RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Software > Digital Voice Decoding Software

Digital Voice Decoding Software For discussion of software applications which decode digital voice formats such as P25, NXDN, MotoTRBO, etc. Please use the HF Digital Signals forum for anything below 30MHz.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 02-11-2013, 10:37 PM
Member
   
Join Date: Mar 2010
Posts: 49
Default Bug fixes for dsd 1.4.1/mbelib 1.2.3

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.
Reply With Quote
Sponsored links
  #2 (permalink)  
Old 02-11-2013, 10:42 PM
scannerfreak's Avatar
Moderator
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Jul 2003
Location: Indiana
Posts: 5,565
Default

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.
__________________

Forum Rules and Guidelines

Last edited by scannerfreak; 02-11-2013 at 10:46 PM..
Reply With Quote
  #3 (permalink)  
Old 02-12-2013, 10:09 AM
rbrtklamp2's Avatar
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2005
Location: Dupage County, Illinois
Posts: 222
Default

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
__________________

Stop streaming public safety comms before encryption kills our hobby!

Last edited by rbrtklamp2; 02-12-2013 at 10:11 AM..
Reply With Quote
  #4 (permalink)  
Old 02-12-2013, 11:40 AM
Member
   
Join Date: Sep 2002
Posts: 550
Default

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??
Reply With Quote
  #5 (permalink)  
Old 02-12-2013, 11:45 AM
AZScanner's Avatar
Member
   
Join Date: Dec 2002
Location: Somewhere in this room. Right now, you're very cold.
Posts: 3,097
Default

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
__________________
Author of ActiveEMS - Phoenix Fire Now Free!
Coming soon: http://phoenixfirevideos.net
Incident Notification now in Beta on Twitter: @PhoenixFireVids
Reply With Quote
Sponsored links
        
  #6 (permalink)  
Old 02-12-2013, 12:50 PM
mtindor's Avatar
OH/WV DB Admin
  RadioReference Database Admininstrator
Database Admin
Amateur Radio Operator
Amateur Radio
 
Join Date: Dec 2006
Location: Jefferson County, Ohio
Posts: 4,816
Default

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
__________________
Mike / AA8IA
PSR800/PRO197/BCD436HP/BCD536HP

If I PM you about a submission, please reply promptly or your submission may be rejected.
Reply With Quote
  #7 (permalink)  
Old 02-12-2013, 1:45 PM
Member
   
Join Date: Dec 2005
Posts: 225
Default

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
Reply With Quote
  #8 (permalink)  
Old 02-12-2013, 4:12 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,360
Default

Quote:
Originally Posted by rbrtklamp2 View Post
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
Reply With Quote
  #9 (permalink)  
Old 02-13-2013, 12:52 PM
Member
   
Join Date: Sep 2002
Posts: 550
Default

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.
Reply With Quote
Sponsored links
        
  #10 (permalink)  
Old 02-13-2013, 5:52 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,360
Default

Quote:
Originally Posted by gary123 View Post
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.


Quote:
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.
Reply With Quote
  #11 (permalink)  
Old 02-14-2013, 2:34 PM
AZScanner's Avatar
Member
   
Join Date: Dec 2002
Location: Somewhere in this room. Right now, you're very cold.
Posts: 3,097
Default

Quote:
Originally Posted by slicerwizard View Post
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
__________________
Author of ActiveEMS - Phoenix Fire Now Free!
Coming soon: http://phoenixfirevideos.net
Incident Notification now in Beta on Twitter: @PhoenixFireVids
Reply With Quote
  #12 (permalink)  
Old 02-14-2013, 5:57 PM
inigo88's Avatar
California DB Admin
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Oct 2004
Location: Kern County, CA
Posts: 1,567
Default

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!
Reply With Quote
  #13 (permalink)  
Old 02-16-2013, 10:10 PM
Member
   
Join Date: Mar 2010
Posts: 49
Default

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
Reply With Quote
  #14 (permalink)  
Old 02-16-2013, 10:31 PM
mtindor's Avatar
OH/WV DB Admin
  RadioReference Database Admininstrator
Database Admin
Amateur Radio Operator
Amateur Radio
 
Join Date: Dec 2006
Location: Jefferson County, Ohio
Posts: 4,816
Default

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



Quote:
Originally Posted by dsdauthor View Post
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.
__________________
Mike / AA8IA
PSR800/PRO197/BCD436HP/BCD536HP

If I PM you about a submission, please reply promptly or your submission may be rejected.

Last edited by mtindor; 02-16-2013 at 10:37 PM..
Reply With Quote
  #15 (permalink)  
Old 02-17-2013, 4:31 AM
Seor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,930
Default

DSDAuthor - please check your PMs.

Quote:
Originally Posted by dsdauthor View Post
I don't seem to be able to edit the first post....
The forum has a 1 hour time limit for edits and typos.

Quote:
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.
Reply With Quote
Sponsored links
  #16 (permalink)  
Old 02-17-2013, 5:08 AM
Seor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,930
Default

Quote:
Originally Posted by mtindor View Post
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.
Reply With Quote
  #17 (permalink)  
Old 02-17-2013, 3:19 PM
Seor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,930
Default

Quote:
Originally Posted by Unitrunker View Post
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.
Reply With Quote
  #18 (permalink)  
Old 02-20-2013, 2:05 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,360
Default

Also, some of the NXDN bit scrambling sequence (nxdnpr[145]) is incorrect.
Reply With Quote
  #19 (permalink)  
Old 02-21-2013, 6:30 PM
AZScanner's Avatar
Member
   
Join Date: Dec 2002
Location: Somewhere in this room. Right now, you're very cold.
Posts: 3,097
Default

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
__________________
Author of ActiveEMS - Phoenix Fire Now Free!
Coming soon: http://phoenixfirevideos.net
Incident Notification now in Beta on Twitter: @PhoenixFireVids
Reply With Quote
  #20 (permalink)  
Old 03-04-2013, 5:01 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 129
Default

Quote:
Originally Posted by Unitrunker View Post
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
Reply With Quote
Reply

Tags
sticky

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 10:11 PM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2011 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions