DSD 1.6? Closed fork or open source

[n4yek]

Originally Posted by slicerwizard

1. Auto mutes P25 encrypted signals by default, run with option -pu to unmute if you want the r2d2 sounds.

Also fairly easy........ and in the LDU functions, preface the processMbeFrame calls with if (state->P25KID == 0)

Sorry for stupidity,
I am lost when it come to this step, you say preface, is it suppose to look like this:

if (state->P25KID == 0)
processMbeFrame (opts, state, imbe_fr, NULL, NULL);

or
processMbeFrame (opts, state, imbe_fr, NULL, NULL);
if (state->P25KID == 0)

thanks.

[mtindor]

Originally Posted by n4yek

Sorry for stupidity,
I am lost when it come to this step, you say preface, is it suppose to look like this:

if (state->P25KID == 0)
processMbeFrame (opts, state, imbe_fr, NULL, NULL);

or
processMbeFrame (opts, state, imbe_fr, NULL, NULL);
if (state->P25KID == 0)

thanks.

The first one.

Mike

[n4yek]

Thanks, wanted to make sure.

[gariac]

I completely forgot about the mbe part of the program, which is why I couldn't find the golay table. [I did look at every dsd file before throwing in the towel and posting my question.]

Is the array size of 2048 sufficient? And then I have to ask if we add more data to the table, isn't there some index limit that needs changing? Otherwise how does the new data get read?

BTW I've looked at a lot of the compiler warnings. They appear legit, but not significant. Things like variables passed to functions that don't get used.

[blantonl]

These updates and changes should definitely be added to the Wiki.

[mtindor]

Originally Posted by gariac

Is the array size of 2048 sufficient? And then I have to ask if we add more data to the table, isn't there some index limit that needs changing? Otherwise how does the new data get read?

Since I'm not a programmer, I'm probably not qualified to answer. However, if there are no more than 2048 elements in the array with a size of 2048, I'm pretty sure we're safe in that regard.

The data _must_ be getting read since the program does not crash after this fix is applied. Without the fix, it only takes a short amount of time sitting on a TRBO control channel for it to crash out.

BTW I've looked at a lot of the compiler warnings. They appear legit, but not significant. Things like variables passed to functions that don't get used.

Clean it up and release some updated source if you have the abilities. Fork it, spoon it, whatever.

Me? Well, I'll just use it and enjoy it until it's no longer useful. It's been pretty useful since the first day it was released though.

Mike

[mtindor]

Originally Posted by blantonl

These updates and changes should definitely be added to the Wiki.

Aww shucks. I just checked the Wiki, and it doesn't look like you added them yet

I've got modified source that works just fine, but every person who has touched the DSD source and who then has released the updated source or an updated binary seems to disappear. I wouldn't even attempt to put any updated source online anywhere. I'm putting on my tin foil hat.

If your suggesting that somehow all of these instructions be put in an article so that somebody can grab the pristine DSD / mbelib source and compile it with these fixes or updates, I concur. But I don't like wiki editing.

Mike

[gariac]

I don't know. GITMO is nice and warm, even in the winter.

Given the lack of people willing to wear orange jump suits, is it possible to have a test suite to verify the program is working properly? Something like wav file in to wave file out. A bug (as in modification error) in the raise cosine filter would probably cause a soft error, but the percent accuracy decode might catch an error.

Come to think of it, some time ago I did a thread where I found that redirecting the input file to dsd wasn't the same as using the soundcard. I had to put the stored audio on a mp3 player (which does wav) and then sample it again. This was for trbo decode.

So there may be one more bug lurking.

[jhampton2000]

Originally Posted by Unitrunker

Audi is only needed for the install.

Sorry, I don't understand this comment......was this directed at the instructions I posted, and if so, have I made a mistake? Just keen to make sure that I understand how the changes to the C code get compiled/installed into a new DSD executable in the right way: I'm a noob at this, so any help appreciated.

Jim

[Unitrunker]

It was. Autocorrect got in the way.

sudo is only needed for the install. You don't need super user access to compile.

[Unitrunker]

Originally Posted by blantonl

These updates and changes should definitely be added to the Wiki.

A shopping list of manual edits is not the way to go. Someone could create a set of patch files, or - even better - use Github as it was intended. (Sorry, that someone won't be me.)

Seriously though, is 50 monkeys independently typing out the same edits a good idea?

[slicerwizard]

Originally Posted by jhampton2000

So I really appreciate the work on this and info from slicerwizard....like Mike, I'm not an expert when it comes to (re)writing c code, so I'd sure appreciate if someone could verify i have the right steps here

Yep, that all looks good.

Originally Posted by mtindor

For anyone adding these features based upon what Slicer said, you might also want to include a 'fix' from ericcottrell in another post:

DSD 1.4 and mbelib 1.2.3 released

Mike

Yep, definitely add that as well.

Originally Posted by mtindor

Since I'm not a programmer, I'm probably not qualified to answer. However, if there are no more than 2048 elements in the array with a size of 2048, I'm pretty sure we're safe in that regard.

Golay FEC data and the syndromes produced from it are 11-bit data, so exactly 2k table entries are required/used.

[Unitrunker]

This fixes DSD to link properly on cygwin. This applies only to the DSD makefile, not the mbelib makefile.

I'm using GCC 4.

Locate the dsd build rule in the makefile (search for the line that starts with "dsd:").

The line beneath it links the object files to produce the DSD executable.
On cygwin, this will likely fail because - for reasons unknown - cygwin in sensitive to placement of the link arguments. So, replace ...

$(CC) $(CFLAGS) $(LIBS) -o dsd ($OBJS)

... with this ...

$(CC) $(CFLAGS) o dsd ($OBJS) $(LIBS)

In other words, move the "LIBS" reference to the end of the command.

Other quirks from building under cygwin aren't as critical.

The audio device under cygwin is "/dev/dsp", not "/dev/audio" which is the default. To make life easier, edit dsd_main.c to replace all references to "/dev/audio" with "/dev/dsp". Otherwise, you have to remember to supply the correct device name at the command line every time you run dsd.

[mtindor]

Thanks Andrew, and Rick, for the info.

If somebody were to decide to update the source [i.e. learned how to do the github thing I suppose], then I guess a question remains as to whether it should still be DSD and then, what eversion it should be if all of the above were added in.

Woodpecker had done a few other things [probably small but maybe not] that aren't mentioned above for manual editing. One of them was the /dev/dsp changes [because he was building specifically for Windows] and things like the -ff switch [and then later, having the filter on by default and using -l to turn it off].

So it would be nice for somebody who is used to doing these things to suggest whether or not the name / version stuff needs changed as part of the process of providing updated source online.

mike

[mtindor]

And then one has to consider the reason why the previous maintainers have not continued to update the code and have totally disappeared. I'm a bit paranoid about that. If one of us were to take that source and make updates and release those source updates [using Github I suppose], are we then suddenly culpable if there are any pending patenting / licensing issues? Seems to me that this must be the case. I get a feeling that everytime somebody [including Binome] tried to improve upon things, heat came upon them from somewhere and then they disappeared from the face of the earth [figuratively].

I wouldn't want anyone to suggest that others get themselves in hot water, if there is any hot water to get into.

Mike

[Unitrunker]

Andrew - thanks for putting this together.

Originally Posted by slicerwizard

1. Auto mutes P25 encrypted signals by default, run with option -pu to unmute if you want the r2d2 sounds.

Also fairly easy. Encrypted audio will have non-zero values in the HDU KID field, so just save that KID value and only decode P25 audio if KID==0. So add int P25KID to the state structure and in p25p1_hdu.c, after skipDibit (opts, state, 160);, add state->P25KID = strtol(kid, NULL, 2); and in the LDU functions, preface the processMbeFrame calls with if (state->P25KID == 0)

The ALGID and KID are also updated in LDU2. The changes you suggest for p25p1_hdu.c also apply to p25p1_ldu2.c. The dsd_state structure already has members for "algid" and "kid". They're ASCII, but do exist. The downside is the code to gather ALGID and KID bits doesn't take advantage of the available error correction bits. The ALGID is only 8 bits so - in theory - it is less likely to succumb to false bit values. The ALGID value for unencrypted voice is $80. Applying bit correction would be ideal.

I sit between two P25 sites - one that is 99% clear and the other is 99% encrypted so I can test this out.

Originally Posted by mtindor

So it would be nice for somebody who is used to doing these things to suggest whether or not the name / version stuff needs changed as part of the process of providing updated source online.

I think gariac's objection that DSD1.6 (sometimes called DSD4WIN) should not be called DSD because of a lack of source. The edits we're describing here could certainly be considered DSD.

[mtindor]

Some problems with compiling this stuff [on Windows] looks like Makefile issues. But if the Makefile is modified, I have no clue if it'll still make on Linux. I'm only compiling on Windows.

For instance, for me to compile any of this on Windows [even after Rick's Makefile fix for the Makefile in dsd], I have to do this:

1. ensure /usr/local/lib/ and /usr/local/include/ directories exist [under cygwin of course]
2. cd to the mbelib source dir
3. make
4. if it makes alright, do a 'make install'

That'll put the revelent mbelib files in /usr/local/lib/ and /usr/local/include/

If one fails to make sure /usr/local/lib/ and /usr/local/include/ directories are created beforehand, the 'make install' of mbelib will copy each of the required files to a filename called /usr/local/lib or /usr/local/include, instead of copying the actual files as new files into /usr/local/lib/ and /usr/local/include/

5. copy over *.o from the mbelib source directory to the dsd source directory
6. run 'make'

make will fail:

gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_main.c -o dsd_main.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_symbol.c -o dsd_symbol.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_dibit.c -o dsd_dibit.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_frame_sync.c -o dsd_frame_sync.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_file.c -o dsd_file.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_audio.c -o dsd_audio.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_serial.c -o dsd_serial.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_frame.c -o dsd_frame.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_mbe.c -o dsd_mbe.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dsd_upsample.c -o dsd_upsample.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c p25p1_hdu.c -o p25p1_hdu.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c p25p1_ldu1.c -o p25p1_ldu1.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c p25p1_ldu2.c -o p25p1_ldu2.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c p25p1_tdulc.c -o p25p1_tdulc.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c p25_lcw.c -o p25_lcw.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c x2tdma_voice.c -o x2tdma_voice.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c x2tdma_data.c -o x2tdma_data.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dstar.c -o dstar.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c nxdn_voice.c -o nxdn_voice.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c nxdn_data.c -o nxdn_data.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dmr_voice.c -o dmr_voice.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c dmr_data.c -o dmr_data.o
gcc -O2 -Wall -I. -I/usr/local/include -I/usr/include -c provoice.c -o provoice.o
gcc -O2 -Wall -L/usr/local/lib -lm -lmbe  -o dsd dsd_main.o dsd_symbol.o dsd_dibit.o dsd_frame_sync.o dsd_file.o dsd_audio.o dsd_serial.o dsd_frame.o dsd_mbe.o dsd_upsample.o p25p1_hdu.o p25p1_ldu1.o p25p1_ldu2.o p25p1_tdulc.o p25_lcw.o x2tdma_voice.o x2tdma_data.o dstar.o nxdn_voice.o nxdn_data.o dmr_voice.o dmr_data.o provoice.o
dsd_main.o:dsd_main.c:(.text+0x22a): undefined reference to `_mbe_initMbeParms'
dsd_main.o:dsd_main.c:(.text+0x831): undefined reference to `_mbe_initMbeParms'
dsd_main.o:dsd_main.c:(.text+0xc72): undefined reference to `_mbe_printVersion'
dsd_frame.o:dsd_frame.c:(.text+0x66c): undefined reference to `_mbe_initMbeParms'
dsd_frame.o:dsd_frame.c:(.text+0x9b8): undefined reference to `_mbe_initMbeParms'
dsd_frame.o:dsd_frame.c:(.text+0xab5): undefined reference to `_mbe_initMbeParms'
dsd_mbe.o:dsd_mbe.c:(.text+0x72): undefined reference to `_mbe_initMbeParms'
dsd_mbe.o:dsd_mbe.c:(.text+0x14c): undefined reference to `_mbe_processImbe4400Dataf'
dsd_mbe.o:dsd_mbe.c:(.text+0x1fd): undefined reference to `_mbe_processAmbe2250Dataf'
dsd_mbe.o:dsd_mbe.c:(.text+0x2b1): undefined reference to `_mbe_processImbe7100x4400Framef'
dsd_mbe.o:dsd_mbe.c:(.text+0x367): undefined reference to `_mbe_processAmbe3600x2250Framef'
dsd_mbe.o:dsd_mbe.c:(.text+0x40c): undefined reference to `_mbe_processImbe7200x4400Framef'
collect2: ld returned 1 exit status
Makefile:106: recipe for target `dsd' failed
make: *** [dsd] Error 1

So, if I run the following command it'll produce the dsd.exe

gcc -O2 -Wall -L/usr/local/lib -o dsd mbelib.o dsd_main.o dsd_symbol.o dsd_dibit.o dsd_frame_sync.o dsd_file.o dsd_audio.o dsd_serial.o dsd_frame.o dsd_mbe.o dsd_upsample.o p25p1_hdu.o p25p1_ldu1.o p25p1_ldu2.o p25p1_tdulc.o p25_lcw.o x2tdma_voice.o x2tdma_data.o dstar.o nxdn_voice.o nxdn_data.o dmr_voice.o dmr_data.o provoice.o ambe3600x2250.o imbe7200x4400.o ecc.o imbe7100x4400.o

Obviously an actual 'make' of dsd barks because of the -lm -lme parts on the gcc line. Omitting them and running gcc works fine.

And these are just things to deal with when trying to do this on Windows. Since I don't know jack about programming / compiling, I wing it. Any changes I make to Makefiles are likely going to break the make process in Linux. People who program know how to allow for these differences in the Makefiles. I don't.

BTW, I bring this up because I'm playing around with Git / Github and forked off the existing DSD so that I could play with it. Of course this probably isn't the way to go, since you also don't want 50 people forking off DSD and mbelib and having various different versions out there on Github.

It's a cluster no matter how you look at it. I think unless there is an actual 'maintainer' of one repository of dsd and mbelib, it's foolish to even go this route.

Mike

[n4yek]

Originally Posted by slicerwizard

1. Auto mutes P25 encrypted signals by default, run with option -pu to unmute if you want the r2d2 sounds.

Also fairly easy. Encrypted audio will have non-zero values in the HDU KID field, so just save that KID value and only decode P25 audio if KID==0. So add int P25KID to the state structure and in p25p1_hdu.c, after skipDibit (opts, state, 160);, add state->P25KID = strtol(kid, NULL, 2); and in the LDU functions, preface the processMbeFrame calls with if (state->P25KID == 0)

I have somehow mess this step up and can't for the life of me figure it out, I keep getting an error when I try to Make the file. I would be forever greatful if someone would actually type this up the way it should look in all three files.

[n4yek]

Don't everybody jump in at once now...

[EricCottrell]

Hello,

I last looked at this thread back in December and should have been following it. I also wrote my own fixes to 1.4 that were enumerated on this thread and added some more of my own. I need to compare the fixes with mine and pick up ones I missed.

I had problems under Linux using the OSS emulation with DSD so I added capability to use ALSA instead.

I found the DMR Filter significantly improves the decoding and I can get useful decodes on much more noisy signals.

I started to focus on data frame decoding. I got the data frame deinterleaved and the ECC code done for the CC and Slot Type. This lead to finding a possible problem with sync when decoding DMR control channels. Occasionally when it sounds like a channel grant is being sent, an unknown slot type error occurs, but slot type ECC errors also occur. This may indicate the program syncing to the wrong part of the data stream.

73 Eric