DSD 1.3 and mbelib 1.2 released

[mostar]

first, thanks to dsdauthor for a spectacular piece of work. this is arguably the most significant software to hit the scanner world since the motorola trunking code made its way to usenet in '97...

second - a quick question about using EDACS-capable scanners, such as the PSR-500 or 996XLT, with DSD. since these units cant natively decode ProVoice, i'm assuming that whenever they detect a ProVoice talkgroup that they would filter or ignore it, and refuse to follow it. if that is the case, i'm guessing you would not be able to use a stand-alone scanner with DSD on a ProVoice system? or is there a way to force any of these units to go ahead and follow a ProVoice talkgroup, like you can with Unitrunker (which is in my top-three list of best-ever pieces of scanner software)?

thanks.

 

[Jay911]

im using a laptop, so im stuck with the MIC input. If I have issues with it, i'll use a spare optiplex that has a line input.

Your laptop may have an option in the mixer settings for selecting whether that's used as a mic in or line in. My netbook does (and so does my Vaio, the linux machine I'm using).

 

[Jay911]

second - a quick question about using EDACS-capable scanners, such as the PSR-500 or 996XLT, with DSD.

When in trunking mode, most if not all scanners automatically skip ProVoice talkgroups - they don't even tune the scanner to that frequency. So there's no way to automatically hear the ProVoice if your scanner is in trunking mode. If you tune the channels in conventional mode, that should work.

 

[mhzscan]

Thanks J - Got it working at 97% with the MIC input. Had to reboot in order for it to take the audio settings

 

[paparazzo]

TETRA Decoding possible?

Dear DSDAuthor,

dou you think that there is a possibility to implement TETRA decoding in dsd?
If you need some recordings of TETRA Signals i may manage this for you.

TETRA is a big thing over here in europe now and lot's of agencies and departments
are going to switch over to it now and leaving the analog systems.

So there is a big black hole in Europe now, and maybe you are the right person
to fill it with light ;-)

Regards,
Jochen

 

[SCPD]

One problem with using a cheap scanner to decode Tetra is the bandwidth of the final IF. 15 kHz is typical for these radios but Tetra uses 25khz. In other words, you've lost some of the signal before it reached the software.

 

[paparazzo]

Okay, understood,

but there are scanners available on the market providing the possibility to
switch the if bandwith wider like the aor ar-5000.

Maybe this will work than.

Regards, Jochen

 

[MattSR]

With respect Rick, I understand and agree with your point but it seems a bit out of place in the thread?

 

[EricCottrell]

Hello,

There seems to be a problem using 64 bit Linux. The programs compile. I get no sound using the Provoice samples on a 64 bit Debian system and 64 bit Ubuntu system. Saving to a wav results in a audio file with silence. I do get sound when I play the Provoice samples with the program compiled on a 32 bit Debian system.

73 Eric

 

[Giulio]

Here is my little contribution, hoping it could be useful.
It's a MotoTRBO recording from an unid local station in Turin, Italy.

MEGAUPLOAD - The leading online storage and file delivery service

Don't know if it contains voice or data or idle frames.
Looking at the image it seems that transmissions happens at regular intervals.
Audio file has been cleaned as much as possible from non signal portions.

My thanks to DSD and MBELIB authors and every contributor.

Giulio

 

[dwc]

I would like to ask those of you who have this working 100%, what type of sound cards are you using?

If you could include the name of the sound card and driver (emu10k, via82xx, sb16, cmi8xxx, etc) that would be great.

Thanks,

dwC

 

[SCPD]

MattSR - I'm not saying "don't do it". Some users won't understand why they can decode signal A but not B. I've spent the last six years explaining to users the extra effort needed to get a decent P25 signal when EDACS and Motorola decoding work fine.

I foresee the DSD wiki page explode into multiple pages to cover the nuances and requirements of each protocol.

 

[EricCottrell]

Hello,

I was able to compile on a 32 bit linux platform and got P25 working.

However I can not decode Provoice using the -fp option. I tried several computers and radio setups that can decode both P25 and EDACS control channels. Very seldom I get a momentary audio noise. If I use the -s option I can see the two peaks of the GFSK signal. It appears no sync occurs because the # characters do not move and the text fields remain blank. I tried different audio levels and only the peaks in the -s display move.

Has anyone decode Provoice on an EDACS Extended Addressing system? I seem to remember Provoice data polarity is inverted on an EDACS system. There does not seem to be an invert option for Provoice.

73 Eric

 

[MattSR]

Rick - cool, I see what you're getting at, I just wasn't sure what angle you were coming from. The best bit about TETRA is that the specs are completely open - including the voice codec.

It's very hard to get people to understand why C4FM is several orders of magnitude harder to decode than simple 2 level FSK. With OP25, we have got two decoders in use, they're both about 80% of the way there but they're definitely not perfect!

 

[EricCottrell]

Hello,

I looked over some bit captures that I did last year on the EDAC EA system. I was able to match up the spacer bits and the 16 bits between the two sets of IMBE frames. The interesting part is I have a different header from what is mentioned in the other thread. Also some values alternate between two values.

94 D8 35 23 0E BF 33 33 69 69 69 69 69 69 69 69 A8 00 08 5D 75 AA Vo Vo Vo Vo ... 21 75 Vo Vo Vo Vo Vo ...
94 D8 35 23 0E BF 33 33 69 69 69 69 69 69 69 69 44 75 C8 5D 75 AA Vo Vo Vo Vo ... 21 75 Vo Vo Vo Vo Vo ...

I am going to modify the program after I get some sleep to see if that fixes my decoding problem.

73 Eric

 

[systron]

VSELP Linux Codec

here is a linux VSELP codec ( maybe useful) :

Speech Softwares by IKEDA Mikio

(VSELP Speech Codec)

 

[EricCottrell]

I looked over some bit captures that I did last year on the EDAC EA system. I was able to match up the spacer bits and the 16 bits between the two sets of IMBE frames. The interesting part is I have a different header from what is mentioned in the other thread. Also some values alternate between two values.

94 D8 35 23 0E BF 33 33 69 69 69 69 69 69 69 69 A8 00 08 5D 75 AA Vo Vo Vo Vo ... 21 75 Vo Vo Vo Vo Vo ...
94 D8 35 23 0E BF 33 33 69 69 69 69 69 69 69 69 44 75 C8 5D 75 AA Vo Vo Vo Vo ... 21 75 Vo Vo Vo Vo Vo ...

I am going to modify the program after I get some sleep to see if that fixes my decoding problem.

73 Eric

Hello,

I changed the sync to 94D83523 and now I am getting good decodes for ProVoice on the local EDACS EA system. I suspect the changes support the increased number of identifiers available in the EDACS EA system.

Another problem I noticed is that a segment of the transmission will sometimes be repeated at the end.

73 Eric

 

[SCPD]

Thanks Eric. That implies ...

1. the IV is moved four bytes further down in the frame
2. the LID field is also moved down four bytes
3. the LID looks to be larger eg. 20 bits instead of 16

The "2175" value that separates the two IMBE cell pairs- is the same as the "classic" ProVoice frame sync of "5712" value - but with the digits in reverse. The engineers changed the header but retained the structure and format of the "payload" portion of the voice frames. Interesting stuff.

Back to the LID field in the header. In the published specs for ProVoice - the 16 bit LID field is used to send out 32 bit code words (you need two consecutive frames to get the whole code word). The code word implicitly contains an 8 bit color value. The 12 least significant bits are BCH or Golay protection (I forget at the moment). The total bits in the codeword are therefore 40 bits.

Assume the EA ProVoice headers expanded the LID field to 20 bits. Two consecutive LID fields could be combined into a 40 bit code word. Might they have done away with the implicit color code to continue using the same error protection mechanism?

Food for thought while you're staring at raw binary dumps.

 

[Jay911]

I'm still having trouble getting the program to decode audio I've recorded from my local systems. As I said earlier, I can't run my Linux machine within range of the systems that will work with the program. So I am recording from a discriminator-tapped BC245 into Audacity on my WinXP netbook, then (after editing the sound file so that the actual transmissions are separated out) playing the transmissions into the Linux machine via a patch cord from the netbook to the Linux box. I had issues with the volume levels originally, but I thought I had adjusted it to a suitable level (as far as the waveform showing in Audacity indicated). When I pipe these files into the program as described above, though, I just get bleeps and burbles and no valid voice traffic.

I had tried recording TRBO and some P25 voice traffic when the volume was too high. The next day when I had my volume set better, I could only get a reliable P25 signal. (There's no ProVoice near me.) Again, the P25 comms don't decode. I'm going to attach the raw (discriminator output) P25 wav files to this message. (EDIT: I'm going to upload them to my personal webspace because the attachment function won't accept the size of the (1.01mb) zip file. Go to http://www.jay911.org/radio/753f-p25.zip.) Could someone assess them and see if I still have the volume set wrong, or not a clean enough signal, or a bad tap, or what?

Thanks in advance.

 

[js_scan888]

Jay911,

1st problem: The WAV file is recorded at 44100 Hz instead of the required 48000 Hz.
2nd problem: That is not a P25 transmission. That is a 2 level FSK signal.

Do you have Motorola Astro (VSLEP) digital systems up there ?