OP25 VirtualBox Project - Run OP25 on Windows 7

[boatbod]

Thanks to the previous post I see we have an update to try. Great, except I can't get any audio.

I'm starting the main application with the following command:
./rx.py --args "rtl=0" --gains 'lna:36' -D cqpsk -f 773.84375e6 -S 1440000 -q 0 -T trunk-leo.tsv -q 1 -w 2> stderr.2

And the audio server as follows:
nc -kluvw 1 127.0.0.1 23456 | aplay -c1 -f S16_LE -r 8000

The main text window looks like it is working properly. I see the NAC as expected, and various voice frequencies and tgid's, plus some activity (current tgid) at the bottom of the screen. Unfortunately I get no audio from the audio server, no any error messages or indication why not. The config files (.tsv) were copied straight from a working earlier release, so unless the file format has changed, they should be good.

ETA(1): This is a phase 2 system which almost exclusively uses tdma audio.
ETA(2): I'm looking in the "lib" code and not seeing anywhere that phase 2 audio data gets written to UDP.

 

[KA1RBI]

I'm looking in the "lib" code and not seeing anywhere that phase 2 audio data gets written to UDP.

haha yep, I think that's correct. Thx also to PiccoIntegra for being the first to report this.

Max

 

[scan18]

Thanks, boatbod, I am seeing exactly what you described. Wasn't sure if it was ok to discuss here, but you saved me from typing it all out.

 

[boatbod]

haha yep, I think that's correct. Thx also to PiccoIntegra for being the first to report this.

Max

Thanks for the confirmation Max. Let me know when you need it tested on ph2.

Thanks, boatbod, I am seeing exactly what you described. Wasn't sure if it was ok to discuss here, but you saved me from typing it all out.

Any time

Sent from my SM-N920V using Tapatalk

 

[boatbod]

So I hacked together some code to support P25 phase 2 (tdma) audio from Max's new rx.py app. It's quick and dirty but it works reasonably well for me.

If you want to try it, there are three files you will need to modify:
p25_frame_assembler_impl.cc
p25p2_tdma.h
p25p2_tdma.cc
You can pick these up from my google drive, drop them over the existing copies in the lib directory, then perform a make and make install from the build directory as usual.

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

To enable phase 2 decode, you have to add the "-2" option back on the rx.py command line.
./rx.py --args "rtl=0" --gains 'lna:36' -D cqpsk -f 773.84375e6 -S 1440000 -q 0 -T trunk-leo.tsv -q 1 -2 -w 2> stderr.2

Rather obviously, the audio server also has to be running in a separate window.
nc -kluvw 1 127.0.0.1 23456 | aplay -c1 -f S16_LE -r 8000

 

[scan18]

So I hacked together some code to support P25 phase 2 (tdma) audio from Max's new rx.py app. It's quick and dirty but it works reasonably well for me.

If you want to try it, there are three files you will need to modify:
p25_frame_assembler_impl.cc
p25p2_tdma.h
p25p2_tdma.cc
You can pick these up from my google drive, drop them over the existing copies in the lib directory, then perform a make and make install from the build directory as usual.

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

To enable phase 2 decode, you have to add the "-2" option back on the rx.py command line.
./rx.py --args "rtl=0" --gains 'lna:36' -D cqpsk -f 773.84375e6 -S 1440000 -q 0 -T trunk-leo.tsv -q 1 -2 -w 2> stderr.2

Rather obviously, the audio server also has to be running in a separate window.
nc -kluvw 1 127.0.0.1 23456 | aplay -c1 -f S16_LE -r 8000

Works like a champ, thanks! CPU usage down to 10% from 30% with the new program.

I'm testing with pulse turned on, as I think that is the only way I can adjust the volume. I'm running this on a dedicated laptop, not through a VM.

 

[boatbod]

Works like a champ, thanks! CPU usage down to 10% from 30% with the new program.

I'm testing with pulse turned on, as I think that is the only way I can adjust the volume. I'm running this on a dedicated laptop, not through a VM.

I ran it for several hours last night using Pulse on native ubuntu and didn't notice any dropouts. The GR code still calls p25_frame_assembler_impl::forecast() method, but now the multiplier setting is totally non critical as far as audio quality is concerned. It's certainly a major improvement and I really must thank Max and anyone else involved in the development of the new features!

Now for my wish list:
- I'd like to see an option for an FFT plot to help with initial tuning etc.
- when exiting, terminal.py does not clean up Curses properly and you have to manually run a 'reset' command to use that window again.
- the last used TGID and Tag gets left on the bottom left of the terminal window when the receiver is parked on the control channel.
- p25p2 decode is attempted regardless of whether it needs to be or not. Looks like some optimization in p25_frame_assembler_impl::general_work() might be in order.
- general optimizations to strip out the legacy code used to create audio the old way.

/Graham

 

[KA1RBI]

Hi Graham

many thanks for this feedback, that's very valuable. I took a super-brief look at your mods to re-enable P2 and they match perfectly with the mods I had planned, but not yet implemented. In fact all of the changes to go from scope.py to rx.py were on the order of minimal hacks to get from point A to point B. Accordingly I'd like to have you send a patch which (provided it matches what I already expect) I'd be happy to apply.

I think I've figured out a way now to get patches in the proper format that I need without punishing the user excessively. Once you've got the tree to contain just the patch (removing any extraneous changes you don't want included), you can do "git status" to confirm that the modified files are only those three (in this case). Then (change p1.patch to whatever):

git diff > p1.patch

This should produce a patch in the proper unified diff format that I need. Since "patch" is really good at highlighting only what's changed it's a really good opportunity to check and verify the patch contains only what you want in it (make sure the changed lines are only the lines that you want to actually change and there are no whitespace additions that are causing false positives etc)., and that's about it! Then send me the p1.patch file (or whatever you've named it).

Now for my wish list:
/Graham

I would be *delighted* to receive patches for this stuff as well. One specific one, it should clean up the window properly, with no need to "reset", if you use the "q" key to exit. If not, it could be there's been a program crash - take a look at the stderr file and notify me of any Tracebacks, please.

thx and 73

Max

 

[boatbod]

Thanks Max. I'll work on it later this evening and send you the patch.

Sent from my SM-N920V using Tapatalk

 

[boatbod]

Max, I created the git diff patch file for the tdma audio. You can pick it up here:
https://drive.google.com/open?id=0B-9lC78gYedOdjltM296dUFTTEE

I'll turn my attention to some of the simpler terminal.py stuff now.

 

[KA1RBI]

Max, I created the git diff patch file for the tdma audio. You can pick it up here:
https://drive.google.com/open?id=0B-9lC78gYedOdjltM296dUFTTEE

Thanks Graham

It's pushed to the "max" branch in the repo.

Also I'm not sure if we still need output_queue (looks like the p1 fdma uses it also though), but I've made the following mod (in p2 only for now)

#if 0
                output_queue_decode.push_back(snd);
#endif

Please advise if this breaks anything. If not it's a candidate for cleanup at some point...

I'll turn my attention to some of the simpler terminal.py stuff now.

Thanks again Graham. just to note, it's easiest for me to send each change in a separate patch, rather than one huge one. I know patches are really old school and nowadays would be handled via git pull requests (etc). but that's not currently in place...

Max

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

 

[boatbod]

Thanks Graham

It's pushed to the "max" branch in the repo.
<snip>

Fantastic, thanks! I cleaned up my local copy, pulled your commits and checked that they work just fine for me.

I've got one more small patch for you - it erases the "active" tgid and tag from the terminal when they are no longer active and the receiver is parked on the control channel.
https://drive.google.com/open?id=0B-9lC78gYedOczNCTENkRW4yOU0

I've been trying to figure out a clean way to trap ctrl-c and cleanly exit curses, but so far it's eluded me. Strangely the "q" method is working today, but I swear it wasn't yesterday when I tried it.

 

[KA1RBI]

I've got one more small patch for you

Nice!

pushed

 

[boatbod]

Nice!

pushed

One more for you... this one shuts down gracefully and resets the Curses screen if you hit ctrl-c.

You may decide it would be better implemented through message passing rather than a direct call to a member method. That would certainly make it thread safe, but the additional overhead and complexity involved seemed unnecessary given the circumstances.
https://drive.google.com/open?id=0B-9lC78gYedOVnpXbkVTUHdDS28

 

[scan18]

Thanks guys, just pulled down these updates and they are working great so far.

 

[boatbod]

Max,

Here is a patch that implements the "fft" plot type using numpy.
https://drive.google.com/open?id=0B-9lC78gYedOOU16dkZ4bnFEUFk

Changes are in files rx.py and gr_gnuplot.py.

I'd love to implement grid lines in the plot (especially at the mid point of the x-axis) but gnuplot is being stubborn and refusing to cooperate. Suggestions welcome.

 

[lukekb]

So I finally got OP25 up and running using VMware... and the Phase 2 audio sounds the same as I am getting from my program: https://openmhz.com/pgcnorth

I will try to get some side by side recordings, but OP25 keeps crashing when I add a Logger.
It don't sound bad, but it is still a lot worse than Phase 1.

Can you tell if there are some obvious parameters I should adjust? Should I miss with gain_mu, costas_alpha?

I have attached some screen shots. It looks like it is tuned in pretty well.

 

[boatbod]

So I finally got OP25 up and running using VMware... and the Phase 2 audio sounds the same as I am getting from my program: https://openmhz.com/pgcnorth

I will try to get some side by side recordings, but OP25 keeps crashing when I add a Logger.
It don't sound bad, but it is still a lot worse than Phase 1.

Can you tell if there are some obvious parameters I should adjust? Should I miss with gain_mu, costas_alpha?

I have attached some screen shots. It looks like it is tuned in pretty well.

First things first, op25 doesn't much like virtual machines, but there are things you can do to help the situation.

i. Create or edit the file ~/.gnuradio/config.conf and set the following parameters:
[audio_alsa]
period_time = 0.015
nperiods = 16

ii. Try disabling pulse audio and run directly through alsa by setting the following parameter in /etc/pulse/client.conf, then reboot.
autospawn = no

iii. Lastly, try tweaking the settings in the forecast loop in op25/op25/gr-op25_repeater/lib/p25_frame_assembler_impl.cc. Replace the entire contents of the existing p15_frame_assembler_impl::forecast() method with:

   const size_t nof_inputs = nof_input_items_reqd.size();
   int nof_samples_reqd = 0;

   if (d_do_audio_output)
       nof_samples_reqd = ceil(0.5f * nof_output_items);
   else
     nof_samples_reqd = ceil(4.0f * nof_output_items);
   std::fill(&nof_input_items_reqd[0], &nof_input_items_reqd[nof_inputs], nof_samples_reqd);

Then go back to the op25/build directory and perform a "sudo make install" to compile and install the changes. Note: the key change here is the reduction from 0.6 to 0.5. Subtle, but on my system it had a huge effect.

Report back and let me know if any of this improved things. For what it's worth, my op25 system sounds great! Certainly way better than my PSR800 scanner on our statewide simulcast phase 2 system. You can listen here: http://www.broadcastify.com/listen/feed/25166

 

[boatbod]

Max,

Here is a patch that implements the "fft" plot type using numpy.
https://drive.google.com/open?id=0B-9lC78gYedOOU16dkZ4bnFEUFk

Changes are in files rx.py and gr_gnuplot.py.

I'd love to implement grid lines in the plot (especially at the mid point of the x-axis) but gnuplot is being stubborn and refusing to cooperate. Suggestions welcome.

I figured out how to fix the gridlines in gnuplot. Patch updated to reflect changes.
https://drive.google.com/open?id=0B-9lC78gYedOOU16dkZ4bnFEUFk

 

[KA1RBI]

I figured out how to fix the gridlines in gnuplot. Patch updated to reflect changes.
https://drive.google.com/open?id=0B-9lC78gYedOOU16dkZ4bnFEUFk

Hi Graham

Many thanks for these patches. I've just done a push containing the FFT and to catch exceptions that may occur. It's more general than just catching Ctrl-C - for example there's a new 'x' command in the terminal interface that deliberately generates an exception for test purposes - the goal is to catch any such errors that might allow rx.py to escape back to the shell CLI prompt without cleaning up the terminal.

As for the FFT it uses your first patch as a base. I've also added labelling of the X axis to show the frequency.

I'm not totally happy with the way it's currently done. Both your original FFT and my modified one both seem to be "jumpy" and it's very hard to say what can be done to improve in cases where the user doesn't run with a center frequency specified.

In my version the gridlines are also fixed but at the cost of using a white background. Id' prefer to restore this to black... Your later patch (I haven't examined it) fixed the grid lines and may also fix the labels on the X axis.

Another strange thing in the FFT is that the left and right edges give the impression that the spectrum is attenuated in those zones. When running osmocom_fft with the same width you don't see this. It's either just an artifact of the FFT or it's actually attenuating the spectrum. In either case it would be good to know what the issue is, if you feel like playing with all these things. I'm sure you can find many ways of improving it.

Anyway looking forward to seeing more patches. As Scott can also attest I'm always tempted to rewrite them. But in any case your efforts are helping to make OP25 better for all. It is interesting to note that DSD+ users (and for that matter Unitrunker users) have no such possibility...

73

Max

p.s. could I have you send me a PM, with your email address