HackRF options ? More than this needed like the Airspys???
Ok.. .with the Airspys hidden magic spell documented... Do the HackRF's need something more like that??? I've got: --args 'hackrf' -g 65 -f 412.34e6 -N 'RF:14,IF:32,BB:26' As the various gains etc.....Any thing more to make it work "correctly?" :) ;) :) ;) That would certainly help with some other tests I'd like to do with OP25 v. some other stuff... Thanks advance....
I just started playing with a HackRF One ("clone"). This seems to basically work: --args 'hackrf' -N RF:0,IF:24,BB:28 -S 4000000 -o 100e3 -q 0 -d 0 .... I think 4M SMPS is around the limit for the processor in my RPi3 - beyond that, regular traffic sounds like it's encrypted :) Not sure if '-g' does anything in this context? I included the '-o' since there's a pretty hefty DC center spike. Still need to figure out if I can make op25 park on a fixed center frequency and find the channels with the sampled space, but I need something better than the RPi3 to cover the system that I want to monitor (channels span about 5MHz). You probably know already, but in case not; the gains are: RF: preamp - either 0 (off) or 14 (on) IF: aka LNA - from 0 to 40 in 8dB steps BB: "baseband" (a.k.a. VGA) - from 0 to 62 in 2dB steps Mine mysteriously stopped receiving on a few occasions yesterday. Nothing in the output to explain why (with '-v2') - it just stopped showing TSBKs (and CPU usage dropped to nothing). I cranked it up to '-v10' yesterday, but haven't reproduced the problem (yet).... ~iain On Sun, Sep 6, 2020 at 11:03 AM <op25@zellners.com> wrote:
Ok.. .with the Airspys hidden magic spell documented...
Do the HackRF's need something more like that???
I've got:
--args 'hackrf' -g 65 -f 412.34e6 -N 'RF:14,IF:32,BB:26'
As the various gains etc.....Any thing more to make it work "correctly?" :) ;) :) ;)
That would certainly help with some other tests I'd like to do with OP25 v. some other stuff...
Thanks advance....
Quoting iain macdonnell - N6ML <ar@dseven.org>:
I just started playing with a HackRF One ("clone"). This seems to basically work:
--args 'hackrf' -N RF:0,IF:24,BB:28 -S 4000000 -o 100e3 -q 0 -d 0 ....
I've got 2 clones to play with... as I felt they may solve another problem. But I think there are 2 issues there, one devices, and two signal. The devices that have 8bit ADC are basically akin to the old double IF conversion scanners, plagued with issues especially in dynamic range. Even more so in the 700MHz PS LMR area. With FirstNets RFI butting right up to that band, even with the 1MHz guard band the RTL's with 8bit ADC are plagued with RFI junk from the FirstNet RFI. in the D Block...I can watch the RFI disappear as you shove the tuning further up the band. Unfortunately my systems operate over the entire band... The 12bit Airspys, and the MSI's aka RDSDR, are they even supported? Are more like triple conversion IF radios. I don't see the RFI splurges all over the band, 700MHz NB PS LMR that I see with the RTL's be it V3 or the other asian junk. I don't see this as much at the 850MHz NSPAC band, but my prime system is well below the 862 ESMR and the A/B Cell blocks at 870Mhz.
I think 4M SMPS is around the limit for the processor in my RPi3 - beyond that, regular traffic sounds like it's encrypted :)
Not sure if '-g' does anything in this context?
Not sure either thats why I am asking before I bang my head playing with options that don't do anything like I did with the Airspy
I included the '-o' since there's a pretty hefty DC center spike.
Another plus to the airspy line, can't say if the MSI/RDSDR ones have this as far as I know none of them are supported by a real OS and software. Other software has it on its list for the future but seems to be getting shoved down the priority level.
Still need to figure out if I can make op25 park on a fixed center frequency and find the channels with the sampled space, but I need something better than the RPi3 to cover the system that I want to monitor (channels span about 5MHz).
OP25 doesn't work that way , and with out a major rewrite to do that you are better to just set a smaller bandwidth/sample rate as the rest is wasted processing. I set my op25 setups to be about 1MSPS or so as thats more than enough for things.
You probably know already, but in case not; the gains are:
RF: preamp - either 0 (off) or 14 (on) IF: aka LNA - from 0 to 40 in 8dB steps BB: "baseband" (a.k.a. VGA) - from 0 to 62 in 2dB steps
Well I know what the HRFO have, I didn't know the conventions to match up to OP25/rx.py, thats why I am asking. I found some rx.py examples.... which gave those and can translate them to it, but the Airspy's needed some other options in the args options to actually make it work, and I'd like to have these all ready to go so as to not waste lab time..Thanks for the info... save some headaches right there.
On Mon, Sep 7, 2020 at 8:25 AM <op25@zellners.com> wrote:
Quoting iain macdonnell - N6ML <ar@dseven.org>:
Still need to figure out if I can make op25 park on a fixed center frequency and find the channels with the sampled space, but I need something better than the RPi3 to cover the system that I want to monitor (channels span about 5MHz).
OP25 doesn't work that way , and with out a major rewrite to do that you are better to just set a smaller bandwidth/sample rate as the rest is wasted processing.
It can work that way. It was not working for me because I had an integer (I guess) for the center frequency, instead of a float(??). I changed it from "773" to "773.0", and now it stays centered there, and finds the channels within the 6MHz sampled. [image: center.PNG] In the past, I've complained that the first word or two of a transmission often gets missed. One theory was that the tuner (RTL dongle back then) was taking some time to effect retuning, and that a solution that doesn't need to retune may be better. I'm still noticing the start of transmissions get missed occasionally, but maybe less than before. I might have to go back to the RTL to try to get a comparison. When you said "doesn't work that way", perhaps you meant that it doesn't continue decoding the control channel whilst simultaneously decoding a voice channel? I believe that that's true, although it does monitor control traffic on the voice channel. I'm not sure if there's any latency involved in "offset retuning". ~iain
I can't confirm as I have never run a HackRF with op25 but those parameters are completely consistent with those published in the HackRF examples gong back to the signal scope days of op25. -----Original Message----- From: op25-dev <op25-dev-bounces@lists.osmocom.org> On Behalf Of op25@zellners.com Sent: Sunday, September 6, 2020 1:03 PM To: op25 op25 <op25-dev@lists.osmocom.org> Subject: [op25-dev] HackRF options ? More than this needed like the Airspys??? Ok.. .with the Airspys hidden magic spell documented... Do the HackRF's need something more like that??? I've got: --args 'hackrf' -g 65 -f 412.34e6 -N 'RF:14,IF:32,BB:26' As the various gains etc.....Any thing more to make it work "correctly?" :) ;) :) ;) That would certainly help with some other tests I'd like to do with OP25 v. some other stuff... Thanks advance....
With rx.py you can enter a center frequency in your trunk.tsv file and it'll offset tune (you'll see it in the fft plot). You can do something similar in multi_rx.py but that involves the frequency in the 'devices' section and then setting the device to "tunable": false. Graham On Sun, Sep 6, 2020, 2:43 PM <wllmbecks@gmail.com> wrote:
I can't confirm as I have never run a HackRF with op25 but those parameters are completely consistent with those published in the HackRF examples gong back to the signal scope days of op25.
-----Original Message----- From: op25-dev <op25-dev-bounces@lists.osmocom.org> On Behalf Of op25@zellners.com Sent: Sunday, September 6, 2020 1:03 PM To: op25 op25 <op25-dev@lists.osmocom.org> Subject: [op25-dev] HackRF options ? More than this needed like the Airspys???
Ok.. .with the Airspys hidden magic spell documented...
Do the HackRF's need something more like that???
I've got:
--args 'hackrf' -g 65 -f 412.34e6 -N 'RF:14,IF:32,BB:26'
As the various gains etc.....Any thing more to make it work "correctly?" :) ;) :) ;)
That would certainly help with some other tests I'd like to do with OP25 v. some other stuff...
Thanks advance....
On Sun, Sep 6, 2020 at 12:05 PM Graham Norbury <gnorbury@bondcar.com> wrote:
With rx.py you can enter a center frequency in your trunk.tsv file and it'll offset tune (you'll see it in the fft plot).
Thanks - I think I have it straight now. Apparently "773" in trunk.tsv is not the same as "773.0" (!) Now using a RPi4, and it seems to be handling 8M sample rate so-far. ~iain
Quoting Graham Norbury <gnorbury@bondcar.com>:
On 9/7/20 11:19 AM, op25@zellners.com wrote:
OP25 doesn't work that way , and with out a major rewrite to do that you are better to just set a smaller bandwidth/sample rate as the rest is wasted processing.
I set my op25 setups to be about 1MSPS or so as thats more than enough for things.
Sorry to disagree but op25 can and does work that way if correctly configured under either rx.py or multi_rx.py. In fact the multi_rx.py implementation is designed to support an arbitrary number of trunking systems and voice channel decodes using 1-to-/N/ SDR devices.
Maybe this will settle this. ** I AM WRONG. ** Period. So where is the MULTI_rx.py documented??? I've never seen or even heard of this. Or documented at all really. Its all just letting it trunk from a CC like a scanner......Or this mode with a center freq... So lets discuss what it can do... you mention multiple CC and multiple audio feed...
liquidsoap...
Yuck not really a fan.. ....but anyway.... So lets start with 1 CC and doing MULTIPLE FEEDS???? How is all this plumbed together to get this my IceCast server??? Audio losses from "scanning" or this is queued up to feed in serial fashion????? One CC would need at minimum 5 feeds.... and how is all this audio held/queued up??? So if say 2 TGID's are active???? I can see issues trying this on a PI with the writes to an SD card right there.
, but the penalty for going that route is having to deal with multiple antennas (or a splitter) to try to capture an already marginal signal.
I have a dedicated yagi to point to one system. And fed through LMR400, low noise distribution amp to provide plenty of ports. Same with my setup for more localized system on an omni, LMR400, low noise dist. amp and multiple ports. More than I need really. Basically its the same setup you would see at the rx end of a site.
Honestly the best "documentation" is going to be the *example.json files found in the apps directory. A single "one trunked system with 3 feeds" can be seen in p25_example.json. You don't have to use liquidsoap if you don't want to; there is the built-in audio player and also the stand-alone helper app "audio.py". That said, we moved away from recommending darkice because of reliability issues with the snd-aloop driver on Raspbian. Graham On 9/8/20 11:51 PM, op25@zellners.com wrote:
Quoting Graham Norbury <gnorbury@bondcar.com>:
On 9/7/20 11:19 AM, op25@zellners.com wrote:
OP25 doesn't work that way , and with out a major rewrite to do that you are better to just set a smaller bandwidth/sample rate as the rest is wasted processing.
I set my op25 setups to be about 1MSPS or so as thats more than enough for things.
Sorry to disagree but op25 can and does work that way if correctly configured under either rx.py or multi_rx.py. In fact the multi_rx.py implementation is designed to support an arbitrary number of trunking systems and voice channel decodes using 1-to-/N/ SDR devices.
Maybe this will settle this. ** I AM WRONG. ** Period.
So where is the MULTI_rx.py documented???
I've never seen or even heard of this. Or documented at all really. Its all just letting it trunk from a CC like a scanner......Or this mode with a center freq...
So lets discuss what it can do... you mention multiple CC and multiple audio feed...
liquidsoap...
Yuck not really a fan.. ....but anyway....
So lets start with 1 CC and doing MULTIPLE FEEDS????
How is all this plumbed together to get this my IceCast server???
Audio losses from "scanning" or this is queued up to feed in serial fashion?????
One CC would need at minimum 5 feeds.... and how is all this audio held/queued up??? So if say 2 TGID's are active???? I can see issues trying this on a PI with the writes to an SD card right there.
, but the penalty for going that route is having to deal with multiple antennas (or a splitter) to try to capture an already marginal signal.
I have a dedicated yagi to point to one system. And fed through LMR400, low noise distribution amp to provide plenty of ports.
Same with my setup for more localized system on an omni, LMR400, low noise dist. amp and multiple ports. More than I need really.
Basically its the same setup you would see at the rx end of a site.
participants (4)
-
Graham Norbury -
iain macdonnell - N6ML -
op25＠zellners.com -
wllmbecks＠gmail.com