Scanning DMR mototrbo Cap+ and Con systems on the raspberry pi 3b+

[613scanner]

Has any one been able to use a raspberry pi 3b+ to listen to mototrbo cap+ and con networks?
I am getting ready to get a raspberry pi 3b+ anyway as a scanner for my local P25 public safety system ( OP25). I was thinking that maybe I could use it as a " mobile scanner" . I would like to just have a smallish setup I could leave in my backpack and use Bluetooth headphones with . There are many low power mototrbo cap+ and con networks that would be nice to listen to when in the area.

What programs can be run on the raspberry pi 3b+ that decode DMR / mototrbo ? from my research so far the rtl-sdr.com blog tested this program called exagear-desktop that ran a few windows only programs well ( via wine ) including dsd+ , however as of end of February the program is no longer for sale ?

I have thought of getting a md380 and flashing the experimental firmware to scan with , but I am trying to keep this cheap ( I already have rtl-sdr dongles , sd cards etc).

 

[Ubbe]

If you have a laptop, have you tried running a windows versions with a RTL-SDR dongle and check its performance? It is a terrible receiver for mobile use where varying signal strenghts from interfering sources drives the dongle into overload and making it difficult to do any valuable monitoring. The MD380 solution works perfect receiver wise but it doesn't trunk track.

At home a SDR dongle have a more constant signal level and can be set to its most optimum parameters to work satisfactory. There's probably a reason to why so few people consider making working images for raspberry devices using a SDR dongle for trunking systems that you'll more or less need to use a computer to login to see the TG and name tags and to select and avoid TG's in scan.

/Ubbe

 

[boatbod]

op25 multi_rx.py can handle TRBO Connect+ trunking. It can also handle base station DMR, but not currently TRBO Capacity+ or TDMA simplex.

 

[613scanner]

If you have a laptop, have you tried running a windows versions with a RTL-SDR dongle and check its performance? It is a terrible receiver for mobile use where varying signal strenghts from interfering sources drives the dongle into overload and making it difficult to do any valuable monitoring. The MD380 solution works perfect receiver wise but it doesn't trunk track.

At home a SDR dongle have a more constant signal level and can be set to its most optimum parameters to work satisfactory. There's probably a reason to why so few people consider making working images for raspberry devices using a SDR dongle for trunking systems that you'll more or less need to use a computer to login to see the TG and name tags and to select and avoid TG's in scan.

/Ubbe

For the locations I plan to scan I have started taking brief measurements for the times of day I will likely to be in the area / wanting to scan and the noise floor seems to be within 2-4 db day to day . The signals I am interested in are very strong in comparison and I get good decodes . I am thinking about the design of how it will all go in my bag . Right now I'm thinking that I will be using a shortish USB cable and housing the dongle in a separate modified container with some shielding. All the mototrbo I am interested in is all UHF so I can make a quick simple antenna to help things along.

op25 multi_rx.py can handle TRBO Connect+ trunking. It can also handle base station DMR, but not currently TRBO Capacity+ or TDMA simplex.

So if I am already using your fork of OP25 I should already have multi_rx.py installed ? I will give it a try on my local con+ systems!

If I understand correctly I could feed audio from rtl_fm ( or the rtl_airband people seem to recommend) to multi_rx.py and have a okayish scanner for cap+ systems ? None of the systems that are cap+ I am looking at are simplex to my understanding unless some having only one frequency makes them so ? Two systems I am looking at are both malls one with two frequencies( Rideau Centre Trunking System, Ottawa, Ontario - Scanner Frequencies) and a single frequency ( St. Laurent Centre Trunking System, Ottawa, Ontario - Scanner Frequencies)

Honestly the cap+ systems I am looking at have very few talk groups and I am fine without filtering out the talkgroups I'm not interested in.

 

[boatbod]

For the locations I plan to scan I have started taking brief measurements for the times of day I will likely to be in the area / wanting to scan and the noise floor seems to be within 2-4 db day to day . The signals I am interested in are very strong in comparison and I get good decodes . I am thinking about the design of how it will all go in my bag . Right now I'm thinking that I will be using a shortish USB cable and housing the dongle in a separate modified container with some shielding. All the mototrbo I am interested in is all UHF so I can make a quick simple antenna to help things along.



So if I am already using your fork of OP25 I should already have multi_rx.py installed ? I will give it a try on my local con+ systems!

If I understand correctly I could feed audio from rtl_fm ( or the rtl_airband people seem to recommend) to multi_rx.py and have a okayish scanner for cap+ systems ? None of the systems that are cap+ I am looking at are simplex to my understanding unless some having only one frequency makes them so ? Two systems I am looking at are both malls one with two frequencies( Rideau Centre Trunking System, Ottawa, Ontario - Scanner Frequencies) and a single frequency ( St. Laurent Centre Trunking System, Ottawa, Ontario - Scanner Frequencies)

Honestly the cap+ systems I am looking at have very few talk groups and I am fine without filtering out the talkgroups I'm not interested in.

multi_rx.py is included as part of the standard op25 repo. All you have to do is create the appropriate cfg.json and (ideally) have a pair of RTL dongles or one single dongle with enough bandwidth to cover the full spectrum that the Cap+ system occupies. There are example cfg.json for cap+ systems included in the apps directory.

The problem with Con+ is that transmissions rotate through the available voice frequencies so following a conversation could be problematic without an application that knows how to trunk track it. Unfortunately the current op25 fsk4 demodulator is a little slow to react to tdma burst transmissions so it does not do a good job of capturing the very short status messages broadcast when a cap+ voice channel is idle waiting for traffic. (This is also the same reason that op25 presently cannot receive tdma direct/simplex dmr.)