DSD 1.3 and mbelib 1.2 released

[offsite]

*Jay911

..sorry.... multiplexing

 

[gariac]

So tonight I had a brainstorm. As I was installing Wube or whatever that small install was that was mentioned in another thread, to let Ubuntu live on my netbook alongside XP, I was fiddling with my XTS3000.. my ASTRO-capable-and-programmed XTS3000.
.

Does the netbook have a line input. Today all you find are microphone inputs. If you put a three pin mini to RCA cable on the "input", you would find about 3.5V DC on one of the RCA plugs. This is to power the external microphone. The other is a low level input. My recollection is the DC is on the left plug and the microphone is on the right plug.

In any event, I don't recall seeing a post of dsd running on Intel HDA, which is what most laptops use these days. The old AC07 worked fine with linux programs, but not HDA.

 

[redhelmet13]

[I started with Wubi, just like you, but soon transitioned to the bootable/persistant thumb drive approach... because i can run it on (almost) any machine that will boot from a USB port... plus i don't have anything on the machines' HDDs to clutter them up. One negative is it takes a looong time to boot, but once it does, everything runs just great, even on a netbook!

-rb-[/QUOTE]
Forgive me since I am completely new to Linux etc... Ubuntu can be loaded on a thumb drive? My system is able to boot to a USB device... I also have USB external hard drives which may be the better approach.
I dont have any room on my system drive (all available space is partitioned and is assigned as logical drives).

 

[offsite]

bootable/persistant USB Thumbdrive

http://forums.radioreference.com/tr...-unitrunker-ubuntu-10-4-wine.html#post1314503

The above worked for me empirically... but there are others here who, unlike me, actually know stuff about about this topic and might have better advice...

-rb-

 

[Comint]

Someone throw me a hint on how to get a good screencap of xoscope running and I'll try this again and post the result.

You could try Gadwin Printscreen, which is freeware. Just remember to change the image type from the default BMP to PNP.

NOTE: The link points to the Download site.

--
Comint

 

[Sjinndoawi]

To Bad

Looks like I will have to let this program pass by since all of my other Radio programs work on windows just great. To bad this wont get ported to windows.

 

[AZScanner]

Looks like I will have to let this program pass by since all of my other Radio programs work on windows just great. To bad this wont get ported to windows.

I'm beginning to think it can't be ported and that's why we haven't seen it yet.

Windows is a bugger when it comes to talking directly to hardware. It really keeps you away from it as much as possible. For most applications, that's a good thing because you just write for the windows API and it handles all the different types of hardware people stuff into their computers. But for real time decoding, we really would need to get Windows to let us at the hardware itself for the sake of conserving resources and maximizing speed. Windows doesn't play well with that idea.

Now, could an offline decoder be written? One that you feed recorded discriminator audio to that it reconstructs into intelligible audio? The short answer is yes - I've SEEN IT DONE, and it was done in qbasic of all things (don't ask, I'm not allowed to share). Damn if I could get it to decode anything other than the samples it came with, but it most undoubtedly worked. I was very impressed. I tried like hell to port it to VB but I sucked at it, and gave up. Once in a while I kick it around again, but that's usually short lived and never results in much more than a cool looking program that doesn't work.

I'm sure someone with a good working knowledge of C++ could make use of the DSD source code to do the heavy lifting on recorded audio files. I wish I knew how, because if I could write that, it would be the stuff of scanner legend, but alas, I learned VB instead of C, and even there, my knowledge is pretty limited (read - nil) when it comes to hacking into wav files and turning them into individual bits, symbols and frames. Even the guy who wrote MDTMon back in the day wrote a DLL in C to handle the decoding because VB was just WAY too slow at it.

Maybe when I win the lottery and retire, I'll take some C++ classes and have a go at it. Then again, maybe not.

-AZ

 

[SCPD]

I'm beginning to think it can't be ported and that's why we haven't seen it yet.

*giggle* Thanks Phil - that was funny.

Windows is a bugger when it comes to talking directly to hardware. It really keeps you away from it as much as possible. For most applications, that's a good thing because you just write for the windows API and it handles all the different types of hardware people stuff into their computers. But for real time decoding, we really would need to get Windows to let us at the hardware itself for the sake of conserving resources and maximizing speed. Windows doesn't play well with that idea.

That really does not apply here. You're talking buffered audio in this case, not direct manipulation and sampling of pins on a serial port. Unless you're running multiple instances of DSD, I don't think performance is an issue.

The DSD code needs to be re-factored to continue to evolve on Linux as much as any other platform. The audio data is "pulled" via blocking reads to the /dev/audio device. Replacing this with an asynchronous IO model where audio sample data arrives in chunks allows concurrent IO to other devices like disk and keyboard so that the program can become interactive.

The rest of the code should port to Mac or Windows just fine.

 

[CrazyCalifornian]

I've been looking for that qbasic program for a few years, but no luck...
Can you tell me what the filename is?

I've been toying with the idea of trying to get DSD working in Windows too

Thanks,
Jay

 

[SCPD]

I've been looking for that qbasic program for a few years, but no luck...
Can you tell me what the filename is?

p25demo.bas (or something like that). Send me an email, I'll forward a copy.

I've been toying with the idea of trying to get DSD working in Windows too

This pair of links seem to suggest an IMBE codec for Windows already exists.

 

[CrazyCalifornian]

Rick,
Email sent to your hotmail address...

Many thanks,
Jay

 

[SCPD]

Email sent to your hotmail address...

Try gmail - I don't have a hotmail address.

 

[mtindor]

Try gmail - I don't have a hotmail address.

ROFL. You're a funny guy

 

[CrazyCalifornian]

Oops, meant the uni... at yahoo.com

 

[Sjinndoawi]

Give it a TRY Jay

You would be the "MAN" for that Jay!! If I was as gifted as you or Rick in writting code I would give it a try but I am not. It would be a Great Program (DSD)
to have ported to windows.

Brian

 

[KA1RBI]

p25demo.bas (or something like that).

Damn if I could get it to decode anything other than the samples it came with, but it most undoubtedly worked. I was very impressed.

Yes, it was quite impressive. It had a unique graphical display of the symbol demodulation progress - would be nice to see that carried forward too. I can tell you that in op25-dev our first-generation C++ IMBE decoder was "inspired" by that prog. In fact, I can tell you that it was believed to be 100% bug-for-bug compatible with it! The 4fsk demodulator was *very* stubborn about not demodulating anything other than the samples it came with all right. I was starting to think that they'd been "doctored" somewhat. It would have been nice to get that to work with arbitrary samples, since it only required an 8K sample rate. Today we take 48K for granted...

73

Max

 

[CrazyCalifornian]

Well, since Rick has the QB version buried on an old HD, if someone else could send it to me at (my RR.com ID) at hotmail dot com or at cox dot net, I'd appreciate it as it would also free up his time looking for it

Thanks,
Jay

 

[dsdauthor]

As promised, here are updated versions with some minor features/bugfixes. Several folks have offered to provide OpenSKY .wav files but have not sent download links yet. I would really like to add OpenSKY support if it turns out to be possible. .wav files will also be required for any other formats (Astro VSELP for example) to be considered. All .wav files should be in 48k/mono/16bit from a good discriminator tap. The more minutes of speech transmissions the better (including before a transmission starts through after it ends).

Note: the ProVoice EA sync has not been tested, let me know if it works. It will display the same as regular ProVoice so you will have to know which type of system you are testing it on
to confirm.

I have updated the Wiki with the new download links.

DSD 1.3.1 New features:
Support for ProVoice EA sync
CTRL-C is now caught so .wav files can be properly closed
DSD now shows mbelib version as well as it's own version
-R resume option now triggers on any TSDU so control channels can be left
in conventional scanlists.
Auto output gain now has 0.5 second hold time for faster error burst recovery
(was 1.5 seconds)
Audio output upsampling function simplified and improved

DSD 1.3.1 Fixed bugs:
DSD_Author.pgp now has correct public key (was copy of mbelib_Author key)
TGID and SRC are now cleared after TDULC or TDU.
Voice error counter is now reset in noCarrier()
TGID and SRC were not displaying for X2-TDMA frames
Fixed buffer issue in resumeScan()
Fixed error in .wav file headers preventing playback on some apps

mbelib 1.2.2 Fixed bugs:
uninitialized variable in SpectralAmpEnhance()

I also installed Ubuntu 10.04 64bit onto a Dell inspiron 1501 laptop and did not have any problems with speech output. It is possible that the bug fixed in mbelib-1.2.2 was causing unpredictable effects on some systems. One thing I noticed about Ubuntu is that it set the gnome visual effects fairly high by default. On systems with limited cpu you should disable all visual effects in the display settings. I also set the font in the terminal window to use a fixed width non antialiased font to save cpu.

Several posters in this thread appear to have sub-optimal discriminator taps and/or receivers. It is important that the tap provide as much audio bandwidth as possible. I use a large capacitor in my taps (no resistors) and that seems to work very well. You may even be able to use no capacitor if your soundcard has input buffering already. In any case the waveform edges should appear very squared off for Motorola control channel signals (which are 2 level). There should be four distinct levels on C4FM signals and the transitions should be fairly squared off. There should not be any high frequency noise with a clean strong signal either.

The vertical bars in DataScope mode (-s) should be equally spaced. I have one scanner with a damaged discriminator that shows the right most bar very close to the next bar on QPSK signals and does not decode QPSK because of that even though it does fine with the narrower C4FM. I probably would not have discovered what the problem was without the DataScope view.

Not all scanners are created equal. I have found that the best scanners for DSD are (surprise!) digital scanners. Many analog scanners have very poor discriminator tap output, especially the cheaper ones.

There seems to be some confusion about the "input %" display in the default errorbars display mode. That indicates the input audio volume not % of successfull decode. The optimal level may vary between radios/soundcards but usually the best setting is between 40% - 60%. If you scan both C4FM and QPSK (LSM) systems you can set the input level for 40% on C4FM and the QPSK will come in around 60%.

 

[AZScanner]

Well, since Rick has the QB version buried on an old HD, if someone else could send it to me at (my RR.com ID) at hotmail dot com or at cox dot net, I'd appreciate it as it would also free up his time looking for it

Thanks,
Jay

I think you'd be much more successful trying to port DSD than getting that old QB thing working. I looked for it and I think I got rid of it. I don't have it here on this PC, but I might at home. At any rate, don't hold your breath getting that QB thing to decode anything other than the file it came with.

-AZ

 

[AZScanner]

Replacing this with an asynchronous IO model where audio sample data arrives in chunks allows concurrent IO to other devices like disk and keyboard so that the program can become interactive.

The rest of the code should port to Mac or Windows just fine.

Would your old capture.cpp serve as a good starting point for this? With the long weekend coming up, maybe I could take a crack at it.

-AZ