6 Sep
2020
6 Sep
'20
8:03 p.m.
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....
6 Sep
6 Sep
8:22 p.m.
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(a)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....
7 Sep
7 Sep
5:19 p.m.
Quoting iain macdonnell - N6ML <ar(a)dseven.org>rg>:
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.
7:02 p.m.
On Mon, Sep 7, 2020 at 8:25 AM <op25(a)zellners.com> wrote:
Quoting iain macdonnell - N6ML <ar(a)dseven.org>rg>:
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
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. 
6 Sep
6 Sep
8:43 p.m.
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(a)lists.osmocom.org> On Behalf Of op25(a)zellners.com
Sent: Sunday, September 6, 2020 1:03 PM
To: op25 op25 <op25-dev(a)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....
9:05 p.m.
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(a)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(a)lists.osmocom.org> On Behalf Of
op25(a)zellners.com
Sent: Sunday, September 6, 2020 1:03 PM
To: op25 op25 <op25-dev(a)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....
9:51 p.m.
On Sun, Sep 6, 2020 at 12:05 PM Graham Norbury <gnorbury(a)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
9 Sep
9 Sep
5:51 a.m.
Quoting Graham Norbury <gnorbury(a)bondcar.com>om>:
On 9/7/20 11:19 AM, op25(a)zellners.com wrote:
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...
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. 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.
1:26 p.m.
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(a)zellners.com wrote:
Quoting Graham Norbury <gnorbury(a)bondcar.com>om>:
On 9/7/20 11:19 AM, op25(a)zellners.com wrote:
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...
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. 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.
1335
days inactive
1338
days old
8 comments
4 participants
participants (4)
-
Graham Norbury -
iain macdonnell - N6ML -
op25＠zellners.com -
wllmbecks＠gmail.com