Bug fixes for dsd 1.4.1/mbelib 1.2.3

Status
Not open for further replies.

dsdauthor

Member
Joined
Mar 17, 2010
Messages
49
As you probably have noticed I have not had any time to give to this project in the past few years. I'm ready to take a fresh look at this and would like to get a new release out with the numerous bug fixes that have been identified.

Please use this thread to consolidate the known issues and fixes.
Please do NOT use this thread to ask for help compiling or using DSD.
If this thread is stickied I will keep this first post updated with the list of known issues being worked on for the next release.
 

scannerfreak

Moderator
Database Admin
Joined
Jul 3, 2003
Messages
5,193
Location
Indiana
Welcome back. I will sticky this. I will also echo the above requests. To all, please follow them.

If your edit time expires, feel free to PM a mod (or post here) and we can edit the initial post for you.
 
Last edited:

rbrtklamp2

Member
Premium Subscriber
Joined
Dec 8, 2005
Messages
847
Location
Dupage County, Illinois
Bug fixes and other enhancements I would like to see include

NXDN Trunking support- it will currently not decode any NXDN trunked channels
P25 Phase 2 support- Currently it only supports X2-TDMA
When Decoding P25 data can you make it so it can display the HDU, LDU1, LDU2, and TDU packets in hex format that would help alot.

Thanks for coming back DSDAUTHOR we missed you,
Bob
 
Last edited:

gary123

Member
Joined
Sep 11, 2002
Messages
2,200
Welcome back. Exellent program Thank You.

I have to echo rbrtklamp2 request.
when decoding P25 data being able to display the VC packet info (88bits) would be extremely usefull. I do not know if you process the parity info or not but being able to select this on and off would be helpfull too.

maybe porting it to Java so that one version works for both major operating systems would be something for the future??
 

AZScanner

Member
Joined
Dec 19, 2002
Messages
3,342
Location
Somewhere in this room. Right now, you're very col
Welcome back DSDAuthor! There's been some pretty significant development done in your absence that you'll probably want to include in your official fixes. This thread contains the details.

If I could also make one request while you're at it, I second the request to be able to output to a file the hex data for the HDU, LDU1, LDU2 and TDU packets. It's a fix I was planning to add to my own personal copy if I am able to figure out how (I've done a little dabbling in C), but I think it would be a great addition to the official code.

Thanks once again for all you do!
-AZ
 

mtindor

OH/WV DB Admin
Database Admin
Joined
Dec 5, 2006
Messages
10,368
Location
Carroll Co OH / EN90LN
dsdauthor,

There have been many people compiling the pristine dsd 1.4.1/mbe 1.2.3 on Linux. There have been some who have incorporated 'fixes' for various bugs. There have been Windows binaries released by some that have added new features (raised cosine filter and a couple other things), but with no source.

There is a large base of Windows users now thanks to the binaries, so I would say that some work should be done on making sure that either binaries are made for Windows when new source is released, or that fixes are made to allow easier / less error-prone compilation on Windows.

Thank you for your original work, and for your willingness to pick up development again.

I'd encourage you to read the following threads regarding some bugs/fixes that have been talked about. I'd also encourage you to take a look at the Windows 1.6 binary to see what changes were made in it. There is a thread from Woodpecker on the subject of DSD 1.6 for windows on these forums where he talks about the changes that he had incorporated.

slicerwizard
- http://forums.radioreference.com/di...-1-6-closed-fork-open-source.html#post1884783

ericcotrrell
- http://forums.radioreference.com/1879375-post298.html

unitrunker
- http://forums.radioreference.com/1879375-post298.html


I'd encourage you to read the following forum thread:

http://forums.radioreference.com/di...e/256111-dsd-1-6-closed-fork-open-source.html

Thanks!

Mike
 

racingfan360

Member
Joined
Dec 19, 2005
Messages
1,158
Welcome back dsdauthor...great to have you around again.

The earlier posts from AZScanner and Mike cover the main bugs fixes I would have suggested, and the threads they linked to.

If I may suggest a few new features that you might like to consider:
- Color Code decoding for DMR/MotoTRBO channels (I'm sure Ian Wraith will be able to help out if necessary given his considerable expertise with DMRDecoder)

- Add the ability to configure the file name for .amb recordings (or more specifically, annotate the filename with the decoded digital type - NX48, NX96 or DMR, and include Color Code in the filename if possible). Another idea might be to save the .amb files to different (configurable) directories depending on the digital type decoded.

- I'd also vote for the ability to decode voice traffic on a NXDN trunked system. You might find this thread helpful, as it links to the [now] open standard:
http://forums.radioreference.com/di...47-status-nexedge-idas-nxdn4800-decoding.html

Thanks for coming back...I really believe that DSD is the most significant development in the scanning world for many years.

Jim
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
When Decoding P25 data can you make it so it can display the HDU, LDU1, LDU2, and TDU packets in hex format that would help alot.
DSD's decision point tracking logic doesn't allow for proper HDU decoding, nor does it take advantage of the FEC elements built in to the HDU data. I marked some of the bad decodes with X's:

http://home.ica.net/~phoenix/wap/Misc/DSD HDU Decision Point Tracking.PNG


This is how it's supposed to look:

http://home.ica.net/~phoenix/wap/Misc/Proper HDU Decision Point Tracking.PNG
 

gary123

Member
Joined
Sep 11, 2002
Messages
2,200
slicerwizard. I believe you are correct DSD does not use the P25 builtin parity routines.

from what I have partially figured it may be possible to intercept and dump the LDU VC packets as/before they are passed on to the IMBE portion of the program.
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
slicerwizard. I believe you are correct DSD does not use the P25 builtin parity routines.
It's easy to verify; an HDU looks like this:

Code:
HDU

48 bit frame sync
64 bit NID
648 bit header code word (36 18-bit Golay codewords; 6p+11FEC+1parity)
10 null bits
22 bits (11 status symbols; inserted after every 70 bits)
--------------
792 total bits


FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFNNNNNNNNNNNNNNNNNNNNNNss
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNppppppGGGGGGGGGGGPppppppGGGGss
GGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGss
GGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppss
GGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppss
ppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppss
ppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPss
ppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGss
GPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGss
GGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGss
GGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPppppppGGGGGGGGGGGPnnnnnnnnnnss

and in p25p1_hdu.c, the code repeatedly grabs 6 bits (3 dibits) and discards the next 12 bits (6 dibits):

Code:
dibit = getDibit (opts, state);
mi[0] = (1 & (dibit >> 1)) + 48;      // bit 1
mi[1] = (1 & dibit) + 48;     // bit 0
dibit = getDibit (opts, state);
mi[2] = (1 & (dibit >> 1)) + 48;      // bit 1
mi[3] = (1 & dibit) + 48;     // bit 0
dibit = getDibit (opts, state);
mi[4] = (1 & (dibit >> 1)) + 48;      // bit 1
mi[5] = (1 & dibit) + 48;     // bit 0
skipDibit (opts, state, 6);

dibit = getDibit (opts, state);
mi[6] = (1 & (dibit >> 1)) + 48;      // bit 1
mi[7] = (1 & dibit) + 48;     // bit 0
dibit = getDibit (opts, state);
mi[8] = (1 & (dibit >> 1)) + 48;      // bit 1
mi[9] = (1 & dibit) + 48;     // bit 0
dibit = getDibit (opts, state);
mi[10] = (1 & (dibit >> 1)) + 48;     // bit 1
mi[11] = (1 & dibit) + 48;    // bit 0
skipDibit (opts, state, 7);

dibit = getDibit (opts, state);
mi[12] = (1 & (dibit >> 1)) + 48;     // bit 1
mi[13] = (1 & dibit) + 48;    // bit 0
dibit = getDibit (opts, state);
mi[14] = (1 & (dibit >> 1)) + 48;     // bit 1
mi[15] = (1 & dibit) + 48;    // bit 0
dibit = getDibit (opts, state);
mi[16] = (1 & (dibit >> 1)) + 48;     // bit 1
mi[17] = (1 & dibit) + 48;    // bit 0
skipDibit (opts, state, 6);

Same deal with the MI, etc. in p25p1_ldu2.c.


from what I have partially figured it may be possible to intercept and dump the LDU VC packets as/before they are passed on to the IMBE portion of the program.
Yep, that's trivial. I'll hook you up.
 

inigo88

California DB Admin
Database Admin
Joined
Oct 31, 2004
Messages
1,990
Location
San Diego, CA
I agree with everyone above. Especially take a look at the windows build 1.6 thread. In addition to everything that was mentioned, considerable progress was made in decoding weak TRBO (DMR) signals by using a "raised cosine filter." (Details are in the thread).

I'd love to see additional support for DMR as far as MotoTRBO Color Codes, talkgroups, radio IDs and channel grants for the various trunked variants. (Currently DSD shows all these as 'unidentified CSBK.' See the threads "Understanding Capacity Plus Trunking" and "Understanding Connect Plus Trunking" in this thread for details, and feel free to PM me, IanWraith or others with questions.

Most importantly, we would love to see NXDN trunked voice supported, as it uses a different frame sync method than the regular NXDN voice packets.

Thanks for coming back! :)
 

dsdauthor

Member
Joined
Mar 17, 2010
Messages
49
I don't seem to be able to edit the first post....

Here is the list I have so far from the above comments and thread links.

known bugs

- audio device support for Unbuntu >= 10.5
- Golay 23,12 syndrome table missing entries
- dibit buffer overrun
i- nput level calibration off by 2x - this is not an issue on any systems/cards that I have used. Is there an example of operating systems/ sound card that has this problem?
- Makefile support for cygwin
- mbe_convertImbe7100to7200 (2 bugs reported in http://forums.radioreference.com/1879375-post298.html)

feature requests
- NXDN trunk system voice channels (I need sample 48k/mono/16bit discriminator tap audio from a voice channel)
- P25 phase 2 support (I need sample 48k/mono/16bit discriminator tap audo from a voice channel)
- Display P25 phase 1 HDU/LDU1/LDU2/TDU header/data payloads in hex
- option to mute encrypted signals
- raised cosine filter input processing
 

mtindor

OH/WV DB Admin
Database Admin
Joined
Dec 5, 2006
Messages
10,368
Location
Carroll Co OH / EN90LN
Please see the comments of slicerwizard 4-6 posts above this one.

Don't get me wrong, I'm ever grateful for your work on DSD. But the P25 stuff needs work. P25 decodes aren't nearly as good on DSD as they are with any digital scanner I have, and I'm thinking [but could be wrong] that it has something to do with what slicerwizard is referencing 4-6 posts above. So please add to the list something about making the P25 Phase 1 more robust.

Basically, what I experience is that when particular errors occur, it takes a very significant amount of time for it to recover and start decoding again. I'll be hearing perfect audio from a beautiful input signal and then all the sudden it cuts out and oftentimes takes many many seconds to recover and start producing intelligible audio -- and I'll have two digital scanners on at the same time (all feeding off of the same antenna system with Stridesberg multicoupler), and they won't miss a beat.

The raised cosine filter is a must [with an option to disable], and that definitely makes for a huge improvement in decoding TRBO (some say it's only more effective on marginal signals, but I say it's a noticeable improvement on both strong and weak sigs). Now, I don't know if the raised cosine filter is useful [or even active] on P25 signals in the 1.6 Beta win binary floating around.


- Mike



I don't seem to be able to edit the first post....

Here is the list I have so far from the above comments and thread links.
 
Last edited:

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
DSDAuthor - please check your PMs.

I don't seem to be able to edit the first post....
The forum has a 1 hour time limit for edits and typos.

dsdauthor said:
P25 phase 2 support (I need sample 48k/mono/16bit discriminator tap audo from a voice channel)
I'll try to get this for you later today. Weekend traffic tends to be low.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
But the P25 stuff needs work. P25 decodes aren't nearly as good on DSD as they are with any digital scanner I have, and I'm thinking [but could be wrong] that it has something to do with what slicerwizard is referencing 4-6 posts above. So please add to the list something about making the P25 Phase 1 more robust.
Andrew raises two points that are worth adding to the list.

1. better symbol tracking.
2. apply error correction bits to the link control data.

The latter requires the following:

Massey-Berlekamp

#1 will improve voice decoding.
#2 has nothing to do with voice quality.

I'm going to make a suggestion:

Add an option to DSD to stream voice data over UDP or TCP. Another instance of DSD would receive the data. This would work just like the record-to-disk and playback-from-disk but over the Internet.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
I'll try to get this for you later today. Weekend traffic tends to be low.
Got it. I think I caught a complete call beginning to end. Have no idea which slot was being used. I've got it in 96000 and 48000 sps.

I also snagged what I think is a wide Opensky sample. All the Opensky in my area is narrow Opensky 2 variety.
 

AZScanner

Member
Joined
Dec 19, 2002
Messages
3,342
Location
Somewhere in this room. Right now, you're very col
Here's an idea which may or may not be totally crazy - How hard would it be to add the ability to take the output of RTL_FM as an input source for DSD? For example, you'd enter this at a command prompt: rtl_fm -N -f 460.3M -s 48k -o 4 -l 190 |DSD -i stdin -o dev/dsp, other options etc.and DSD would read the stream from RTL_FM and process it that way, eliminating the need for a sound card input in between, which would hopefully make it run much faster and decode better on slower machines like mine. I can pipe RTL_FM to SoX for output to the soundcard, but I have no idea how to go about adding this capability to DSD. If anyone here can point me in the right direction I can try adding the code myself. I'm currently tasked with re-learning C for my job so this would be a fun way to sharpen my skills with it (it's been three kids and many years since I last coded in C).

-AZ
 

KA1RBI

Member
Joined
Aug 15, 2008
Messages
799
Location
Portage Escarpment
Got it. I think I caught a complete call beginning to end. Have no idea which slot was being used. I've got it in 96000 and 48000 sps.

I also snagged what I think is a wide Opensky sample. All the Opensky in my area is narrow Opensky 2 variety.

Hey Unitrunker

Could I also get a copy of this please & thank you

The 96k one would be best.

Max
 
Status
Not open for further replies.
Top