DSD 1.3 and mbelib 1.2 released

[schranze]

In my city I have may be 30 tetra frequencies . if you want records let know to european listeners

i have sampels form belgium for you , let me now

 

[gariac]

I ran DSD on an odd signal I heard in both Nevada (Nellis range and Vegas), and in California along I-15. I started a different thread since it is not strictly DSD MBE related.

http://forums.radioreference.com/tr...cc-nor-trunk-408-1875-nevada.html#post1349885

 

[gariac]

This thread is getting mighty unwieldy, but I'm not sure if I should start a new one.

Regarding this thread
http://forums.radioreference.com/tr...cc-nor-trunk-408-1875-nevada.html#post1349885

the one reply I got was by someone who indicated they are getting 100% on the decode. Best I can do is 45%. What we really need are some test files with the associated log file, just in the oddball case where some installed code is working but behaving a bit differently from the authors installed code.

As a code enhancement, it seems some sort of AGC wouldn't be that hard to add. For unknown reasons, my Audigy maximum sensitivity is different under windows and linux. I can drive it to 100% under windows but about 50% under linux. I'd hate to have to build an amp if software is an easier fix.

 

[SCPD]

DSD already has a form of AGC. You need to provide a healthy signal but the code will tolerate long term trends in amplitude.

 

[gariac]

I doubled the accuracy with a 6dB increase in signal level. No offense to the programmer, but I really don't think it has much of an AGC, if any at all.

Now it could be my compilation is not proper, which I why I thought a test bench would be a good idea. Not just a test signal, but some figure of merit to see if it is working properly. The log would be fine.

 

[AZScanner]

Adapting DSD to Windows shouldn't be that big of a problem...

Jay

Just curious - any luck with this yet? I've been way too busy to attempt it (and I doubt my noobish C++ skills would be sufficient anyway).

-AZ

 

[CrazyCalifornian]

Just have a VS6 project created so far, been busy with my other progs ...

Jay

 

[fourthhorseman]

Ill bump that,,
Spent alotta time tryingto get it wot find my sound card,,no luck since ive got a fickle notebook that love to have driver issues,,

fingers crossed for that windows version,,

 

[primehifi]

I don't see it mentioned, but will we be getting an update or has this project sunk to the underground.

 

[TampaTyron]

DSD Fearure request

DSD Author,
I have several Mototrbo radios and system at my disposal. I am the tech who works for one of the larger Motorola dealers in this part of the state.As someone who sells and services these systems, I say this is a great tool!!! Is there a way to determine the group id that the repeater is tranmitting? Thank you, Tyron.

 

[dsdauthor]

I don't see it mentioned, but will we be getting an update or has this project sunk to the underground.

I'm still around but I have been busy with other projects. Was there a particular feture or update you were looking for?

I am looking at some OpenSKY signals but if it turns out that they do encrypt all voice traffic then it will obviously not be supportable.

 

[primehifi]

I'm still around but I have been busy with other projects. Was there a particular feture or update you were looking for?

I figured as much, this project is greatly appreciated (and incredibly interesting) and I waited as long as I could stand it before saying something out of respect for your efforts.

Really all I, and I know a few others, are looking for is to see the AEGIS get demodulated.

 

[ilgrant]

I'm still around but I have been busy with other projects. Was there a particular feture or update you were looking for?

I am looking at some OpenSKY signals but if it turns out that they do encrypt all voice traffic then it will obviously not be supportable.

Maybe I'm reading too much into this...are you stating that you have received OpenSky samples and they are encrypted?

Thanks for sharing DSD.

 

[racingfan360]

DSDAuthor, can i also pass on my thanks for this program....it is simply fantastic to finally be able to listen to all those MotoTRBO signals: a new one seems to pop up now every month. I'd love to know if/when you plan to take forward voice demod of NXDN signals please?

Thanks again, Jim

 

[systron]

i hope for more supported codecs...

 

[systron]

and soon or later a I/Q input option for support of newer radios with I/Q output like the Alinco DJ-X11.

DJ-X11 Detail information

great job anyway. many thanks to DSDAuthor !

 

[dsdauthor]

DSDAuthor, can i also pass on my thanks for this program....it is simply fantastic to finally be able to listen to all those MotoTRBO signals: a new one seems to pop up now every month. I'd love to know if/when you plan to take forward voice demod of NXDN signals please?

Thanks again, Jim

I am focusing on NXDN right now. I have some OpenSKY samples but it is going to take alot of work to handle the CDPD-like frames and determine once and for all if the voice bits are encrypted as advertised.

It looks like there is no special interlave pattern, NXDN just has four voice frames concatenated together in one NXDN frame (with signalling bits). There is a bit modulation
however that is likely keyed off of the programmed color code. If anyone has access to the specification documents for this the algorythim for generating the bit modulation would be very useful. It may also be possible to infer the bit modulation from the buffer frame at the end of each transmission.

I'm going to try to get a hold of a radio again to generate some more test signals with. Transmitting a pure tone of a given frequency should put the voice codec in a special "tone frame" mode that generates a specific predictable bit pattern that would really help with
analyzing the bit modulations.

 

[js_scan888]

1) NXDN uses the same randomizer polonomial (X^9 + X^5 + 1) as the ETSI TS 102 490 standard, and the ITU-T O.153 standard. With experimentation, it can be determined that the starting point for NXDN voice data is at bit 180 of the 511 pseudo random bit stream. When applied to the received voice bits, 92 out of the total 288 voice bits will be inverted back to normal. The randomizer prevents long strings of binary 1's or 0's from occuring in the data stream which can cause timing issues.

2) The array Cik[5][11] in function mbe_decodeAmbe2250Parms is too small. This array needs to be set to Cik[5][18], because the indexes in the AmbeLmprbl array goes all the way up to 17. Data would be lost or some other variable data would be walked on because of this bug.

 

[dwc]

dsdauthor,

Out of curiosity, what kind of sound card are you using for testing? I am looking to replace my lousy AC97's with something a bit beefier and not so CPU reliant.

Thanks

dwC

 

[gariac]

I wouldn't dump AC97. Intel HDA (the next generation) is not very well supported in linux.