ATCTech
Active Member
- Joined
- Aug 13, 2002
- Messages
- 1,857
I've been monitoring a 3 frequency Cap+ system for the past week with about 80% success. Once in a while when the rest channel changes, DSD+ shows (example from a few moments ago):
2018/02/11 10:23:46 Freq=463.150000 DCC=1 Lost rest channel; tuning to 460.875000
2018/02/11 10:23:47 Freq=460.875000 DCC=1 Lost rest channel; tuning to 463.150000
2018/02/11 10:23:48 Freq=463.150000 DCC=1 Lost rest channel; tuning to 460.875000
2018/02/11 10:23:49 Freq=460.875000 DCC=1 Lost rest channel; tuning to 463.150000
2018/02/11 10:23:50 Freq=463.150000 DCC=1 Auto enabling audio synthesis
2018/02/11 10:23:51 Freq=461.650000 Current network: 999 Air Transat
2018/02/11 10:23:51 Freq=461.650000 Current site: 999-1 CYYZ Terminal 3
2018/02/11 10:25:28 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=22 Ch=3 2s
2018/02/11 10:25:28 Freq=461.650000 DCC=1 461.650000 is second Cap+ repeater (Ch3 and Ch4)
In other words, it appears that since only repeaters 1 & 3 (the two frequencies shown in the search) for the past while had all voice traffic was on them and one slot on one of them was the rest channel, repeater 2 (ch. 3 & 4) was never checked in the rest channel scan by DSD+. In this example, I manually intervened and entered 461.6500 (repeater 2) into FMP and monitoring was restored. FWIW, DSD+ Cap+ CC also only showed the 2 active frequencies prior to the rest channel change as well. When all 3 are in use during busier times, all 3 frequencies are displayed in the proper order.
Second, as is the case right now, repeater 2 no longer contains the rest channel and DSD+ is not scanning the list at all, it's stuck on repeater #2.
2018/02/11 10:31:37 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=315 Ch=4 1s
2018/02/11 10:31:38 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=314 Ch=4 13s
2018/02/11 10:31:56 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=314 Ch=3 2s
2018/02/11 10:31:56 Freq=461.650000 DCC=1 461.650000 is second Cap+ repeater (Ch3 and Ch4)
2018/02/11 10:31:58 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=315 Ch=3 4s
2018/02/11 10:32:03 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=314 Ch=3 4s
2018/02/11 10:40:00 Freq=461.650000 DCC=1 Lost rest channel
And the cc.log last few entries from just now:
2018.02.11 10:39:54 Sync:+DMR
2018.02.11 10:39:54 +DMR slot2 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 +DMR slot1 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 +DMR slot2 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 +DMR slot1 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 Cap+ Site=1 RestCh=4
2018.02.11 10:39:54 +DMR slot2 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 +DMR slot1 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:55 Sync: no sync
then nothing for the next 10 minutes as I typed this.
Most of the time, especially when the system is busy, all 3 repeaters are in the voice call cycle and when the rest channel changes DSD+ will find the next one right away, then out of nowhere it stops checking the 3 frequencies in the DSD+ frequencies file.
I have -rc in the DSD+ and FMP CC startup files, and the 3 frequencies are in the proper order, at least as far as DSD+ reporting "is xxx Cap+ repeater on a regular basis:
Cap+, 999, 1, 1, 460.8750, 0.0, 0
Cap+, 999, 1, 3, 461.6500, 0.0, 0
Cap+, 999, 1, 5, 463.1500, 0.0, 0
Any idea what I'm missing, or if this a case for the DSD+ guys to look into? And before somebody suggests signal strength/quality, it's rock solid and audio is excellent as well. When I manauly select a system frequency it restores immediately
My other observation is that when the rest channel does change, DSD+ doesn't continue to display any of the other frequencies until there's voice activity on them. Is this normal behavior in Cap+ monitoring when the frequency file clearly contains all the system frequencies?
Thanks!
Bob
2018/02/11 10:23:46 Freq=463.150000 DCC=1 Lost rest channel; tuning to 460.875000
2018/02/11 10:23:47 Freq=460.875000 DCC=1 Lost rest channel; tuning to 463.150000
2018/02/11 10:23:48 Freq=463.150000 DCC=1 Lost rest channel; tuning to 460.875000
2018/02/11 10:23:49 Freq=460.875000 DCC=1 Lost rest channel; tuning to 463.150000
2018/02/11 10:23:50 Freq=463.150000 DCC=1 Auto enabling audio synthesis
2018/02/11 10:23:51 Freq=461.650000 Current network: 999 Air Transat
2018/02/11 10:23:51 Freq=461.650000 Current site: 999-1 CYYZ Terminal 3
2018/02/11 10:25:28 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=22 Ch=3 2s
2018/02/11 10:25:28 Freq=461.650000 DCC=1 461.650000 is second Cap+ repeater (Ch3 and Ch4)
In other words, it appears that since only repeaters 1 & 3 (the two frequencies shown in the search) for the past while had all voice traffic was on them and one slot on one of them was the rest channel, repeater 2 (ch. 3 & 4) was never checked in the rest channel scan by DSD+. In this example, I manually intervened and entered 461.6500 (repeater 2) into FMP and monitoring was restored. FWIW, DSD+ Cap+ CC also only showed the 2 active frequencies prior to the rest channel change as well. When all 3 are in use during busier times, all 3 frequencies are displayed in the proper order.
Second, as is the case right now, repeater 2 no longer contains the rest channel and DSD+ is not scanning the list at all, it's stuck on repeater #2.
2018/02/11 10:31:37 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=315 Ch=4 1s
2018/02/11 10:31:38 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=314 Ch=4 13s
2018/02/11 10:31:56 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=314 Ch=3 2s
2018/02/11 10:31:56 Freq=461.650000 DCC=1 461.650000 is second Cap+ repeater (Ch3 and Ch4)
2018/02/11 10:31:58 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=315 Ch=3 4s
2018/02/11 10:32:03 Freq=461.650000 DCC=1 Group call; TG=60 [Operations] RID=314 Ch=3 4s
2018/02/11 10:40:00 Freq=461.650000 DCC=1 Lost rest channel
And the cc.log last few entries from just now:
2018.02.11 10:39:54 Sync:+DMR
2018.02.11 10:39:54 +DMR slot2 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 +DMR slot1 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 +DMR slot2 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 +DMR slot1 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 Cap+ Site=1 RestCh=4
2018.02.11 10:39:54 +DMR slot2 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:54 +DMR slot1 BS DATA DCC=1 CSBK Cap+ RestCh=4
2018.02.11 10:39:55 Sync: no sync
then nothing for the next 10 minutes as I typed this.
Most of the time, especially when the system is busy, all 3 repeaters are in the voice call cycle and when the rest channel changes DSD+ will find the next one right away, then out of nowhere it stops checking the 3 frequencies in the DSD+ frequencies file.
I have -rc in the DSD+ and FMP CC startup files, and the 3 frequencies are in the proper order, at least as far as DSD+ reporting "is xxx Cap+ repeater on a regular basis:
Cap+, 999, 1, 1, 460.8750, 0.0, 0
Cap+, 999, 1, 3, 461.6500, 0.0, 0
Cap+, 999, 1, 5, 463.1500, 0.0, 0
Any idea what I'm missing, or if this a case for the DSD+ guys to look into? And before somebody suggests signal strength/quality, it's rock solid and audio is excellent as well. When I manauly select a system frequency it restores immediately
My other observation is that when the rest channel does change, DSD+ doesn't continue to display any of the other frequencies until there's voice activity on them. Is this normal behavior in Cap+ monitoring when the frequency file clearly contains all the system frequencies?
Thanks!
Bob
Last edited: