Bug fixes for dsd 1.4.1/mbelib 1.2.3

[dsdauthor]

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]

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.

[rbrtklamp2]

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

[gary123]

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]

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]

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
- DSD 1.6? Closed fork or open source

ericcotrrell
- DSD 1.4 and mbelib 1.2.3 released

unitrunker
- DSD 1.4 and mbelib 1.2.3 released


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

DSD 1.6? Closed fork or open source

Thanks!

Mike

[jhampton2000]

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:
Status of NEXEDGE/iDAS/NXDN4800 decoding?

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

Jim

[slicerwizard]

Originally Posted by rbrtklamp2

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/Mis...20Tracking.PNG


This is how it's supposed to look:

http://home.ica.net/~phoenix/wap/Mis...20Tracking.PNG

[gary123]

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]

Originally Posted by gary123

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:

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):

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.

[AZScanner]

Originally Posted by slicerwizard

Yep, that's trivial. I'll hook you up.

Me too! Me too! Any chance you can post up the modified code as an attachment? This will give me a good excuse to try making a new Windows build on my own.

Thanks,
-AZ

[inigo88]

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]

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 DSD 1.4 and mbelib 1.2.3 released)

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]

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

Originally Posted by dsdauthor

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.

[Unitrunker]

DSDAuthor - please check your PMs.

Originally Posted by dsdauthor

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

The forum has a 1 hour time limit for edits and typos.

Originally Posted by dsdauthor

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.

[Unitrunker]

Originally Posted by mtindor

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.

[Unitrunker]

Originally Posted by Unitrunker

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.

[slicerwizard]

Also, some of the NXDN bit scrambling sequence (nxdnpr[145]) is incorrect.

[AZScanner]

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]

Originally Posted by Unitrunker

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