OP25 OP25 AMBE Tone Feature Missing

[PiccoIntegra]

I created a simple companion app to read symbol files created with OP25. I used GNU Radio companion to create a basic script with a file sink, throttle, and null sink with a few parameters. I then used code ripped from the rx.py app to put the pieces together and replaced the null sink with the decoder. The syntax is similar to the rx app, with a few tweaks, specifically for decoding TDMA symbols.

In the attached zip file, it contains the program called decode_symbols.py and a text file with the command line parameters and example usage. There are two AMBE and one IBME symbol files you can use for testing the app. The AMBE files contain tone frames to use for debugging. This program must reside in the gr-op25_repeater/apps directory in order to work..

There are a couple of utility apps in the gr-op25_repeater/apps/tdma directory that can be used to further debug the TDMA symbols. But they didn't quite do what this app does, which behaves in the same manner as the rx app.

 

[boatbod]

I created a simple companion app to read symbol files created with OP25. I used GNU Radio companion to create a basic script with a file sink, throttle, and null sink with a few parameters. I then used code ripped from the rx.py app to put the pieces together and replaced the null sink with the decoder. The syntax is similar to the rx app, with a few tweaks, specifically for decoding TDMA symbols.

In the attached zip file, it contains the program called decode_symbols.py and a text file with the command line parameters and example usage. There are two AMBE and one IBME symbol files you can use for testing the app. The AMBE files contain tone frames to use for debugging. This program must reside in the gr-op25_repeater/apps directory in order to work..

There are a couple of utility apps in the gr-op25_repeater/apps/tdma directory that can be used to further debug the TDMA symbols. But they didn't quite do what this app does, which behaves in the same manner as the rx app.

This sounds useful - I'll give it a try later tonight!

As of my commits last night, basic single tone synthesis should be working right now. The amplitude is probably incorrect, and two-tone (dtmf, knox, etc) are not presently implemented, but that should be simple enough.

 

[PiccoIntegra]

Holy crap... I just applied the last few updates from your repo, and I hear AMBE tones.. haha

They're loud, but they are there. It's not much different than when these channels are using Phase 1 mode. So I'm assuming the volumes are adjusted at the consoles.

Woot! I'm not sure I could have figured that out. I would have assumed the AMBE spec was correct until slicerwizard set the record straight. Thank you for doing that.

 

[boatbod]

Holy crap... I just applied the last few updates from your repo, and I hear AMBE tones.. haha

They're loud, but they are there. It's not much different than when these channels are using Phase 1 mode. So I'm assuming the volumes are adjusted at the consoles.

Woot! I'm not sure I could have figured that out. I would have assumed the AMBE spec was correct until slicerwizard set the record straight. Thank you for doing that.

Maybe someone versed in dsp can comment on amplitude calculations:-

Per the spec we decode an ambe "AD" amplitude value in the range 0-127, which represents a logarithmic value of -87.13dBm0 (silence) to +3.17dBm0 (full scale).

I need to turn the AD value into an amplitude multiplier to convert a +/-1.0 waveform into +/-32767 (16bit pcm sample). Right now I've taken the simplistic approach of multiplying the raw AD value by 200, which results in "loud" but broadly acceptable tone reproduction.

My question is whether I need to convert the logarithmic dBm value back into a linear amplitude before scaling the waveform. If so, would someone propose the appropriate math... I believe it might be along the lines of gain = 10^(AD/20)

Thanks,
Graham

ETA: Presently the tone generator is only enabled for P25P2 on only for single freq tones. Dual frequency tones will be added next, then I'll likely have to tweak some things in rx_sync to allow it to work for DMR and the other protocols that utilize the same AMBE codec.

 

[nokoa3116]

Thank you so much for implementing this, I really appreciate it. I can hear the tones my department plays. At times it's a little choppy, not sure whether that's just my reception or something on your side. Regardless once again thank you for this, that's the only thing I had missing for my feeds.

 

[boatbod]

Thank you so much for implementing this, I really appreciate it. I can hear the tones my department plays. At times it's a little choppy, not sure whether that's just my reception or something on your side. Regardless once again thank you for this, that's the only thing I had missing for my feeds.

I've noticed some choppiness on one of my machines at home, yet strangely a different lower end laptop is playing them really well. Frankly it doesn't take much of a glitch to notice a small disturbance in a pure tone that would go unnoticed if it were speech. Perhaps implementing the erasure/frame-repeat process for tones as well as voice?

 

[boatbod]

All the tones defined in Table 9 have been implemented. The tone generation routine could/should be optimized by making a lookup table that is populated once at startup rather than re-computing the samples on the fly every time they are needed. We'll call that version 2...

ETA: I've added tone decode to rx.sync for the DMR protocol. Could someone please test it and let me know if it works.

Half Rate YSF and D-STAR probably also require tone support, but having looked at the code I'm not sure where to extract the u3 parameter required to validate a tone frame. Perhaps someone with more intimate knowledge of these protocols could take a stab at it.

 

[ansul1001]

do i have to run anything else after git pull or will it automatically update I already have your version

 

[boatbod]

do i have to run anything else after git pull or will it automatically update I already have your version

Its a pretty big c/c++ code update which requires a compile/install. The easiest way to accomplish this is as follows:

cd ~/op25
git pull
./install.sh

If you don't mind digging down in the weeds a little deeper, the alternative method is this:

cd ~/op25/build
git pull
make
sudo make install

Either way, once you restart op25 there are no additional configuration options that need to be set. Tones will simply be played when they are received... but hold on to your hat, then can be a bit loud!

 

[ansul1001]

Thanks for the help

 

[squirrel]

So I was surprised that when I pulled the latest update that the 2 tone dispatch tones started coming through. All of the hard work is appreciated, but is there any way to disable the tones so they do not play as before? The county I am monitoring rebroadcasts their high band dispatch channel and it was nice not hearing the tones. I was messing around with the -t option but I think that might be for something else.

In the meantime I want to revert back to the older version I was running. I am not too familiar with GIT, but is there a way to pull back to a certain commit prior to the tones being added?

 

[boatbod]

So I was surprised that when I pulled the latest update that the 2 tone dispatch tones started coming through. All of the hard work is appreciated, but is there any way to disable the tones so they do not play as before? The county I am monitoring rebroadcasts their high band dispatch channel and it was nice not hearing the tones. I was messing around with the -t option but I think that might be for something else.

In the meantime I want to revert back to the older version I was running. I am not too familiar with GIT, but is there a way to pull back to a certain commit prior to the tones being added?

LOL... people want the tones, now people don't want the tones!

Right now there isn't a command line option to disable them. Adding something isn't terribly difficult, but it touches a lot of interfaces and would cause a full recompile. I'll have to think about it.

To get back to an earlier version of the code, you look in the "git log" and pick the one you want and run the command "get checkout xxxxxxxxxxxxx" where the x's are replaced with the git version string.

e.g.

git checkout 80832a19f8833c4c5590ece05c62c5ae92ed6f63

Then go back and recompile the library.

cd ~/op25
./install.sh

 

[squirrel]

LoL, yeah you cannot please everyone . If you can make an option in the future great if not I can work around it.

Thanks for the git info.

 

[boatbod]

LoL, yeah you cannot please everyone . If you can make an option in the future great if not I can work around it.

I have pushed a solution. It's not overly elegant, but it'll work and is minimally invasive.
What I've done is implement a compile-time option to allow you to build the application with AMBE tones disabled. The default is tones enabled, but if you really want to disable them, just do the following (after your have pulled in the latest changes from git):

cd ~/op25/build
cmake -DAMBE_TONES=OFF ../
make
sudo make install

When you run cmake you should see a line that says "AMBE Tone Synthesis Disabled"

-- Build type not specified: defaulting to release.
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Build type not specified: defaulting to release.
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
[b]-- AMBE Tone Synthesis Disabled[/b]
-- Configuring done
-- Generating done
-- Build files have been written to: /home/gnorbury/op25/build
-- Cache values

 

[squirrel]

That works great!

Thanks

 

[squirrel]

I have noticed something weird with the latest update. It seems that OP25 stops playing the audio before the transmission ends then plays that missing piece when the next one comes in. Let me try to explain what I am experiencing.

I have 2 setups both monitoring the same system using RPi 3B +:

• Setup A is using latest code pulled from Git with AMBE Tones enabled
• Setup B is using checkout from commit 43aaa084299a8c15066a1a65b8096bee148f2f40 "Missed part of the fix for "set tgid:"
• Startup Command: ./rx.py --args 'rtl' -N 'LNA:47' -S 2400000 -f 772.9812e6 -o 25000 -q 0 -U -T trunk.tsv -V -2 2> stderr.2

After a fresh reboot listening to both systems at the same time it seems that A will cutoff about .5 seconds before the end of the transmission, but B continues to plays all of it. Then when the next transmission comes in A plays the remainder of the previous transmission then starts playing the new transmission. It seems to take a few minutes before it starts to happen and progressively gets worse over time resulting in transmissions getting cut short (2-5 seconds experienced).

For a sanity check I got the latest from the master branch and rebuilt on B and it started to exhibit the same behavior as A. I then went backwards thru the commits and found that on the above one it stopped doing it, so I think something changed after that.

I am not sure if I can provide any logs but let me know if I can be of assistance.

 

[boatbod]

The behavior you describe would be occur if the pcm doesn't flush at the end of a transmission. Normally this is accounted for in sockaudio.py with the two byte "00 00" udp frame (and it's the main reason I wrote that player in the first place). If you weren't using the -U built in audio player this would be expected behavior with the aplay | nc alternative.

As far as I know there is no reason why any of the AMBE tone commits should change your system behavior for pcm flushes. It's certainly not happening on any of my systems that I have running all day long... Perhaps is someone else is experiencing the same thing they can let us know?

As an aside, I would note that -S 2400000 sample rate is usually way too large for a RPi3 and will cause cpu overload and audio stuttering. I recommend cutting it back to 57600, or whatever the minimum value is that you can make run on your system. When I used to run a RPi3 here, the difference in performance between the two settings was huge!

 

[squirrel]

I thought I had set the sample rate to 57600 previously. Let me give that a try.

 

[squirrel]

After making the change it still seems to do it just not as bad.

What is the minimum hardware you recommend? Obviously the Pi is cheap, but I am also looking for something that is low power usage. I do have a stick PC with a Intel® Atom™ x5-Z8350 Processor and am not sure if that will handle it either, but I am willing to get something that this will run well on.

Thanks

 

[boatbod]

After making the change it still seems to do it just not as bad.

What is the minimum hardware you recommend? Obviously the Pi is cheap, but I am also looking for something that is low power usage. I do have a stick PC with a Intel® Atom™ x5-Z8350 Processor and am not sure if that will handle it either, but I am willing to get something that this will run well on.

Thanks

I use an Intel NUC7 for streaming two feeds simultaneously. It works really well and has been far more reliable than my old Pi3 ever was, but then it cost 10x more than the Pi3.