Montgomery Co TRS & 396T

[maus92]

I've been driving through MC for the last few days, and I noticed that my 396 is not decoding/receiving their TRS. I know that the radio used to work in MC, but this is the first time I've been in the county since upgrading to the latest firmware. Is anyone else experiencing a similar problem? Has MC changed the setup of their TRS? BTW, I manually tuned to their active CC frequency and could see radio ID's and TG's, but the audio was digital and was not being decoded. Also, there were no ENC or LNK flags displayed. A further note - I was receiving Howard Co's TRS just fine.

Thanks for your help,

CA
Annapolis

 

[Llwellyn]

I tried pulling in Montgomery county from my location, and I could no longer copy them enough to decode the trunking channel... back when the leaves were off of the trees, I could copy them no problem. What signal I did copy sounded a little odd, the control channel sounded slightly different than it should. That could have been the poor reception, or it could be part of the problem. I'll try again from work later this week and see if I can pick them up.

 

[troymail]

I don't get a real strong signal but I am able to lock in on the CC and hear some broken conversations (weak)... seems to be workin on my 396... running v1.11.03

BTW - I'm in Western AA County - below BWI.

Checked it out from an area near Rt 175/Rt 295 in Jessup... pretty good reception from there....

 

[maus92]

Hmmm...

I know that my 396T is working because it decodes other P25 800 TRS's (went through Sussex Co. yesterday, as well as Upper ES), so I'm going to reset the radio and redownload everything and post the result.

Thanks,

CA
Annapolis

 

[maus92]

Update

All,

I reloaded my MC system using UASD and drove down I-270 from Frederick to Bethesda - my 396 is still not decoding the MC TRS. I locked onto the control channel and saw all kinds of activity, but nothing is being decoded. Very strange. I'm reflashing the newest firmware, but if that doesn't work, I may have to revert the the previous version - which I need to find somewhere...

CA
Annapolis

 

[kg4icg]

Question? Did you set the trunk system up as P25 or 800mhz standard. If you set up as P25 then that's the problem, It's 800 mhz standard. I'm here in Ashburn,Va and receive Montgomery County without any problems.


R Collins

 

[maus92]

System Type

Set up as 800 Type 2 standard. The scanner used to decode this system just fine several months ago.....

CA
Annapolis

 

[Dank]

I'm in the NE part of Montgomery County and I have had some issues too since reloading their data into my BC296 on Saturday. It worked fine last time I monitored them before reprogramming my radio. I reloaded the same ARC file on Saturday morning. When I manually stop on a freq I can hear them loud and clear, but my radio is not decoding their system when in the scan mode. I will confirm the 800Mhz std setting tonight.

 

[WadeBlake]

I have a BC296D and it receives the Montgomery Co. system fine. I'm not sure how the 396 trunk setting works, but the 296 is set at TYPE2/P25 800. The Montgomery Co. system uses an "analog" control channel, while the talk groups are digital.

Wade

 

[maus92]

Montgomery County & 396T con't

All,

So I reflashed the latest firmware, and changed from ID Scan to ID Search..... and viola! I can now receive and decode the Montgomery County TRS.... except that the programmed TGID's are not being received/decoded. I checked the RR database to see if the TGID's have changed recently, but it doesn't appear so. Here's the question - has Montgonmery County changed their TGIDs? I am not seeing any TGID's that are shorter than 5 digits, most are 16### and higher, plus the I-Calls. I'm begining to think that my USAD file is corrupt somehow.... Any suggestions/advice is appreciated.

CA
Annapolis

 

[Llwellyn]

I wasn't going to admit this at first, but I changed my mind

Check to make sure that the UASD entries are correct and that they are not switched or reversed from what they should be (i.e. TGID vs. TG Name). I did that on one system that I partially entered with Excel and partially with UASD... somehow I got them backwards. It flashed to the radio with a bunch of TGID's as TG Names with TGID's that were all messed up. I think anything that had a letter that's also a hex digit ended up getting entered into the radio anyway and it threw the rest out... it looked like the system was scanning just fine in ID Scan too, because the CC data was correct there just weren't any *in use* TG's in there.

 

[maus92]

That was a great suggestion, but I checked and everything was programmed correctly. I think that the best way to proceed is to create a test Montgomery County System, programmed with a sampling of busy TG's (Fire Dispatch, Rockville Police District, etc.) and see what happens....

But keep those suggestions rolling in...

CA
Annapolis

 

[maus92]

Problem Solved

So, after a few months of screwing around, I have discovered the source of my problem with the Montgomery County TRS and my 396T.

Originally, I had my scanner setup to monitor the MCTRS in ID Scan mode. At some point, the scanner stopped receiving the system. I theorized that a either a new firmware update or reprogramming the MCTRS system somehow hosed the scanner, so I reflashed the 1.13 and reloaded the system database - with no effect. So I changed the mode from ID Scan to ID Search. Viola! - sort of. I started receiving the system, except I was only seeing the TGIDNumbers - but not the translated TGIDNames. Then the other day I was in DC, so I pulled off to the side of the road and experimented with programming the system manually (not using the software.) When I looked in the MC system, the TGIDNames were there, but when went in the edit the TGIDNumbers - they were empty (blank!) So I programmed in TGID 3344 (MC Fire Dispatch) - and Viola! It properly translated the TGIDNumber to the TGIDName. I went home and fired up USAD, and looked at the MC system - all the TGIDNames and Numbers were properly entered. So then I examined the .usd file for the MC system using Windows Notepad. All the Group Names, TGIDNames and Numbers were there, but upon closer inspection, I noticed some shifting of the data caused by missing parans, commas, etc. in different places throughout the file!

So it turns out that the root of my probelm was a corrupted .usd file. Since USAD didn't load the TGIDNumbers, the ID Scan mode had no TGIDNumbers to evaluate and could never translate an appropriate TGIDName. And since ID Scan mode assumes that you only want to hear what TGIDNumbers that you have programmed, the scanner never tunes to a TG. That's why the scanner worked when switched to the ID Search mode, because ID Search looks for all TGIDNumbers and receives the TG, and if there is a TGIDName associated with it, displays that info.

It's curious that the USAD software seemed to have no problem with the missing and/or shifted characters when reading the corrupted .usd data file. I guess there is some sort of data validation/error correction built into the software, but for some reason, it doesn't correct the data file when resaved...

Note: Due to the number of TG's in the MC TRS, I decided to split up the Fire and Police zones into two seperate systems. That's the beauty of the 396/996 - the dynamic system of memory allocation is extremely flexible.

CA
Annapolis