Hi All, I'm looking for hints as to how to get P25 frames to decode properly using rx.py and wireshark. I'm using the max branch of OP25 on Debian 8. I'm trying to monitor a phase 2 system. I have compiled wireshark 1.8.6, with the OP25 patches and have it running on Ubuntu 14.04 on another machine. I can see P25 frames in wireshark, they show up but I have very strange information in them. Lots of TGIDs set to 0, etc. There are also very few if any LDU1 and LDU2 frames making it into the traces on both Phase 1 and 2. Mostly HDU and link control stuff. I'm watching OP25 switch to a voice channel in the console so I know that there is audio on one of the monitored TGs. Does anyone have any pointers or gotchas for this? I have tried both with and without the -2 and -v switches. I am using -w and -W 224.0.0.1. Should I be using the old branch for this? Is this possible? I have also noticed on Phase I systems that the TGID, ALGID, and MI shows up in the stderr file when debug (-v) is set to 10, I think. But this does not happen on Phase 2. Any way to make this happen on Phase 2? Thanks for any assistance. James
You'll definitely want to turn off all audio decoding (-2 and -V) when using wireshark, otherwise the audio stream will pollute the P25 data being sent over UDP. Beyond that it's unclear to me whether wireshark works properly with the rx.py version of the op25 codebase. I don't believe it's been tested to any degree.
Thanks for the reply. It sounds like using scope.py from the main branch is the best bet at this point. I've been thinking about building a mini desktop with Ubuntu 14.04 for use specifically with OP25, so I think I will finally bite the bullet and do so. I don't think the main branch liked my Debian 8 installation when I tried to compile. When using scope.py do I need to do the same thing as far as turning off audio decoding for use with wireshark? Would this be what I want for example? ./scope.py --args 'rtl' -N 'LNA:30' -f <freq> -S 1000000 -q 1 -v 10 -w -W 224.0.0.1 -T file.tsv Thanks again On Tue, Aug 29, 2017 at 12:31 PM, gnorbury@bondcar.com [op25-dev] < op25-dev@yahoogroups.com> wrote:
You'll definitely want to turn off all audio decoding (-2 and -V) when using wireshark, otherwise the audio stream will pollute the P25 data being sent over UDP. Beyond that it's unclear to me whether wireshark works properly with the rx.py version of the op25 codebase. I don't believe it's been tested to any degree.
I have an image file with a working OP-25 "max" branch Raspberry Pi 3 system available if anyone wants to try it (just copy to an SD card and boot). I'm in a low-bandwidth location now, but will be back home late next week. Ping me if you want to grab it. Johm On Aug 29, 2017, 1:19 PM, at 1:19 PM, "James K4JK k4jk.james@gmail.com [op25-dev]" <op25-dev@yahoogroups.com> wrote:
Thanks for the reply. It sounds like using scope.py from the main branch is the best bet at this point.
I've been thinking about building a mini desktop with Ubuntu 14.04 for use specifically with OP25, so I think I will finally bite the bullet and do so. I don't think the main branch liked my Debian 8 installation when I tried to compile.
When using scope.py do I need to do the same thing as far as turning off audio decoding for use with wireshark? Would this be what I want for example?
./scope.py --args 'rtl' -N 'LNA:30' -f <freq> -S 1000000 -q 1 -v 10 -w -W 224.0.0.1 -T file.tsv
Thanks again
On Tue, Aug 29, 2017 at 12:31 PM, gnorbury@bondcar.com [op25-dev] < op25-dev@yahoogroups.com> wrote:
You'll definitely want to turn off all audio decoding (-2 and -V)
when
using wireshark, otherwise the audio stream will pollute the P25 data being sent over UDP. Beyond that it's unclear to me whether wireshark works properly with the rx.py version of the op25 codebase. I don't believe it's been tested to any degree.
I would be very interested in getting this image. I had the exact same idea. :)
Hi John, Do you think that it would work on a next thing chip? Regards, fm
C.H.I.P seems a bit light in the specs department; just 1GB and a 1Ghz processor. I didn't see what OS it runs, but if it's Debian or some derivative, then you should at least be able to compile the code. You might be able to get it to work if you offload the audio processing to a different machine.
participants (5)
-
flkmrz＠gmail.com [op25-dev] -
gnorbury＠bondcar.com [op25-dev]
-
James K4JK k4jk.james＠gmail.com [op25-dev]
-
John Ackermann N8UR jra＠febo.com [op25-dev]
-
zraith＠gmail.com [op25-dev]