Hi Eric. Please check your PM. I have some info you would be interested in.
thanks!
thanks!
DSD improvements I am working on
- Thread starter EricCottrell
- Start date
-
- Tags
- dsdplus
- Status
n4yek
Member
Eric,
I tried something new today with WinDSDv2. I told it to not send decoded audio to the sound card using the -n command.
When I use this, I no longer receive the error listed above in nd5y's response. What does happen though is after a while, the program will crash and I have to close it and re-open to continue decoding the data stream of the voice channels I am watching. This will happen after about 10-15 minutes.
Just fyi
Danny
Hi all,
I'm getting good decode on everything and about 80% or so on NXDN 4.8. I have both ICOM R7000 and R8500 and the 8500 performs best with NXDN 4.8 in narrow mode but still audio cuts out. I am wondering if the 5.5KHz filter is too narrow for the 6.25 KHz signal.
I wonder if it's better to use the radio's cleaner 455KHz IF and down convert to sound card frequencies (12KHz) with possibly correct filtering at this point. In addition, I & Q could also be demodulated in the same circuit and outputting to the left and right sound card channels. This should help with the correct handling of P25 CQPSK signals on simulcast systems.
I would be willing to draw up a schematic if I would get some help in the design.
Eric, would this be something worth doing and would you be willing to make the appropriate mod to WinDSD?
thanks!
I'm getting good decode on everything and about 80% or so on NXDN 4.8. I have both ICOM R7000 and R8500 and the 8500 performs best with NXDN 4.8 in narrow mode but still audio cuts out. I am wondering if the 5.5KHz filter is too narrow for the 6.25 KHz signal.
I wonder if it's better to use the radio's cleaner 455KHz IF and down convert to sound card frequencies (12KHz) with possibly correct filtering at this point. In addition, I & Q could also be demodulated in the same circuit and outputting to the left and right sound card channels. This should help with the correct handling of P25 CQPSK signals on simulcast systems.
I would be willing to draw up a schematic if I would get some help in the design.
Eric, would this be something worth doing and would you be willing to make the appropriate mod to WinDSD?
thanks!
Hello,
I have been distracted by some bright shiny objects recently. Code development can be a slow process. I am looking at some possible tools and libraries to use. It is possible with some added windows code (audio and serial port I/O) and CMake magic to have the mainstream dsd code buildable under both Linux and Windows.
I am doing some research and consideration on how to restructure code to make it easier to display and do other processing like logging. Dsd basically dumps information out on the fly as it is a dumper type program. The user will not see much changed even though there will be major changes internally. Software Developers use the term "refactoring" to describe this restructuring.
My efforts have been to enable detail dumps of the CAI to see how a system works, since I am interested in protocols and how they work. I realize most users are really only interested in identification type infomation, who is talking to whom on what site of what system. So I am thinking of extending the existing verbose levels so the default is to only give basic infomation like is done for P25. If the user wants a detailed dump then just add a -v option to the command line with a higher level.
I am also interested in supporting other inputs. I came across this interesting thread since I have a HP-1.
http://forums.radioreference.com/tr...-cdb-1-serial-command-hp-1-nice-surprise.html
I am going to run some tests to see how useful it is and how widespread the implementation. It may only work on P25 signals.
I still want to look at changing the display to be similar to the ncurses type display examples from earlier in the thread. It appears possible to compile ncurses for windows. This will allow for screen formating. There are add-ons that allow for form style data entry.
I am debating on using Qt instead. The program would go from a command line program to a window based program that runs under X Windows or Microsoft Windows. There would likely still be a window to display the CAI dump. If I go the Qt route, the QtDSD program would be a redesign and likely not share much with the current dsd other than my decoding additions.
73 Eric
I have been distracted by some bright shiny objects recently. Code development can be a slow process. I am looking at some possible tools and libraries to use. It is possible with some added windows code (audio and serial port I/O) and CMake magic to have the mainstream dsd code buildable under both Linux and Windows.
I am doing some research and consideration on how to restructure code to make it easier to display and do other processing like logging. Dsd basically dumps information out on the fly as it is a dumper type program. The user will not see much changed even though there will be major changes internally. Software Developers use the term "refactoring" to describe this restructuring.
My efforts have been to enable detail dumps of the CAI to see how a system works, since I am interested in protocols and how they work. I realize most users are really only interested in identification type infomation, who is talking to whom on what site of what system. So I am thinking of extending the existing verbose levels so the default is to only give basic infomation like is done for P25. If the user wants a detailed dump then just add a -v option to the command line with a higher level.
I am also interested in supporting other inputs. I came across this interesting thread since I have a HP-1.
http://forums.radioreference.com/tr...-cdb-1-serial-command-hp-1-nice-surprise.html
I am going to run some tests to see how useful it is and how widespread the implementation. It may only work on P25 signals.
I still want to look at changing the display to be similar to the ncurses type display examples from earlier in the thread. It appears possible to compile ncurses for windows. This will allow for screen formating. There are add-ons that allow for form style data entry.
I am debating on using Qt instead. The program would go from a command line program to a window based program that runs under X Windows or Microsoft Windows. There would likely still be a window to display the CAI dump. If I go the Qt route, the QtDSD program would be a redesign and likely not share much with the current dsd other than my decoding additions.
73 Eric
n4yek
Member
Hello,
I did not have any problems with the link. Version 2 is current.
http://www.radiophile.info/WinDSD/WinDSDv2.zip
73 Eric
You were right. I checked last night and the website wasn't responding to requests but the box was online.
DSD Version X
Eric, are you saying your back on the project? Since I am involved in the NXref project (with NDA),
I might be able to have a friend look it over and see whats missing. Though we use the RAW and PURE
ip stream, there might be some things we can offer that wont violate the NDA. We have code for both
Icom and Kenwood.
I congratulate you on the current build of DSDwin that decodes conventional OTA signals. Good job.
Please advise or email me direct.
I will be heading to Jacksonville in 7 hours (5 am ET) so I am off to na na land. Work needs me up there
working on a bad situation. Love traveling, just not the 3 hour drive from central Fla to Jax.
Evans
KD4EFM
NXDNINFO.COM | NXDN CAI and its application to Amateur Radio
Eric, are you saying your back on the project? Since I am involved in the NXref project (with NDA),
I might be able to have a friend look it over and see whats missing. Though we use the RAW and PURE
ip stream, there might be some things we can offer that wont violate the NDA. We have code for both
Icom and Kenwood.
I congratulate you on the current build of DSDwin that decodes conventional OTA signals. Good job.
Please advise or email me direct.
I will be heading to Jacksonville in 7 hours (5 am ET) so I am off to na na land. Work needs me up there
working on a bad situation. Love traveling, just not the 3 hour drive from central Fla to Jax.
Evans
KD4EFM
NXDNINFO.COM | NXDN CAI and its application to Amateur Radio
Hello,
I have a copy of the NXDN specifications, so I am mostly covered. One thing that is missing is the radio alias that some trunked systems transmit and dsdplus displays. It does not seem to be in the specifications.
I have been working on and off for a few months. It was really great when I was able to get the itpp library to do the punctured convolutional decoding and started to decode the data. There are so many messages and data elements. I am in the middle of restructuring the code to improve things.
One interesting feature of an IDAS multi-site trunked system (Type-D) is when a radio registers at a site. The site sends a file to the radio that gives the repeater to frequency mapping. It was really helpful in figuring out a IDAS system up in Maine. I can figure out the information by looking at the hex dump of the data, but I need to write some code that would decode the file data and display the values. There is another file that is sent on inter-system sites that gives a site list and frequency of the collect channels. These files are documented in the specifications. I do not know if there are any inter-system linking going on to test receiving the inter-system file.
There is more Ham DMR activity in my area, so I have some Motorola XPRs. We do have some NXDN activity south of Boston, but it is just out of range of my location. I do have a number of different types of DMR and NXDN commercial stuff in the area that I can use to test dsd. There is even a DMR Tier 3 (trunked) system, but it is an hour or so drive away.
73 Eric
I have a copy of the NXDN specifications, so I am mostly covered. One thing that is missing is the radio alias that some trunked systems transmit and dsdplus displays. It does not seem to be in the specifications.
I have been working on and off for a few months. It was really great when I was able to get the itpp library to do the punctured convolutional decoding and started to decode the data. There are so many messages and data elements. I am in the middle of restructuring the code to improve things.
One interesting feature of an IDAS multi-site trunked system (Type-D) is when a radio registers at a site. The site sends a file to the radio that gives the repeater to frequency mapping. It was really helpful in figuring out a IDAS system up in Maine. I can figure out the information by looking at the hex dump of the data, but I need to write some code that would decode the file data and display the values. There is another file that is sent on inter-system sites that gives a site list and frequency of the collect channels. These files are documented in the specifications. I do not know if there are any inter-system linking going on to test receiving the inter-system file.
There is more Ham DMR activity in my area, so I have some Motorola XPRs. We do have some NXDN activity south of Boston, but it is just out of range of my location. I do have a number of different types of DMR and NXDN commercial stuff in the area that I can use to test dsd. There is even a DMR Tier 3 (trunked) system, but it is an hour or so drive away.
73 Eric
Hi Eric
Great program! Question, how do you get WinDSD back to the default settings. I changed the -i & -o settings, but I can get back to the default settings before i changed.
vince48
I'm digging this software for decoding iDAS and NEXEDGE. Being there's more information for iDAS, and free channels show correctly, it's proven more useful than DSD 1.51 for system analyzing.
Eric, would you be able to share the format structure for the frequency mapping file? See below for what I've seen. I believe this is what you mean.
Eric, would you be able to share the format structure for the frequency mapping file? See below for what I've seen. I believe this is what you mean.
Code:
Sync: -NXDN48 mod: GFSK inlvl: 8% IDAS Ch DATA DWR (Header) SI:0-0 DI:1-757 BlockCount:3
Sync: -NXDN48 mod: GFSK inlvl: 9% IDAS Ch DATA DWR (Data) PFr:2 Blk:2 00 25 F1 14 1A FC CC 58 1B 49 17 98 16 1B 91 92 48 1B
Sync: -NXDN48 mod: GFSK inlvl: 9% IDAS Ch DATA DWR (Data) PFr:1 Blk:1 DD DD 88 17 1A EE AF 10 1B 3A FA 50 1A 1A F6 B1 D8 1B
Sync: -NXDN48 mod: GFSK inlvl: 8% IDAS Ch DATA DWR (Data) PFr:0 Blk:0 42 FD 18 84 A6 6F 5F 00 00 00 00 00 00 00 00 00 00 00Vince,
If you run the program with no syntax then that's the default. If the defaults changed it's because your system enumerated the inputs and outputs differently. There is no permanent configuration.
Eric, based on what I've read within some ICOM documentation they state that each iDAS channel beacon contains the site identification. Here's what I generally see on a good decode:
There seems to be a good amount of data there. For what isn't known can you print the raw hex so we can take a crack at it?
Code:
Sync: -NXDN48 mod: GFSK inlvl: 50% IDAS Ch DATA
Sync: -NXDN48 mod: GFSK inlvl: 29% IDAS Ch DATA
Sync: -NXDN48 mod: GFSK inlvl: 19% IDAS Ch DATA
Sync: -NXDN48 mod: GFSK inlvl: 13% IDAS Ch DATA
SACCH: Ar:0 Idle Rp:20Hello,
Yes, the DWR Messsages give the information. I have only seen this on the collect channel. The collect channel handles site registration.
The header indicates 3 blocks in your example. The Packet Frame (PFr) and Block (Blk) track together and decrease. A value of zero indicates the last Packet Frame. You have all the blocks. You can use the calculator program to do the hex to decimal conversions.
0025 System Data length = 37 bytes (Opcode + Data) There should be 4 repeaters.
F1 System Data Opcode, F = Integrator Code of 15, and 1 = Site Channel Information
14 1st Repeater Number is 20
1A FC CC 58 1st Repeater Tx Freq (Hz) is 452775000 or 452.775 MHz
1B 49 17 98 1st Repeater Rx Freq (Hz) is 457775000 or 457.775 MHz
16 2nd Repeater Number is 22
1B 91 92 48 2nd Repeater Tx Freq is 462.525 MHz
1B DD DD 88 2nd Repeater Rx Freq is 467.525 MHz
17 3rd Repeater Number is 23
1A EE AF 10 3rd Repeater Tx Freq is 451.850 MHz
1B 3A FA 50 3nd Repeater Rx Freq is 456.850 MHz
1A 4th Repeater Number is 26
1A F6 B1 D8 4th Repeater Tx Freq is 452.375 MHz
1B 42 FD 18 4th Repeater Rx Freq is 457.375 MHz
84 A6 6F 5F Checksum (not included in System Data Length calculation)
73 Eric
Thanks Eric, that's definitely all valid info. I'll put something together in Excel to do the crunching.
This will make identification a LOT easier.
Is there a way to direct the output in the DOS window to a text file? I tried the standard DOS redirect operators, but those didn't work.
rbm
Member
Did you open the DOS Window in administrator mode?
If not, and it's your 'C:' drive, you'll probably get 'Access Denied'.
Rich
Hello,
It appears there are too many errors as there is no SACCH decode except the last one and no data types. Here is what I see on idle bursts on a local system.
Code:
Sync: -NXDN48 mod: GFSK inlvl: 65% IDAS Ch DATA
Sync: -NXDN48 mod: GFSK inlvl: 52% IDAS Ch DATA ADJ_SITE_INFO #1 Sys:1-1 Site:6 #2 Sys:1-1 Site:10
SACCH: Ar:0 Site:8
Sync: -NXDN48 mod: GFSK inlvl: 46% IDAS Ch DATA SRV_INFO Sys:1-1 Site:8 MSS LRS AuS
SACCH: Ar:0 Site:8
Sync: -NXDN48 mod: GFSK inlvl: 41% IDAS Ch DATA ADJ_SITE_INFO #2 Sys:None Site:None #3 Sys:None Site:None
SACCH: Ar:0 Site:8
Sync: -NXDN48 mod: GFSK inlvl: 39% IDAS Ch DATA SRV_INFO Sys:1-1 Site:8 MSS LRS AuS
SACCH: Ar:0 Site:8
Sync: -NXDN48 mod: GFSK inlvl: 37% IDAS Ch DATA TX_REL _C DI:0-0 SI:1-0 FRp:4 TX_REL _C DI:0-0 SI:1-0 FRp:4
SACCH: Ar:0 Idle Rp:1
Sync: no sync73 Eric
- Status
Similar threads
SDS100/SDS200:
Uniden SDS100 GPS Guide (2025)
