OP25 multi_rx.py Ontario Provincial Government Zone 2 help please

Status
Not open for further replies.

boatbod

Member
Joined
Mar 3, 2007
Messages
3,339
Location
Talbot Co, MD
I don't think the US uses .015 channel spacing; likely a Canada thing. So are you saying that an entry in the json file overwrites the .025 value, and if you do not specify anything in the json that the .025 would be the default value?
Yes, the code snippet you posted is the default value given to the parameter if not explicitly set in the .json file.

"I have it kinda working
But I don't know if is working properly just follows 3 voice frequencies and its weird and or different from other trunk systems, and some frequencies will not be on the spot either ex 142.14500 will show 142.14499.
I will be on the shop soon to play with it a bit more "


I'm wondering what frequencies are not being resolved.
There are floating point values being used in the math so I suppose rounding errors are a distinct possibility. On the face of it I don't see that it'll cause a problem in the actual tuning operation, but if turns out that it does, it wouldn't be overly difficult to make the math integer based.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,339
Location
Talbot Co, MD
Glad to hear it working. One question, can the hackrf be used to cover the range, or are two RTL's needed for the following of the control channel? I'll try to set this up for my area and see what happens soon. Thanks.
Missed this question from earlier, but figured it still needed an answer...

OP25's smartnet implementation monitors the trunking control channel continuously because there are situations when it cannot reliably determine that a call is ending (e.g. analog), nor detect the presence of priority traffic which should preempt a call in progress. For this to take place, the application needs at least 2 "channels" defined in the cfg.json file - one dedicated to the 3600bps FSK control channel and the other to the P25CAI (or analog) voice channel. In the op25 world, 'channels' are an entirely software DSP construct comprising of an IF mixer, filtering, demodulation, timing recovery and frame reassembly. Raw samples go in one end of the flowgraph and call-related signaling + decoded audio come out the other.

Each op25 'channel' needs to be fed an appropriate signal source from the tuner hardware. If your tuner has a large enough sample rate you can "park" it on an appropriate frequency (i.e. setting tunable=false) and share it among several 'channels'. If however the tuner only has a small sample rate (e.g. RTL devices) you can dedicate a tuner device to each channel and allow the channels to tune their devices as needed. There are pros and cons of each approach; using wide bandwidth tuners cuts down on the number of antennas and quantity of physical hardware, but it (significantly) increases CPU loading due to increased volume of data being moved over USB plus added computational cost of mixing/filtering higher data rates. Using multiple low-rate sdr devices cuts down on CPU utilization but requires more antennas, incurs higher power consumption and occupies more physical usb ports.

TLDR; yes you can use Hack RF (or Airspy, or anything else supported by gnuradio) if it covers the entire spectrum used by the trunking system you need to monitor.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,339
Location
Talbot Co, MD
There are floating point values being used in the math so I suppose rounding errors are a distinct possibility. On the face of it I don't see that it'll cause a problem in the actual tuning operation, but if turns out that it does, it wouldn't be overly difficult to make the math integer based.
I just pushed a small change which seems to help with this.
 
Status
Not open for further replies.
Top