How do people rate the various SDR software packages in terms of audio performance on P25 simulcast systems. I'm curious because I was surprised by the excellent performance of SDRTrunk when following a decoding a local P25P2 system.
SDRTrunk has good audio, is cross platform, and has a nice GUI, but it is a bit of a resource hog so best to run it on a decent spec machine.How do people rate the various SDR software packages in terms of audio performance on P25 simulcast systems. I'm curious because I was surprised by the excellent performance of SDRTrunk when following a decoding a local P25P2 system.
# os.environ['IMBE'] = 'soft'
I've not given much thought or effort to maintaining the ability to run the 'alternate' vocoder in multi_rx since the regular one works fine for 99.99% of people and it has a much cleaner code-path than the alternate implementation. That said, I would imagine it would be feasible to add tdma support to the alternate by reusing the trans-coding capability of the ambe.c/ambe.h module, much as is done now to get phase 2 codewords into the software decoder using the decode_tap() entry point.Two separate vocoders have been contributed to OP25 over time; and to my ear distinct differences between the two can be detected. For example a few users nearby have complained about a certain dispatcher sounding loud and distorted, a problem which cleared up by switching to the alt vocoder.
The ability to switch to the alt one doesn't apply in all cases. It only works for FDMA, not for TDMA (P2). Also it works only in rx.py, not in multi_rx (looks like the code is present but ignored in multi_rx). Arguably it should be (yet another) command line option, but currently to invoke the alt vocoder the following line in rx.py must be commented-out as shown here:
Code:# os.environ['IMBE'] = 'soft'
Max
Any tips on how to keep UT2 or SDRTrunk from grabbing all SDR dongles? Is there a way to allocate individual SDRs to a specific program?SDRTrunk is unmatched for P25P2 audio running natively on Windows, and the only alternative to DSD+FL as far as I'm aware (without having to install a clunky VM to run Linux for OP25). Rick has no plans to add P25P2 audio decoding anytime soon, if not for years yet.
I'm running SDRTrunk decoding 4 P25 sites (3 TDMA + 1 FDMA), with Trunking Recorder importing all of the audio for the built-in web interface, with Unitrunker 2.1 signal decoding all 4 of those sites. This is all running on a 2012 era i7 3770S with 16 GB of RAM. Total CPU usage rarely gets above 30% even with 12+ traffic channels concurrently decoding in SDRTrunk. Java is a little RAM hungry, and that can balloon to 3+ GB used, but so far it hasn't been much of an issue. I restart SDRTrunk every couple of days to keep things running smoothly.
Unitrunker does not capture dongles unless they are actively running in the software. The same is not true with SDRTrunk, which will lock up every inactive dongle it finds when you start the software.Any tips on how to keep UT2 or SDRTrunk from grabbing all SDR dongles? Is there a way to allocate individual SDRs to a specific program?
My installed version of UT2.1 (I think I'm one version behind) will start any SDR it finds in its previous state. I'll try shutting down the SDRs before I quit the program. I don't want to delete the radios if I don't have to.Unitrunker does not capture dongles unless they are actively running in the software. The same is not true with SDRTrunk, which will lock up every inactive dongle it finds when you start the software.
There is no way to allocate dongles to a specific program. The only workaround is to start Unitrunker first, run any dongles you want to use with that software, then start SDRTrunk and let it capture the remaining dongles.
Also note that once SDRTrunk is running, there is no way to either release a captured dongle or add additional dongles. Whatever the software found and captured when it first started up is what you get, until you repeat the process.
Right, any receivers you leave running before shutting down Unitrunker will start back up again. That is different than the software inherently capturing them upon startup as SDRTrunk does; you are causing the condition, not the software. Either stop the receivers before shutting down Unitrunker, or just stop them once the software is running and before starting SDRTrunk.My installed version of UT2.1 (I think I'm one version behind) will start any SDR it finds in its previous state. I'll try shutting down the SDRs before I quit the program. I don't want to delete the radios if I don't have to.