OP25 New User - Hitting a Setup Roadblock

[KC1UA]

Thanks again for having a look. Other than viewing many of the readme files in the apps folder I haven't done any poking around in areas where I feel I might have thrown a wrench in the machinery. I can always blow up these virtual machines and start over, so that's not a big deal.

One thing that I wondered about as I read a few of the readme's was that in some cases it appeared I might have to open another terminal window and run "./audio.py -u 23456" if I wanted to hear audio. I "thought" that might be exclusive to multi-rx.py but not sure. In any event when I did so it told me that the port was already in use, so I guessed that the process was automatic. It appeared to me by looking in the stderr.2 file that it did use that port on startup. Since then though I've been through countless restarts so I wouldn't think that would be causing an issue. Interesting that your OP25 won't play back the audio.

It's interesting that it is exhibiting the same behavior on both machines which leads me to believe I am doing something incorrect at some point.

Again many thanks.

Edit: This is a shot in the dark but as I look at stderr.2 I am seeing as part of line 14, "do_output[0]". That to me says something is turned off?
Edit #2: Now that I look again I see "do_audio_output[1] so guessing my first edit is irrelevant...

 

[boatbod]

Hi, thanks for having a look at it. Interesting...maybe I have an audio issue. I ran the available audio test in Linux and was able to hear audio from both speakers, but nada via OP25 obviously.

The capture is of a conventional system on Marthas Vineyard island.

I'm at work and can't look at the captures until tonight, but from what I've seen so far, this most probably not something you have "done" to break or misconfigure op25.

 

[boatbod]

The reason op25 boatbod is failing to decode the P25 Conventional frames is because they are arriving with their parity bit set exactly the opposite of what is expected per Table 9 in TIA-102.BAAC section 2.11.

Inspection of the "failed" NID codewords reveals the following received from air:
NAC=0xD10, DUID=0x5 (LDU1), Parity = 0 (should be 1)
NAC=0xD10, DUID=0xA (LDU2), Parity = 0 (should be 1)
NAC=0xD10, DUID=0x3 (TERM), Parity = 1 (should be 0)

Since we know that op25 boatbod works fine with P25 Phase 1 trunking and other P25 Conventional, I'm a bit mystified why the RFSS you are monitoring behaves contrary to expected values. About the only thing I can think of doing is making the parity check optional.

 

[KC1UA]

Interesting. I have some other options for P25 conventional in my area; I'll have a look at another and report back.

In the meantime I have had success with Osmocom. I started over as I was thinking about a part of the install that I was questioning, and it turns out I was correct.

At the point where "cat gr3.8.patch | patch -p1" is run, when it starts attempting to patch files it throws up "Reversed (or previously applied) patch detected! Assume -R? [n]". This is why I think as a beginner I'm doing something wrong, because in this case indeed I did, and typed in "Y" for each of the several prompts I received for this. Maybe this should be added to the tutorial so dummies like me don't zig when they should zag!

As soon as I just let it do its thing with the defaults I observed a completely different (and lengthy) installation and once the rest was done, I was able to get conventional P25 running with the following command line:

"./rx.py --args 'rtl' -S 1000000 -n --gains 'lna:28' -P symbol,constellation -f 156.2175e6 -U -l http:0.0.0.0:8080 2> stderr.2 -X"

I am getting voice decode here, although there's not much else going on on the http interface, which I have to say is normal given all I did was put a frequency in there. Interestingly though if it is decoding voice I wonder what is different than the Boatbod version.

The P25 TRS on Nantucket is still misbehaving for the most part. I'll hope that it will improve enough to try with both versions, and I'll try another P25 conventional with Boatbod and let you know.

Both setups seem much happier with using just RTL sticks as the Airspy is constantly getting blown away in both the Ubuntu VM and Windows, even after a reboot. I'll stick with the RTL's for now to minimize variables.

Back with more a bit later on.

 

[KC1UA]

Added observation in Osmocom with the above setup. Once voice is received the symbol and constellation plots freeze. If I try to refresh the browser I get a circle of death with "waiting for data". As shown above the Boatbod plots work nifty.

Audio quality is absolutely superb!

 

[KC1UA]

One of the beauties of having a receiver to antenna patch panel is that it gives me the flexibility of connecting any receiver to any antenna. Of all things, I just made a discovery that a VHF-HI Yagi tuned for about 155 MHz, pointing west, is by far my best receiving antenna for the P25 trunked system I'm trying to monitor with OP25. Nantucket is southeast of me, and I'm not going to even try to do the math as to how many wavelengths of antenna this yagi is at 857 MHz as it just works....

So I can now confirm that Osmocom is fully operational, and I'll get back to work on Boatbod next. Screenshots of a fairly decent looking signal and some activity are attached.

 

[KC1UA]

Boatbod is now fully operational with the Nantucket system. So I think the audio issue is exclusive to conventional P25.

 

[boatbod]

The reason the decode works with osmocom is because their p25_framer does not enforce nid parity unlike mine, which does.

I have modified my code to disable nid parity checking by default. It is now controlled by a cmake option NID_PARITY_CHECK which can be enabled if desired.

If you run the following commands it will pull the update, recompile/install and nid parity check will go away.

git pull
cd ~/op25
./rebuild.sh

 

[boatbod]

Additionally I can confirm the capture.bin file plays back nice clean audio once you disable the parity check.

 

[CanesFan95]

I suspect that "cat gr3.8.patch | patch -p1" command was needed to get a previous Osmocom version working at the time I did that write-up. So maybe that part is no longer needed.

I've never been clear on how to know what the current versions are and when it's time to do an update.

 

[KC1UA]

The reason the decode works with osmocom is because their p25_framer does not enforce nid parity unlike mine, which does.

I have modified my code to disable nid parity checking by default. It is now controlled by a cmake option NID_PARITY_CHECK which can be enabled if desired.

Updated without issue, now I'm waiting for someone to key the mic. Quiet night on Marthas Vineyard. Such are things in the dead of winter here at Cape Cod and the Islands, especially the islands. On MV they primarily dispatch police island-wide on one frequency and fire/EMS on another. It never seems to fail when I'm testing with the police frequency someone's yacking on fire/EMS, or vice versa.

I suspect that "cat gr3.8.patch | patch -p1" command was needed to get a previous Osmocom version working at the time I did that write-up. So maybe that part is no longer needed.

I've never been clear on how to know what the current versions are and when it's time to do an update.

No worries, I'm not clear on much of anything but I'm learning! Next time I blow one up and install another I'll try it without that command and see what happens. Suffice to say your tutorial was a great starting point for me and is greatly appreciated.

On another note, speaking of blowing up VM's and starting over, I did notice that Ubuntu wanted to update to version 22, which I tried once. Apparently it has gnuradio 3.10 which was unhappy with OP25 when I attempted to install.

No one's talking on 156.2175 so I'll post reply here and follow up when they do; I'm guessing it will work fine.

 

[KC1UA]

Confirmed conventional P25 working with Boatbod...but you knew that anyway!

So it seems with a lot of help (with my thanks) I have the basics down. Now I wonder what kind of next level trouble I can get myself into.

 

[boatbod]

On another note, speaking of blowing up VM's and starting over, I did notice that Ubuntu wanted to update to version 22, which I tried once. Apparently it has gnuradio 3.10 which was unhappy with OP25 when I attempted to install.

My repo now works with gr-3.10 on Ubuntu 22.04 (and derivatives) but the installation is a little different because you need to be on git branch "gr310" in order to get the correct install.sh script. The gr-3.8 installers is *supposed* to notice this and halt with a message telling you what to do, but frankly it's easier to start in the right place.
Some newer distros such as the current Debian Testing are also gnuradio-3.10 based, but also have gcc-12, and this presently causes issues due to a gnuradio gr_modtool bug. I have a dirty hack workaround, but I wouldn't recommend it for now.

 

[belvdr]

On another note, speaking of blowing up VM's and starting over, I did notice that Ubuntu wanted to update to version 22, which I tried once.

Take a snapshot of your VM before you start that kind of work. If your VM has issues, you can revert to the snapshot in a few seconds and be back where you started. While a snapshot can be taken while the VM is up, I generally recommend to shut it down, just to ensure all data is synced to the disk.

 

[boatbod]

Take a snapshot of your VM before you start that kind of work. If your VM has issues, you can revert to the snapshot in a few seconds and be back where you started. While a snapshot can be taken while the VM is up, I generally recommend to shut it down, just to ensure all data is synced to the disk.

With VM's I think it's easier to simply start-over using the new distro rather than going through the pain of an upgrade.

 

[belvdr]

With VM's I think it's easier to simply start-over using the new distro rather than going through the pain of an upgrade.

I tend to agree. However, snapshots are also good to allow recovery from patching, applications upgrades, or even just trying something new.

 

[lwvmobile]

With VM's I think it's easier to simply start-over using the new distro rather than going through the pain of an upgrade.

Ain't that the truth. Get on an LTS release, stay on that release until its no longer supported.

I tend to agree. However, snapshots are also good to allow recovery from patching, applications upgrades, or even just trying something new.

Yep, I use snapshots, clones, backups of the vdi files, all sorts of stuff. I just had to trim down from 10 or so VMs to 6 in order to free up some disk space. Making sure stuff still builds and works properly in multiple environments is a true pain.

 

[KC1UA]

Hi,

Digging up this thread again as I am having a problem installing Osmocom in an Ubuntu 20.04 virtual machine. Per the instructions in the aforementioned .pdf I am using the following command line.

osmocom@ubuntu:~/op25/op25/gr-op25_repeater/apps$ ./rx.py --args 'rtl' -S 1000000 -n --gains 'lna:36' -T maine.tsv -P symbol,constellation -2 -U -l http:0.0.0.0:8080 2> stderr.2 -X
setting gain lna to 36
supported sample rates 250000-2560000 step 24000
osmocom@ubuntu:~/op25/op25/gr-op25_repeater/apps$

As you can see, after trying to load it croaks after showing supported sample rates and goes back to the command prompt. I am attaching the stderr.2 file which seems to have a problem with the NAC entry in my .tsv file? Not sure on that but that's where it seems to die. The thing is I have the NAC entered as 0x3de which appears to be in line with the entries in the sample file. I also attached the .tsv file.

This is a fresh installation of Osmocom. Boatbod works fine.

Can't figure this one out, obviously! Thanks for any input.

 

[KC1UA]

Um...never mind. Rookie mistake. Word of advice to anyone trying this. Use Libre Office so your entries actually line up in the correct columns...all good over here!

 

[KC1UA]

I've advanced to installing Ubuntu on an old mini-PC I had laying around doing nothing, and OP25 Osmocom is up and running on it. However I discovered that when connecting to the OP25 interface via a web browser on a different PC on the LAN I do not appear to be receiving audio. I had not considered this could be a problem when I was running it in a VMWare environment but as I think of it I was "remoting" to it from the same PC so technically not across my LAN. I am hearing audio from the Ubuntu box it's running on so the audio is working. I expect once again I'm missing something obvious?