Glad to hear it'll be fixed eventually, but it's definitely not "an issue with some garbage entries in the frequencies files". Not on my install, at least.
DSDPlus DSD+ 2.457 Available
- Thread starter dave3825
- Start date
In my example I mentioned previously, it was not a garbage entry that causes it - it was the same frequency being used in two different sites. So if I have in my DSDPlus.frequencies file these two lines (still in the old format because I haven't taken the time to convert to the new format yet since I just got back from Holiday and need to parse the files and submit like 15 new sites to RRDB for the aforementioned system so I'll convert the format at the same time):
TIII, 772:3, 0.1, 125, 935.76250, 0.0, 0, 15 ; Control Channel
TIII, 772:3, 0.13, 125, 935.76250, 0.0, 0 ; Control ChannelAnd I tried connecting to site 13 (which is about 120 miles from site 1) I would get the never-ending scroll of the two sites flip-flopping. Same goes if the second entry didn't exist at all. Adding the color code to the second entry would immediately calm it down (which in this example the color code for site 13 just happens to also be 15).
Rgr that. I only said that because i was having the issue, and I admittedly have DSDPlus.* files containing tons of old useless data from systems that do not even exist anymore -- I'm too lazy to clean it out. I figured there was an outside possibility that even though DSDPlus wasn't barking on any of my entries after startup once I did the search/replace, it may have still been due to some conflicting or duplicate entries that ended up in one of my files. I zipped up some raw audio from a TIII CAPMAX system I was having the issue with, along with all of my DSDPlus.* files and sent them to the author. The author wrote back and confirmed that the bug was found and that there was no issue with my files (other than them being a mess).
Mike
I get that periodically. I think it is a site timing thing causes DSD+ to hang on the VC. It will search CC util that VC becomes active again, then back to normal.
Need to check my files though.
And your does the same exact thing? I mean the one window shows it tuning thru all the cc's but the fmp24 windows do not show it cycling? To me it looks like DSDPlus is not directing/communicating to FMP24 to cycle thru the control channels.
I have the same issue where the "Channel Activity" display and RTLSDR hangs on a VC.
The VC hangs for about 1-8 seconds after receiving a clear transmission, and 2-3 seconds on observing an ENC transmission.
This occurs using either 1 x RTLSDR (Combined CC/VC) or 2 x RTLSDR (CC & VC).
FMP24 does not cycle through channels, it just hangs before re-tuning.
This means I miss transmissions until it finishes hanging and tuning to the next active VC or back to CC.
This hanging is experienced on multiple P25 (FDMA & TDMA) and TIII networks.
It would be good to know if anyone else is experiencing these issues and if there is a solution.
Until then I will have to revert back to a previous version that works with no issues.
I emailed the author the issue I was having and linked the video I posted in post 56. Hopefully a fix comes.
Con+ seemed fine but also see this on a NXDN system. Stuck on last voice call freq and repeatedly stating its tuning to 452.7375 which is not the control channel.
2024/01/09 08:34:41 Freq=463.562500 463.5625 -12.44 m SUFFOLK COUNTY COMMUNICATIONS FARMINGVILLE, NY (SUFFOLK) WPNT840
2024/01/09 08:34:41 Freq=463.562500 Current network: R35 Suffolk Comm 35
2024/01/09 08:34:41 Freq=463.562500 RAN=31 Current site: R35-31 Farmingville
2024/01/09 08:34:45 Freq=463.562500 RAN=31 R35-31 neighbor: Site R35-32; CC=40815 451.01875 Plainview
2024/01/09 08:34:45 Freq=463.562500 RAN=31 R35-31 neighbor: Site R35-35; CC=51745 464.68125
2024/01/09 08:34:50 Freq=463.562500 RAN=31 Group call; TG=660 RID=10183 [---] Ch=41910 TX=452.3875 RX=457.3875 3s
2024/01/09 08:34:56 Freq=463.562500 RAN=31 Group call; TG=660 RID=10035 [---] Ch=41490 TX=451.8625 RX=456.8625 5s
2024/01/09 08:35:03 Freq=463.562500 RAN=31 Group call; TG=660 RID=10183 [---] Ch=50355 TX=462.94375 RX=467.94375 3s
2024/01/09 08:35:56 Freq=462.537500 RAN=31 Lost control channel; tuning to 451.862500; dwell time = 0.75 sec
2024/01/09 08:35:57 Freq=451.862500 RAN=31 Lost control channel; tuning to 452.387500; dwell time = 0.75 sec
2024/01/09 08:35:57 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:35:58 Freq=452.737500 RAN=31 Lost control channel; tuning to 462.943750; dwell time = 0.75 sec
2024/01/09 08:35:59 Freq=462.943750 RAN=31 Lost control channel; tuning to 463.562500; dwell time = 0.75 sec
2024/01/09 08:36:00 Freq=463.562500 RAN=31 Found control channel
2024/01/09 08:36:00 Freq=463.562500 RAN=31 Group call; TG=660 RID=10035 [---] Ch=41910 TX=452.3875 RX=457.3875
2024/01/09 08:36:21 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:22 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:23 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:24 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:25 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:25 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:26 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:27 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:28 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:29 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:29 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:34:41 Freq=463.562500 463.5625 -12.44 m SUFFOLK COUNTY COMMUNICATIONS FARMINGVILLE, NY (SUFFOLK) WPNT840
2024/01/09 08:34:41 Freq=463.562500 Current network: R35 Suffolk Comm 35
2024/01/09 08:34:41 Freq=463.562500 RAN=31 Current site: R35-31 Farmingville
2024/01/09 08:34:45 Freq=463.562500 RAN=31 R35-31 neighbor: Site R35-32; CC=40815 451.01875 Plainview
2024/01/09 08:34:45 Freq=463.562500 RAN=31 R35-31 neighbor: Site R35-35; CC=51745 464.68125
2024/01/09 08:34:50 Freq=463.562500 RAN=31 Group call; TG=660 RID=10183 [---] Ch=41910 TX=452.3875 RX=457.3875 3s
2024/01/09 08:34:56 Freq=463.562500 RAN=31 Group call; TG=660 RID=10035 [---] Ch=41490 TX=451.8625 RX=456.8625 5s
2024/01/09 08:35:03 Freq=463.562500 RAN=31 Group call; TG=660 RID=10183 [---] Ch=50355 TX=462.94375 RX=467.94375 3s
2024/01/09 08:35:56 Freq=462.537500 RAN=31 Lost control channel; tuning to 451.862500; dwell time = 0.75 sec
2024/01/09 08:35:57 Freq=451.862500 RAN=31 Lost control channel; tuning to 452.387500; dwell time = 0.75 sec
2024/01/09 08:35:57 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:35:58 Freq=452.737500 RAN=31 Lost control channel; tuning to 462.943750; dwell time = 0.75 sec
2024/01/09 08:35:59 Freq=462.943750 RAN=31 Lost control channel; tuning to 463.562500; dwell time = 0.75 sec
2024/01/09 08:36:00 Freq=463.562500 RAN=31 Found control channel
2024/01/09 08:36:00 Freq=463.562500 RAN=31 Group call; TG=660 RID=10035 [---] Ch=41910 TX=452.3875 RX=457.3875
2024/01/09 08:36:21 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:22 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:23 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:24 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:25 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:25 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:26 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:27 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:28 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:29 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
2024/01/09 08:36:29 Freq=452.387500 RAN=31 Lost control channel; tuning to 452.737500; dwell time = 0.75 sec
Same here and also this causes broken voice.
NXDN system here and I am also observing this on my side.
For those of you who are experiencing the issue where FMP24 appears to be stuck on the last audio call, have any of you recorded raw audio (of a combined CC/VC session) to capture when the event happens, so that raw audio could be sent to the author for reproduction.
Imagine if the author cannot reproduce the issue with their own setup -- it can't get fixed if it can't be reproduced by the author.
Just food for thought -- raw audio. I know somebody said it happens them with both CC+VC dual-dongle setups as well as single-dongle Combined CC/VC setups. But it would be easier to capture raw audio (and know that you have captured it) if you were to attempt to capture raw audio of an event when using just one dongle and combined CC/VC mode.
Anybody up for the challenge?
PS: The more I think about this, the raw audio (from DSDPlus) would likely be useless, since it wouldn't be played back through FMP24. Somebody would likely need to capture the audio via FMP24 (saved as a wav or IQ) . And that saved audio would have to contain the "event", with the "event" being the failure of FMP24 to retune when it is supposed to. Sorry, just thinking out loud.
I'm only making the suggestion because I can't do it myself - I run all Airspys (using FMPA) and have never experienced the issue.
m
Imagine if the author cannot reproduce the issue with their own setup -- it can't get fixed if it can't be reproduced by the author.
Just food for thought -- raw audio. I know somebody said it happens them with both CC+VC dual-dongle setups as well as single-dongle Combined CC/VC setups. But it would be easier to capture raw audio (and know that you have captured it) if you were to attempt to capture raw audio of an event when using just one dongle and combined CC/VC mode.
Anybody up for the challenge?
PS: The more I think about this, the raw audio (from DSDPlus) would likely be useless, since it wouldn't be played back through FMP24. Somebody would likely need to capture the audio via FMP24 (saved as a wav or IQ) . And that saved audio would have to contain the "event", with the "event" being the failure of FMP24 to retune when it is supposed to. Sorry, just thinking out loud.
I'm only making the suggestion because I can't do it myself - I run all Airspys (using FMPA) and have never experienced the issue.
m
Last edited:
Disregard my post quoted above. Raw Audio will not help. Unless the author can reproduce, the author cannot fix. Those of you with the issue are going to have to nail down precisely when and what triggers the event and then send that info to the author.
adsbgreenock
Member
RSP1A devices fixed ? It was my RSPDUO that kept crashing for some reason...After updating the exe files everything works now .
Simply Brilliant Guys and Thanks for your time fixing this.
Much Appreciated
Simply Brilliant Guys and Thanks for your time fixing this.
Much Appreciated
Yes. some details are it usually happens when I get an encrypted call and when the call drops so does the signal on the spectrum display.
When another call is to that same channel, then just pops back to normal. FMP24 window never changes and shows the control channel.
It is not so frequent I can't live with it but does happen.
My case, this happens on a P25 p1 system.
polkaroo
Missed him again!
- Joined
- Apr 14, 2002
- Messages
- 408
Is there a way to "assume" system designations? My DSDplus files consists of TIII systems that I'm not consistently monitoring on in range of (eg. travelling) - any suggestions to modify the Std/nonStd designation to get rid of the minute or more of scrolling errors each time I start the app? I used to keep separate copies but it became increasingly tedious to keep track of.
15 minutes of Find & Replace with Notepad should fix the ones you have. Your other option is to revert to an older version.
slicerwizard
Member
Couldn't you use the RRDB to check? Anything CapMAX is nonstandard, everything else is likely to be standard. Although in this image, I believe City Services is CapMAX, but not marked as so:
I've noticed some systems either not labeled with the actual type of Tier 3 that is displayed in DSDPlus (commonly Capacity Max). I've also seen some submitted or changed as Tier 3 Standard because of what's displayed on the scanner itself (which doesn't differentiate between different Tier 3 types).
cybergibbons
Member
- Joined
- Jan 8, 2024
- Messages
- 5
How do you actually download this version of DSD? No link provided and the site has 1.101 from 2016 on it.
1.101 is the current "free" release. All of the 2.x releases are to users that pay for the "Fast lane" version (a bargain at $25 for unlimited updates)
Once you have a Fast Lane version installed, the updates can be downloaded directly in the app, and you will use the Fast Lane password you receive in your initial e-mail to decrypt the ZIP file.
