OP25 VirtualBox Project - Run OP25 on Windows 7

[Falcon4]

yeah, I have kicked all these vm machines around now for well a couple of weeks. and really do not understand what all the voice problems are. I see a lot of problems being made by not waiting on the machine. just like my famous domino buddy says "even the snake will let you pick him up when he is ready"

At this point I'm really thinking you have to be in possession of a really powerful machine to run in a virtual machine. My little 2 gigs of RAM and the Celeron dual core wasn't cutting the cheese. It "ran" barely but not fast enough to decode and scope would "grey out" and crash. I haven't given up though I'm in the process of trying to partition this SSH drive and trying with a hard install.

 

[k0grt]

So, I've got P25 phase2 decoding working, and can hear audio via both the nc method and the sockaudio.py method. However, all the audio is crackly/popping/staticy.

I tried adjusting the alsa config to have a longer period time & nperiods per a post I saw, but that didn't seem to do any good. I've also tried messing with sample rates to no avail.

Any thoughts on how to clean up the audio?

 

[adcockfred]

yeah, this was the first machine that I owned that would run op25. it is a hand me down. 4 gb ram I to had the graying out at first. I put a quick launch of the player so I did not have to go through terminal to get it to play.
I had all the sound problems at first too. I tried this and I tried that some worked a little. so basically I was running 3 systems. so I built 3 vm's but really nothing came together until I got all 3 machines on the same page. I did bump sample rate up to around 1.8 mil. but just kept going through each machine and waiting on them to all be tweak the same, I found op25 to be like dsd+ if you just keep cycling the program it seems to smooth out. got my eye on a 64 bit 8 gb machine for $50

 

[boatbod]

So, I've got P25 phase2 decoding working, and can hear audio via both the nc method and the sockaudio.py method. However, all the audio is crackly/popping/staticy.

I tried adjusting the alsa config to have a longer period time & nperiods per a post I saw, but that didn't seem to do any good. I've also tried messing with sample rates to no avail.

Any thoughts on how to clean up the audio?

Are you running through alsa or pulse audio?
In the version you are using, pulse audio works a little better than alsa due to the buffering arrangements.

How is your audio using the older scope.py version?

 

[adcockfred]

yeah running pulse audio. a lot of it is just do not hurry the machine, it seems to corrupt.
being from the country is like never changing your phone number!

 

[adcockfred]

Go to my user name at yahoo and I will foreward a couple screen shots

 

[boatbod]

yeah running pulse audio. a lot of it is just do not hurry the machine, it seems to corrupt.
being from the country is like never changing your phone number!

There's a lot of ways to cause audio underruns; basically anything that delays getting the audio samples out of op25's decoders and back into the audio subsystem in a timely manner. Virtual machines would be high on the list, as are other running applications or anything that spikes cpu utilization.

 

[KA1RBI]

all the audio is crackly/popping/staticy.

Is this in a VM? Also could you post a screen print of the "symbol" plot (-P symbol) - it should be taken **during** a reasonable-length voice transmission so we know it's not the control channel, as the CC and VC channels may have a different character...

Max

 

[KA1RBI]

Hi Graham
. . . . . . .
Max

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

Hi Graham

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

 

[k0grt]

Are you running through alsa or pulse audio?
In the version you are using, pulse audio works a little better than alsa due to the buffering arrangements.

How is your audio using the older scope.py version?

I'm not sure why, but I never did get the scope.py version to even decode by control channel properly. However the rx.py version, first try and I was up and running.

Rx.py is getting picked up via nc on the network audio port and piped through aplay. I think I have it fixed, but every time I launch i have to randomly adjust the aplay sample rate until it stops crackling.

Is this in a VM? Also could you post a screen print of the "symbol" plot (-P symbol) - it should be taken **during** a reasonable-length voice transmission so we know it's not the control channel, as the CC and VC channels may have a different character...

Max

It's a quad core i7 with 16gb ram, running straight Ubuntu. So nope, no vm =)

I think I found some code that seems to suggest the sample rate gets dynamically adjusted. I can clean up the audio from rx.py through nc | aplay, if I just randomly keep adjusting the aplay sample rate up or down in 50 increments until it sounds proper. Still doesnt seem right, but it works!

I'll try and get a screenshot later today.

Sent from my SM-G955U using Tapatalk

 

[boatbod]

I'm not sure why, but I never did get the scope.py version to even decode by control channel properly. However the rx.py version, first try and I was up and running.

Rx.py is getting picked up via nc on the network audio port and piped through aplay. I think I have it fixed, but every time I launch i have to randomly adjust the aplay sample rate until it stops crackling.

It's a quad core i7 with 16gb ram, running straight Ubuntu. So nope, no vm =)

I think I found some code that seems to suggest the sample rate gets dynamically adjusted. I can clean up the audio from rx.py through nc | aplay, if I just randomly keep adjusting the aplay sample rate up or down in 50 increments until it sounds proper. Still doesnt seem right, but it works!

I'll try and get a screenshot later today.

Sent from my SM-G955U using Tapatalk

The audio sample rate is always 8000 out of rx.py when using udp.

For reasons not entirely known, I found that I needed a different fine tuning adjustment when using scope.py vs rx.py in order to accurately decode without seeing -1200/+1200 tuning error messages. (rx.py doesn't have fine tuning natively, but it's pretty easy to implement if needed). Same hardware, same machine... ??

 

[boatbod]

Hi Graham

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

PM sent

 

[boatbod]

I've been working to improve the audio on the rx.py version of op25. To that end, I have some updates that I'd like someone to try out, especially if you have a mixed phase 1 / phase 2 system.

Changed files are available from my google drive as follows:

For the apps directory:
sockaudio.py
trunking.py

For the lib directory:
p25p1_fdma.cc
p25p2_tdma.cc

You will need to perform a "sudo make install" from the build directory once you copy in the new files before the changes will work properly.

What it does:
- updated the mapping of tdma SACCH codes to fdma DUIDs and modified the trunking code so that TDMA call termination honors the MAC_HANGTIME indicator and doesn't immediately flip back to the control channel. Now the trunking engine returns to the control channel when the repeater notifies it has MAC_END_PTT or there is a voice timeout.
- updated the sockaudio.py ALSA pcm code to utilize a larger buffer (10x previous size) and implemented a method that detects the end of transmission by looking for a full block of zero audio samples written whenever a voice transmission ends.

Please feed back whether this works for you or not, and also the approximate interval of "PCM underrun" errors you see in the stderr.2 log. I'm particularly interested in Phase 1 fdma audio performance as I have no way of testing that on my system.

ETA: (6/25/2017 21:35pm EST) I tweaked it again to improve the end detection.

 

[wisco_STEW]

boatbod,

I have a mixed system and wanted to chime in on your changes.

I do like the "q" option to kill "rx".

I'm wondering; is there an issue you are after?
I do find under busy times the voice channels can seem to get cut off and thought your changes to the "lib" files looked promising.

Otherwise the "max" branch seems to work quite well for me. On occasion I do get some extended "crickets" for lack of a better term. This is the sound heard when a voice ends, so I'm not sure if it is just some repeatedly keying.

Prior to your latest updates I was interested in your rolled in audio server. I gave it a try and found it did not work well with the alsa compressor I like to use to even out the audio. It seems to shotgun the audio output and throw off the compressor. See the following link for info on the audio setup: https://en.opensuse.org/SDB:Pulseaudio#Dynamic_range_compression_.28night_mode.29

I also like the fft plot; but I find it only work well with a sample rate below about 5MHZ, else I get under runs.

Pertaining to the current files:
I can't seem to build op25 with your files.

/op25/op25/gr-op25_repeater/lib/p25p1_fdma.cc:243:25: error: no ‘void gr::op25_repeater::p25p1_fdma::reset_timer()’ member function declared in class ‘gr::op25_repeater::p25p1_fdma’

Anyway, I'm running this on tumbleweed, without a vm.

Thanks for your work here.

HaveFun,
Wisco

 

[boatbod]

boatbod,

I have a mixed system and wanted to chime in on your changes.

I do like the "q" option to kill "rx".

I'm wondering; is there an issue you are after?
I do find under busy times the voice channels can seem to get cut off and thought your changes to the "lib" files looked promising.

Otherwise the "max" branch seems to work quite well for me. On occasion I do get some extended "crickets" for lack of a better term. This is the sound heard when a voice ends, so I'm not sure if it is just some repeatedly keying.

Prior to your latest updates I was interested in your rolled in audio server. I gave it a try and found it did not work well with the alsa compressor I like to use to even out the audio. It seems to shotgun the audio output and throw off the compressor. See the following link for info on the audio setup: https://en.opensuse.org/SDB:Pulseaudio#Dynamic_range_compression_.28night_mode.29

I also like the fft plot; but I find it only work well with a sample rate below about 5MHZ, else I get under runs.

Pertaining to the current files:
I can't seem to build op25 with your files.

/op25/op25/gr-op25_repeater/lib/p25p1_fdma.cc:243:25: error: no ‘void gr::op25_repeater::p25p1_fdma::reset_timer()’ member function declared in class ‘gr::op25_repeater::p25p1_fdma’

Anyway, I'm running this on tumbleweed, without a vm.

Thanks for your work here.

HaveFun,
Wisco

Thanks for the feedback.

Please give the latest (today's) version of sockaudio.py a try in conjunction with yesterday's changes to the lib directory and let me know if it is any better. I've been working on the buffering and more specifically the ability to drain the pcm at the end of a transmission. For me at least it has really eliminated underruns and choppy/glitch sound to the point that it now happens rarely if at all. You can experiment with the buffer size by playing around with the PCM_BUFFER_SIZE parameter found near the top of sockaudio.py

The FFT plot is somewhat of a work in progress and it can definitely be cpu intensive. You could try decreasing the refresh rate by upping the "skip" threshold (edit gr_gnuplot.py and look for the line that says "if self.skip == 50:" and increase it to a bigger number. Its crude but basically causes the fft to only be recomputed once every 50 invocations. A time-based interval would undoubtedly be better. The other thing to try would be decreasing the parameter FFT_BINS, although this would have the effect of decreasing the resolution of the plot which might be detrimental to it's usefulness.

ETA: relative to the build error, you are missing an update to file ./lib/p25p1_fdma.h which I apparently forgot to upload. Doh!

 

[adcockfred]

wisco read page 47

 

[whatradio]

Hello, guys.

Quite new to SDR stuff and radio in general, but slowly getting there. Bought myself RTL-SDR V3, spent an hour or two to get OP25 running (Mint 18.1, decent PC), so far so good.

Now it seems I've got a mixed P25 Phase1/Phase2 environment, every channel within 2MHz (1 control + 7 voice channels), perfect situation for RTL-SDR. Here are my command line arguments:

./rx.py --args 'rtl' --gains 'lna:30' -f 423.700 -S 2400000 -T trunk.tsv -w -2 -P fft

Now my questions are:
1) Any way to see if particular conversation is encrypted? Getting quite a lot cases of OP25 switching to particular frequency/talkgroup without any resulting audio output. Happens for both FDMA/TDMA, signal level is OK with a beautiful constellation.
2) Is it possible to increase volume/gain of decoded OP25 audio output? Audio quality is perfect, but volume is quite low, at moment cranking global pulseaudi volume to 100% to hear anything, which of course makes other PC sounds incredibly loud.

 

[boatbod]

Hello, guys.

Quite new to SDR stuff and radio in general, but slowly getting there. Bought myself RTL-SDR V3, spent an hour or two to get OP25 running (Mint 18.1, decent PC), so far so good.

Now it seems I've got a mixed P25 Phase1/Phase2 environment, every channel within 2MHz (1 control + 7 voice channels), perfect situation for RTL-SDR. Here are my command line arguments:

./rx.py --args 'rtl' --gains 'lna:30' -f 423.700 -S 2400000 -T trunk.tsv -w -2 -P fft

Now my questions are:
1) Any way to see if particular conversation is encrypted? Getting quite a lot cases of OP25 switching to particular frequency/talkgroup without any resulting audio output. Happens for both FDMA/TDMA, signal level is OK with a beautiful constellation.
2) Is it possible to increase volume/gain of decoded OP25 audio output? Audio quality is perfect, but volume is quite low, at moment cranking global pulseaudi volume to 100% to hear anything, which of course makes other PC sounds incredibly loud.

I don't think there is any special handling for encryption to prevent them playing garbage audio - I had to blacklist a number of tgids on my local phase 2 system because they consistently rattled my ears!

Not sure why you would be seeing retune to an audio channel without resulting audio, especially if the tuning lasted more than a fraction of a second? Are you running the nc | aplay setup or did you try pulling in my changes? Are you getting anything in the stderr.2 log that hints at a timeout?

 

[whatradio]

Not sure why you would be seeing retune to an audio channel without resulting audio, especially if the tuning lasted more than a fraction of a second? Are you running the nc | aplay setup or did you try pulling in my changes? Are you getting anything in the stderr.2 log that hints at a timeout?

Using nc | aplay setup at moment, but will definitely try your changes later.
Anyway, verbosity level 10, stderr output and some source code reading helped me to pin down the problem.
From what I see, phase1 and phase2 decoders each using a separate UDP connection, so first decoded audio grabs the nc UDP port, making it unable to receive another phase audio packets. So you either hear every p1 or every p2 conversation, on a first-come first-serve basis.. Perhaps sockaudio.py is handling connections differently, will take a look.

I don't think there is any special handling for encryption to prevent them playing garbage audio - I had to blacklist a number of tgids on my local phase 2 system because they consistently rattled my ears!

Aye, verbosity helped to identify those as well, luckily not much encryption going on at moment.
Here are ALGID's used by P25
80 Unencrypted
81 DES
83 Triple DES, 168 bit key
84 AES - 256
85 AES - 128

 

[whatradio]

boatbod, I've downloaded and built your changes, had to manually merge your rx.py code with some latest git changes though.

Both phase1 and phase2 audio works now, no more UDP problems, so sockaudio.py its definitely more robust and comfortable way to listen. Thank you for your work, good job! Hope your code get pushed to official git repository soon.