DiGiTaLD
Member
- Joined
- Aug 10, 2005
- Messages
- 789
I believe I'm experiencing a flaw in the 2096 when in talkgroup ID hold mode on a Motorola Type II SmartNet system.
I pipe audio from my 2096 to my computer for audio logging of the primary talkgroup I use at work. This talkgroup is on a Motorola Type II SmartNet system that alternates it's control channel every night at midnight. I work night shift so the control changes while I am at work. I set the scanner up by first selecting to scan only the bank for the system I wish to monitor - and that bank only contains the four possible control channels for that system, nothing else (everything else is zeroed and locked out). I will then put the scanner in talkgroup ID hold mode by going into the talkgroup list (PROG + TRUNK) and then selecting the talkgroup (FUNC + TRUNK). The scanner goes into ID hold mode on the talkgroup I wish to monitor. I have noticed on two different occasions that my software logs no traffic after midnight (when the control channel rotates), even though I know there has been traffic after midnight. I know my software configuration is good because I use it to monitor other things all night long and never experience any trouble with getting a full night of transmissions (and associated logs), except for when talkgroup ID holding on this one system.
I think what is happening is, for whatever reason, when the system control changes at midnight, the scanner is locked on to the old control channel, and does not seek out the new one. This doesn't seem like it should happen, because in ID hold mode the scanner should be looking for traffic from only one talkgroup, not from one specific frequency. I believe this could be a flaw in the programming, as what I believe should happen is when the control channel changes, the scanner should seek out the new control channel, but continue to only look for traffic on the held talkgroup ID, especially when only one bank containing only one system's control channels is selected for scanning while talkgroup ID holding.
Also, I noticed that when pressing MAN to kick the scanner off the talkgroup ID hold mode, the channel the scanner was sitting on was not the current system control channel, but I believe it was yesterday, which further supports my theory of what is happening.
Hope my post isn't too confusing. I haven't tried this with a SmartZone, P25, or EDACS system yet, so I don't know what would happen there. But that's what it seems to be doing with a SmartNet (and would probably also do with others that rotated their control channels). If anybody can replicate this, I'd be interested in hearing about it.
BTW, my 2096 is equipped with the following:
CPU Version 1.1
DSP-App Version 1.4
DSP-Voc Version 1.0
I pipe audio from my 2096 to my computer for audio logging of the primary talkgroup I use at work. This talkgroup is on a Motorola Type II SmartNet system that alternates it's control channel every night at midnight. I work night shift so the control changes while I am at work. I set the scanner up by first selecting to scan only the bank for the system I wish to monitor - and that bank only contains the four possible control channels for that system, nothing else (everything else is zeroed and locked out). I will then put the scanner in talkgroup ID hold mode by going into the talkgroup list (PROG + TRUNK) and then selecting the talkgroup (FUNC + TRUNK). The scanner goes into ID hold mode on the talkgroup I wish to monitor. I have noticed on two different occasions that my software logs no traffic after midnight (when the control channel rotates), even though I know there has been traffic after midnight. I know my software configuration is good because I use it to monitor other things all night long and never experience any trouble with getting a full night of transmissions (and associated logs), except for when talkgroup ID holding on this one system.
I think what is happening is, for whatever reason, when the system control changes at midnight, the scanner is locked on to the old control channel, and does not seek out the new one. This doesn't seem like it should happen, because in ID hold mode the scanner should be looking for traffic from only one talkgroup, not from one specific frequency. I believe this could be a flaw in the programming, as what I believe should happen is when the control channel changes, the scanner should seek out the new control channel, but continue to only look for traffic on the held talkgroup ID, especially when only one bank containing only one system's control channels is selected for scanning while talkgroup ID holding.
Also, I noticed that when pressing MAN to kick the scanner off the talkgroup ID hold mode, the channel the scanner was sitting on was not the current system control channel, but I believe it was yesterday, which further supports my theory of what is happening.
Hope my post isn't too confusing. I haven't tried this with a SmartZone, P25, or EDACS system yet, so I don't know what would happen there. But that's what it seems to be doing with a SmartNet (and would probably also do with others that rotated their control channels). If anybody can replicate this, I'd be interested in hearing about it.
BTW, my 2096 is equipped with the following:
CPU Version 1.1
DSP-App Version 1.4
DSP-Voc Version 1.0
