RPi 3 & RTL-SDR/OP25?

[Hmaxim]

no luck..get this after i installed as you suggested:
op25/build $ make
make[2]: *** No rule to make target '/usr/lib/libboost_filesystem-mt.so', needed by 'op25/gr-op25/lib/libgnuradio-op25.so'. Stop.
CMakeFiles/Makefile2:210: recipe for target 'op25/gr-op25/lib/CMakeFiles/gnuradio-op25.dir/all' failed
make[1]: *** [op25/gr-op25/lib/CMakeFiles/gnuradio-op25.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
I assumed I install libboost in the root directory?

 

[boatbod]

Thanks will give it a try ASAP..will let you know. I find there is so much missing from the Pi3 OS..lots of dependencies and libraries that I had to dig up..not easy when you have no idea whay you are doing

Yes, there definitely were a lot of missing dependencies that I had to install to get things working. Wish I'd kept a list for you

 

[boatbod]

no luck..get this after i installed as you suggested:
op25/build $ make
make[2]: *** No rule to make target '/usr/lib/libboost_filesystem-mt.so', needed by 'op25/gr-op25/lib/libgnuradio-op25.so'. Stop.
CMakeFiles/Makefile2:210: recipe for target 'op25/gr-op25/lib/CMakeFiles/gnuradio-op25.dir/all' failed
make[1]: *** [op25/gr-op25/lib/CMakeFiles/gnuradio-op25.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
I assumed I install libboost in the root directory?

Did libboost-dev install or did apt say it was already installed?
Try going back and deleting/re-creating the build directory and start over with the cmake. It's possible cmake didn't find libboost correctly the first time around (e.g. if not installed) which would make the subsequent compilation a problem because the auto-generated makefiles will be wrong.

 

[Hmaxim]

It installed completely, no errors or comments..I'll do as you suggest and let you know..Thank you very much!

 

[Hmaxim]

That worked perfectly! I can see you know your stuff! so, this is where I am now :

pi@raspberrypi:~/op25/build $ sudo ldconfig
pi@raspberrypi:~/op25/build $

Yay! Now I have see what to do next..I'll be back

 

[boatbod]

That worked perfectly! I can see you know your stuff! so, this is where I am now :

pi@raspberrypi:~/op25/build $ sudo ldconfig
pi@raspberrypi:~/op25/build $

Yay! Now I have see what to do next..I'll be back

Aha, success. Now you just need to build the config and dial in the tuning.

 

[Hmaxim]

OK..I can spend a lot of time learning how to do that, or maybe you can jump start me? I see I have to now run "rx.py", but I don't know how to do that...sorry. Not looking for a frre ride. I have spent hours learning how to get this running, but I'm getting tired I really do appreciate the help. Linux is very foreign to me.

 

[boatbod]

OK..I can spend a lot of time learning how to do that, or maybe you can jump start me? I see I have to now run "rx.py", but I don't know how to do that...sorry. Not looking for a frre ride. I have spent hours learning how to get this running, but I'm getting tired I really do appreciate the help. Linux is very foreign to me.

Send me a link to the RR db entry for the system you wish to monitor, including your control channel freq. I'll see what I can concoct tonight.

 

[Hmaxim]

As we say here in NJ.."you da Man!"..thanks!

I am interested in the NJICS https://www.radioreference.com/apps/db/?sid=7021
Mainly Howell PD. I can already decode and trunk track P25 Phase 1 with FMP Fast Lane, but I live in Howell and they recently went over to Phase 2.
The Wall CC site is best for me: https://www.radioreference.com/apps/db/?siteId=18688
Thank you very much! BTW, Do I need two dongles, or one? I use 2 on FMP.

 

[boatbod]

As we say here in NJ.."you da Man!"..thanks!

I am interested in the NJICS https://www.radioreference.com/apps/db/?sid=7021
Mainly Howell PD. I can already decode and trunk track P25 Phase 1 with FMP Fast Lane, but I live in Howell and they recently went over to Phase 2.
The Wall CC site is best for me: https://www.radioreference.com/apps/db/?siteId=18688
Thank you very much! BTW, Do I need two dongles, or one? I use 2 on FMP.

You only need one dongle.

Configuration files to get you started are here:
https://drive.google.com/open?id=0B-9lC78gYedOSDBIdU9jYlZBV28

Download and put these in the ~/op25/op25/gr-op25_repeater/apps directory.
Start the application with the command:
./njics.sh

Two things you may encounter:
1. RTLSDR driver might not be set up correctly yet. (Needs the blacklisting stuff doing to kernel)
2. I've assumed the modulation is CQPSK, but RR db says C4FM so you may need to change it over if things don't work.

Give it a shot and let me know what happens.

 

[Hmaxim]

Thank you! I hope to get to it tonight, but probably this weekend . I'm eager to get going but the XYL has other plans for me, along with the Old Guy doctor appointments.. I appreciate you taking the time to do this.! I'll let you know how it goes.

 

[Hmaxim]

could not wait..but this is what I get: pi@raspberrypi:~/op25/op25/gr-op25_repeater/apps $ ./njics.sh
bash: ./njics.sh: Permission denied
pi@raspberrypi:~/op25/op25/gr-op25_repeater/apps $

advice?

 

[boatbod]

could not wait..but this is what I get: pi@raspberrypi:~/op25/op25/gr-op25_repeater/apps $ ./njics.sh
bash: ./njics.sh: Permission denied
pi@raspberrypi:~/op25/op25/gr-op25_repeater/apps $

advice?

Lets start with this:

cd ~/op25/op25/gr-op25_repeater/apps
ls -al

PM the results please.

 

[quad_track]

I have some experience with the PI and the RTL-SDR. Not OP25, but related. I have a couple of notes here:

1. The RTL dongle doesn't have an FPGA, so you can't use it to decimate the samples. This means your USB bus will see the full sample rate provided by the chip (usually nothing less than 1 Msps will work with RTL). If you trace the calls, maybe using KCacheGrind, you'll notice a lot of cycles spent in libusb. If you had an FPGA you could spare those cycles by decimating on it. Use something like the LimeSDR instead if your application is CPU intensive.

2. Most of the other CPU time will be spent in the resampler. Don't use an arbitrary resampler if possible. Instead go with the rational resampler as it's less intensive. Decimate as much as you can before anything else (filters, clock synchronizers etc.)

3. Run the Volk profile before hand to get full benefit of Volk optimizations.

4. Avoid FIR filters in the flowgraph. The PI doesn't handle them well.

5. A lot of the plot images in this thread show large amplitude errors. This is usually caused by the DC spike, so shift your channelizer outside the 0 Hz baseband zone.

 

[boatbod]

I have some experience with the PI and the RTL-SDR. Not OP25, but related. I have a couple of notes here:

1. The RTL dongle doesn't have an FPGA, so you can't use it to decimate the samples. This means your USB bus will see the full sample rate provided by the chip (usually nothing less than 1 Msps will work with RTL). If you trace the calls, maybe using KCacheGrind, you'll notice a lot of cycles spent in libusb. If you had an FPGA you could spare those cycles by decimating on it. Use something like the LimeSDR instead if your application is CPU intensive.

2. Most of the other CPU time will be spent in the resampler. Don't use an arbitrary resampler if possible. Instead go with the rational resampler as it's less intensive. Decimate as much as you can before anything else (filters, clock synchronizers etc.)

3. Run the Volk profile before hand to get full benefit of Volk optimizations.

4. Avoid FIR filters in the flowgraph. The PI doesn't handle them well.

5. A lot of the plot images in this thread show large amplitude errors. This is usually caused by the DC spike, so shift your channelizer outside the 0 Hz baseband zone.

Your notes mirror some of my own observations.

Typically I run op25 on my pi3 with a sample rate of 274000, although I have successfully gone as low as 50000.

Filters and decimating are indeed a problem. I noticed the original op25 code spent a lot of cpu cycles in the fir_filter_ccf() routine, so I changed my copy of the code to use the fft_filter_ccf() variant and utilization went down significantly. By reducing the number of taps in the same routine (broadening the cutoff), cpu use was further lowered.

Not all RTL dongles suffer from a dc spike. On the ones that do, you almost certainly have to apply an offset to make them work with any reliability. Others (such as my Noeelec NESDR) there is no spike and an offset is not required.

I haven't seen any USB issues, but don't doubt what you are saying about an FPGA being beneficial.

 

[ctencore]

for others pursuing this path, I was having an issue of garbled audio decoding Phase II. It sounded almost like it was encrypted but having run this on my desktop via vmware I knew it wasn't. Changing the sample rate to 274000 solved this issue.

 

[kb9mwr]

DMR?

Not to change the subject.... I am wondering if anyone has poked around with this.

Max added some support last April for dmr/dstar/p25/ysf..

I am just starting to look at
/op25/op/25/gr_op25_repeater/apps/tx/dmr-cfg.dat and some of the other files. Its not real clear what you have to do etc.

 

[boatbod]

Not to change the subject.... I am wondering if anyone has poked around with this.

Max added some support last April for dmr/dstar/p25/ysf..

I am just starting to look at
/op25/op/25/gr_op25_repeater/apps/tx/dmr-cfg.dat and some of the other files. Its not real clear what you have to do etc.

I believe that's the area Max is currently working on. He recently committed more changes in the same area which 've just merged them into my fork.

 

[n5pwp]

I realize this is a new project and what I'm asking about may be for future development. I got my RPi3 running OP25 and it is working great. I managed to retire my old desktop PC that was dedicated to the task. It heated my office and made a bunch of noise with the PS fan running constantly. I'm amazed that these little Pis work so well for this. Anyway, my question. In the terminal window we see two sets of numbers. One is the TGID and I assume the other is the receiver ID. Is there a way to get the RID to display on the lower terminal screen along with the TGID. Of course We would have to add a separate RID tsv file to keep track of the receiver IDs. Its interesting to see who is talking to who (agency to agency not person to person). Is that available already? Or should I roll up my sleeves and learn Python and add it to the code?

Thanks Max and Boatbod for doing all this work. Also, to all the other guys like me that are digging around in this stuff and trying to understand whats going on. You're helping to keep my retirement interesting.
Mike

 

[boatbod]

I realize this is a new project and what I'm asking about may be for future development. I got my RPi3 running OP25 and it is working great. I managed to retire my old desktop PC that was dedicated to the task. It heated my office and made a bunch of noise with the PS fan running constantly. I'm amazed that these little Pis work so well for this. Anyway, my question. In the terminal window we see two sets of numbers. One is the TGID and I assume the other is the receiver ID. Is there a way to get the RID to display on the lower terminal screen along with the TGID. Of course We would have to add a separate RID tsv file to keep track of the receiver IDs. Its interesting to see who is talking to who (agency to agency not person to person). Is that available already? Or should I roll up my sleeves and learn Python and add it to the code?

Thanks Max and Boatbod for doing all this work. Also, to all the other guys like me that are digging around in this stuff and trying to understand whats going on. You're helping to keep my retirement interesting.
Mike

Actually both those numbers are the two most recent TGIDs seen on that specific frequency. Right now op25 does not attempt to decode or do anything with the Source Id. It probably could be added pretty easily, but at the end of the day that's more cpu cycles used for something other than voice decoding. Not a big deal for a PC, but a RPI3 needs all the help it can get.