OP25 VirtualBox Project - Run OP25 on Windows 7

[boatbod]

Thanks Max.

The attenuation at the edges is due to the rational resampler block (i.e. -Z decimation). I can't explain why it does it, but if you take the resampler out of the data stream it it will run edge to edge.

Gridlines in my first fft attempt were being blocked by the "set object" clause which I eventually eliminated at the cost of a change in background color. I'm not a gnuplot expert, but I will investigate setting a black background without loss of other functionality.

One thing that could be done better is throttling the fft recalculation. I implemented a crude "one in fifty" counter because running it without throttling caused a huge cpu impact. Some sort of millisecond timer (e.g. 10 a second) would likely be a better solution if there isn't a native way of turning down the interval in gnuradio's sink processing logic.

 

[boatbod]

Max, I spent my evening working on an enhancement to the way the fft graph creates itself so it should be possible define a method "fft_sink::set_tune_freq()" that draws a vertical line at whatever frequency the demodulator is currently tuned to. My idea comes from a desire to (a) have a vertical line for the purposes of fine tuning the control channel and (b) in the case of someone using a center_frequency, know where in the spectrum the demodulator is currently pointed.

The only snag is I don't really have a way to test to code because the system I monitor is wider than one RTL tuning width. Looking inside rx.py in the area of p25_rx_block::change_freq() I see code that tells the p25_demodulator to set_relative_frequency() but curiously it never checks the return value and immediately goes on to call self.set_freq() which I suppose overrides things anyway. Bit confused about that...

So, two things I need to know:
- where in rx.py to place a call to self.fft_sink.set_tune_freq(frequency) in the case of relative tuning taking place.
- what I need to change in my config files (i.e. trunk.tsv) to configure center frequency tuning and then how to know if it works.

Thanks!

 

[Forts]

p.s. it is interesting to note that this entire scenario (users contributing improvements) would be impossible in DSD+

No disrespect but many many user suggestion improvements and protocol additions have been added to DSD+ (and UT) over the past few years. Sure, end users can't submit code but that's a very small section of the userbase that would have been able to do so. Same with UT, Rick is constantly working with feedback from the users.

OP25 for the vast majority is a platform they don't even look at as it's notoriously difficult to get running. And hasn't really changed much in recent years. Users these days want a pretty icon to click on and everything to just work... Most aren't even confident they can edit a .bat file let alone tackle something like OP25. For the power users it's great, but the available programs all bring something good to the table.

 

[boatbod]

OP25 for the vast majority is a platform they don't even look at as it's notoriously difficult to get running. And hasn't really changed much in recent years. Users these days want a pretty icon to click on and everything to just work... Most aren't even confident they can edit a .bat file let alone tackle something like OP25. For the power users it's great, but the available programs all bring something good to the table.

No doubt op25 does take some persistence to set up, but then I don't think anyone would claim that setting up Unitrunker, Virtual Audio Cable and DSD+ so that they all play nice together is particularly easier either.

 

[boatbod]

Max - I did get center_frequency to work, but it's definitely broken in it's current form when used on a system that does not fit fully inside the sample spectrum. The fix isn't too hard - mostly just enhanced error handling and fallback to center tuning. Once I get done testing my fft tweaks I'll shoot you another patch since they operate hand in hand.

 

[jonwienke]

No doubt op25 does take some persistence to set up, but then I don't think anyone would claim that setting up Unitrunker, Virtual Audio Cable and DSD+ so that they all play nice together is particularly easier either.

Which is the biggest factor holding back the popularity of SDR vs traditional scanners. You have to cobble together multiple software packages built by different developers who do not coordinate updates together (so updating one package often breaks compatibility with others). There is no unified design for user interface or application function, it's all a messy hodgepodge that is for the most part far less than the sum of its parts.

What would make far more sense is to take the functionality of DSD+ and make it a plugin for SDR# or a similar application that expanded its list of supported modulations from AM/FM/SSB/CW to include DMR, P25, Provoice, NXDN, D-STAR, etc. and update the host app to natively support multiple SDR devices so that the 2-receiver functionality for tracking trunked systems was natively supported, and scanning could be handled in parallel by as many as 8 SDR receivers so that scanning and frequency search speed was increased proportionally by the number of SDRs connected to the app. Add in audio buffering so you could hear simultaneous transmissions sequentially, and you'd have a killer app that would be a real threat to traditional scanner manufacturers.

But in its current fragmented state, SDR is never going to be more than a niche within a niche.

 

[boatbod]

Here is my "max branch" relative tuning patch.
https://drive.google.com/open?id=0B-9lC78gYedORnZPSldXU2lIdEE

It addresses two things:
- enhanced functionality to fft plot showing axis labels and tuning line
- bugfix/enhanced error checking for the existing relative tuning code to allow it to work when the sdr sample range is insufficient to cover the radio system without retuning the center frequency.

Black backgrounds for the various plots are still TBD.

 

[lukekb]

In p25_frame_assembler_impl::forecast()
Should the forecast change for the audio output depending on whether it is Phase 1 or 2, since the bitrate for P2 is 6000 instead of 4800?

Since 4800/8000 = 0.6, would it be 6000/8000 = 0.75 for Phase 2?

Also, I have been setting the output multiple in p25_frame_assembler_impl:25_frame_assembler_impl() because it helps alot with the CPU usage. Is that a bad idea? I have been using:

if (d_do_audio_output) set_output_multiple(864);

 

[boatbod]

In p25_frame_assembler_impl::forecast()
Should the forecast change for the audio output depending on whether it is Phase 1 or 2, since the bitrate for P2 is 6000 instead of 4800?

Since 4800/8000 = 0.6, would it be 6000/8000 = 0.75 for Phase 2?

Also, I have been setting the output multiple in p25_frame_assembler_impl:25_frame_assembler_impl() because it helps alot with the CPU usage. Is that a bad idea? I have been using:

if (d_do_audio_output) set_output_multiple(864);

Depends whether you are using the rx.py version or the older scope.py version. In the older software, any phase 2 forecast multiple larger than 0.5 results in choppy audio on my system. Setting multiples lower than 0.5 did not change the audio, but may affect cpu util.

My guess is that phase 1 will work just fine with a 0.5 multiplier too.

On the later rx.py version of op25, changing the forecast multiplier had no effect on audio output.

Sent from my SM-N920V using Tapatalk

 

[wisco_STEW]

Hello,

I'm glad to see op25 moving along.

I've been testing the latest updates. I had to make one small change (as directed by the compiler) to build on tumbleweed.

- if (isnan(symbol_error)) symbol_error = 0.0;
+ if (std::isnan(symbol_error)) symbol_error = 0.0;

I'm guessing this is not the source of my issue,

I'm thinking the issue i'm running into is the UDP pipe to aplay. Using the command as suggested in the README gives me no audio when i see voice messages from rx.py. I do not believe there is a firewall (disabled) getting in the way here. I'm unable to see any evidence of data being sent on 127.0.0.1 via wireshark.

Is the UDP audio pipe on P1 systems expected to be functional? Understand the system uses the "experimental additions for explicit format voice grant" commits, and had been working prior to the most recent "rx.py" changes removing the need for 14.04.

I've tested aplay on a wav test file and I am able to hear the audio correctly, So I do not believe this is a "pulse issue".

Commands used..

./rx.py --args 'airspy' -f 154.9875e6 -N 'RF:10,IF:9,BB:9' -S 10000000 -o 200.0e3 -q -0 -v 10 -t -w 2> stderr.2

nc -kluvw 1 127.0.0.1 23456 | aplay -c1 -f S16_LE -r 8000

Thanks for sharing.
Have Fun!

wisco

 

[boatbod]

Phase 1 or phase 2 system being monitored? If it's phase 2, you need to add "-2" on the rx.py command line.

Oh and you'll definitely need "-T 'trunk.tsv'" as well., regardless of phase 1 or phase 2.

These are the options I use for rx.py on a phase 2 system.
./rx.py --args "rtl=0" -P fft --gains 'lna:36' -D cqpsk -f 773.84375e6 -S 1440000 -q 0 -T trunk-leo.tsv -q 1 -2 -w 2> stderr.2

 

[boatbod]

Another max branch patch, this time a small but significant improvement to the previous one.
a) Implemented time weighted averaging of the FFT power spectrum display. This radically cuts down on the noise and improves stability of the plot. The weighting factor is hard coded as a constant (FFT_AVG = 0.25) in the gr_gnuplot.py file. Reducing the number makes the plot smoother, but makes it less responsive to changes in tuning or new signals being seen.

b) Implemented a "-d" command line option for "fine tuning" similar to the slider that used to be in scope.py. Most people probably won't need to use this, but I found a situation where the demodulator wouldn't lock on to the signal because it was persistently 90 degrees out of phase due to a small tuning error. The required tuning offset was small (just 200Hz) so I couldn't change the ppm correction, but large enough to cause a problem. Default is "-d 0". Enter a positive or negative integer to adjust the demodulator tuning offset up or down.

https://drive.google.com/open?id=0B-9lC78gYedOM1dJWHkybVVaQzQ

 

[wisco_STEW]

I discovered that i needed to press the "t" key on the rx.py terminal NOT pass "-t" on the command line.

Nice work guys.

 

[PiccoIntegra]

In p25_frame_assembler_impl::forecast()
Should the forecast change for the audio output depending on whether it is Phase 1 or 2, since the bitrate for P2 is 6000 instead of 4800?

I did some testing a few months back which added message ports to the gardner costas loop and the p25_frame_assembler blocks to dynamically change the multiplier based on the samples per symbol from the costas loop. The app would change the sample rate of the costas loop for TDMA, and then the costas loop would emit a message to the frame assembler to change the multiplier whenever there was a change in rate. It worked fine, but I did not notice a huge improvement in performance or decode quality. so I never mentioned it.

The changes to those two blocks are pretty trivial, but connecting them together is a bit more tricky in OP25, due to the demodulation and decoder being in separate code spaces. Rather than fooling with the hier blocks in OP25, I created a CLI app(no gui) so everything was contained. It is hard-coded for the system I tested this on, so it's not too helpful to anyone else.

If you're interested, I can post the message code here, it's a fairly small change.

 

[scan18]

Phase 1 or phase 2 system being monitored? If it's phase 2, you need to add "-2" on the rx.py command line.

The README still indicates in a couple of places that -2 and -V are no longer required, so a lot of phase 2 users who are giving this a try may not know that -2 is still required until they read it here.

 

[boatbod]

I discovered that i needed to press the "t" key on the rx.py terminal NOT pass "-t" on the command line.

Nice work guys.

"t" on the keyboard does the same as "-T <trunk.csv>" on the command line.

 

[VE3RADIO]

No doubt op25 does take some persistence to set up, but then I don't think anyone would claim that setting up Unitrunker, Virtual Audio Cable and DSD+ so that they all play nice together is particularly easier either.

Yeah, but..... DSDPlus / FMP24 is on the Windows platform where 95% of your user base is going to be.. Unix/Linux has it purpose.. but end users is generally not one of those purposes.

FMP24 is included with fastlane and does not require virtual audio cable to work with DSD+ ... also setup is simple.

Perhaps other vendors should build in UDP/TCP.. if they want to play in the DSD+ sandbox... Let us not forget that DSDPlus does 6 different formats... not too shabby for the minor effort involved in learning how to set it up.

 

[boatbod]

Perhaps other vendors should build in UDP/TCP.. if they want to play in the DSD+ sandbox... Let us not forget that DSDPlus does 6 different formats... not too shabby for the minor effort involved in learning how to set it up.

How many other packages support P25 tdma phase 2?

 

[VE3RADIO]

How many other packages support P25 tdma phase 2?

I am sure given enough time the developers at dsdplus will get around to it. I font even think there is a lot of phase 2 out there .. The stuff in my area is all encrypted anyways.. But yea it would be nice.


Sent from my LG-H873 using Tapatalk

 

[boatbod]

I am sure given enough time the developers at dsdplus will get around to it. I font even think there is a lot of phase 2 out there .. The stuff in my area is all encrypted anyways.. But yea it would be nice.

Where I live, the Maryland statewide system is almost exclusively tdma ph2 so if you want to listen you either plunk down $500 for a scanner (which probably does a poor job of decoding) or you learn OP25. It might not have a pretty GUI but it does a great job of decoding audio when set up correctly.