OP25 OP25 WAV file as an input

Status
Not open for further replies.

Old_Macca

Member
Joined
Oct 26, 2019
Messages
9
Hello
I'm a bit stuck here. I currently have boatbod OP25 setup and running using an RTLSDR and outputting to wireshark no problems. However I'd like to have rx.py import .WAV files or worse case an input from the sound card rather than RTLSDR.

I tried with the following command, I also tried adding the options '-a', '-A' and '-I and specifying my soundcard'

./rx.py --input=myfile.wav -D fsk4 -v 50 --wireshark -W 127.0.0.1 -u 6666 2>stderr.log


Traceback (most recent call last):
File "./rx.py", line 921, in <module>
rx = rx_main()
File "./rx.py", line 835, in __init__
self.tb = p25_rx_block(self.options)
File "./rx.py", line 194, in __init__
self.open_file(options.input)
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 92, in __getattr__
return getattr(self._impl, name)
AttributeError: 'top_block_sptr' object has no attribute 'open_file'


Also when I try and specify a soundcard source I get the following error:

./rx.py -I=hw:0,0, -D fsk4 -v 50 --wireshark -W 127.0.0.1 -u 6666 2>stderr.log

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp


trying it with the '-a' I get a different error:


./rx.py -a -I=hw:0,0, -D fsk4 -v 50 --wireshark -W 127.0.0.1 -u 6666 2>stderr.log

gr::log :INFO: audio source - Audio source arch: alsa
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM =hw:0,0,
gr::log :ERROR: audio_alsa_source0 - [=hw:0,0,]: No such file or directory
Traceback (most recent call last):
File "./rx.py", line 921, in <module>
rx = rx_main()
File "./rx.py", line 835, in __init__
self.tb = p25_rx_block(self.options)
File "./rx.py", line 200, in __init__
self.open_audio(self.channel_rate, options.gain, options.audio_input)
File "./rx.py", line 748, in open_audio
self.audio_source = audio.source(capture_rate, audio_input_filename)
File "/usr/lib/python2.7/dist-packages/gnuradio/audio/audio_swig.py", line 154, in make
return _audio_swig.source_make(*args, **kwargs)
RuntimeError: audio_alsa_source


This one might just be a config issue on my part, importing .wav files directly would be my preference.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,959
Location
Talbot Co, MD
It's been a long time since anyone used that functionality. May I ask why you want to do this? Perhaps there is a better way...
 

Old_Macca

Member
Joined
Oct 26, 2019
Messages
9
I'm running into an issue when monitoring a non-trunking P25 system, harris or tait I think. Anyway at the start of each call the HDU and sometimes LDU1 is missing from the capture, if the transmitter doesn't dekey and it continues transmitting a second call I am able to capture the HDU no problems. I think it might be that the demod isn't locking on quick enough.

The system behaves a little different from others I've seen there is this weird solid tone just before the transmission starts, must wake the radio up or something.

I had the idea to record a series of transmissions and splice them all together using audacity and running that through OP25, I'd miss the HDU in the first call yes, but I'd catch the rest of them.

What is interesting is I don't have this issue with transmissions from motorola radios.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,959
Location
Talbot Co, MD
I'm running into an issue when monitoring a non-trunking P25 system, harris or tait I think. Anyway at the start of each call the HDU and sometimes LDU1 is missing from the capture, if the transmitter doesn't dekey and it continues transmitting a second call I am able to capture the HDU no problems. I think it might be that the demod isn't locking on quick enough.

The system behaves a little different from others I've seen there is this weird solid tone just before the transmission starts, must wake the radio up or something.

I had the idea to record a series of transmissions and splice them all together using audacity and running that through OP25, I'd miss the HDU in the first call yes, but I'd catch the rest of them.

What is interesting is I don't have this issue with transmissions from motorola radios.
I think you are correct that the demod does not lock quickly enough. It's actually a known problem with DMR (simplex tdma) and will affect P25 to some extent too. Best guess, the Motorola radios transmit a longer preamble than the Harris or Tait.

Are you using rx.py or multi-rx.py to monitor the channel? The demodulators are the same but the framer is a bit smarter in multi_rx so it _may_ give you a slight timing advantage.
 

KA1RBI

Member
Joined
Aug 15, 2008
Messages
780
Location
Portage Escarpment
Anyway at the start of each call the HDU and sometimes LDU1 is missing from the capture, if the transmitter doesn't dekey and it continues transmitting a second call I am able to capture the HDU no problems. I think it might be that the demod isn't locking on quick enough.
This has been known for a while, especially on conventional P25 using FSK4/C4FM modulation. In response I defined an alt filter type of "fsk4mm". In multi_rx.py this is just a config file option, but in the rx.py that I'm looking at there's apparently no direct way of invoking it. It looks almost as if it might be as simple as inserting [this, for test purposes]

filter_type = 'fsk4mm'

to the list of parameters of the following call in rx.py:

self.demod = p25_demodulator.p25_demod_cb( . . .

Looks like with this hack it would still be necessary to use "-D fsk4" on the command line...

Overall experience with the fsk4mm demod suggested improved recovery of HDUs but perhaps poorer error performance on noisy channels.

Max
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,959
Location
Talbot Co, MD
The OP is attempting to monitor a P25 Conventional channel so the simplest way of accessing fsk4mm might be to use multi_rx.py and make an appropriate config.json
 

Old_Macca

Member
Joined
Oct 26, 2019
Messages
9
Does multi-rx.py support wireshark output? I was able to get it running but without being able to see the output in Wireshark I can't tell if I'm receiving the HDU's or not.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,959
Location
Talbot Co, MD
Does multi-rx.py support wireshark output? I was able to get it running but without being able to see the output in Wireshark I can't tell if I'm receiving the HDU's or not.
No, but you don't need wireshark. Just turn logging up to -v 10 and you'll see the protocol messages.
I'd go further and make the statement that wireshark is not supported, period. The wireshark patches are old, unmaintained, and do not support phase 2 signaling. Even though it might still work from rx.py there's really no reason to use it any more.
 
Last edited:

Old_Macca

Member
Joined
Oct 26, 2019
Messages
9
Hi Boatbod

When I have the verbosity turned up to 10 I only seem to get the IMBE payload rather than all the protocol messages. If it was showing the whole stack I'd expect to see TDU's in there somewhere surely even if I wasn't capturing the HDU's?

Code:
user@user-virtual-machine:~/boatbod/op25/op25/gr-op25_repeater/apps$ ./multi_rx.py -c cfg.json -v 10
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

device: {'gains': 'lna:59', 'args': 'rtl=0', 'ppm': 0, 'rate': 1000000, 'frequency': 415275000, 'tunable': False, 'offset': 0, 'name': 'device_0'}
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
Using device #0 Realtek RTL2838UHIDIR SN: 00000002
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
channel (dev device_0): {'plot': 'symbol', 'name': 'p25', 'excess_bw': 0.2, 'symbol_rate': 4800, 'destination': 'file:///tmp/out1.raw', 'demod_type': 'fsk4', 'filter_type': 'rc', 'device': '', 'frequency': 415275000, 'raw_seek': 0, 'raw_output': '', 'if_rate': 24000, 'raw_input': ''}
Using two-stage decimator for speed=1000000, decim=10/4 if1=100000 if2=25000
1588332985.245604 [-1] mute channel(0)
1588332985.245643 [-1] mute channel(1)
Allocating 15 zero-copy buffers
1588333065.355824 [-1] resync at count 0 for protocol P25 (expected count 24)
1588333065.486647 [-1] IMBE 1e b0 ea 16 bb 60 d4 3e dd f1 ce errs 0
1588333065.487372 [-1] IMBE 3b 32 1e 63 f8 05 61 94 a0 43 41 errs 0
1588333065.487671 [-1] IMBE 73 7b 49 59 fe 9f 69 07 ca fb b7 errs 0
1588333065.487996 [-1] IMBE 57 1e 23 aa 5f 04 c0 83 c7 73 04 errs 0
1588333065.488258 [-1] IMBE 37 31 61 aa eb 67 a9 02 7a ed e7 errs 0
 

wgbecks

Active Member
Joined
Jan 17, 2005
Messages
537
Location
NE Wisconsin
As Max has commented, the HDU's are not always reliably decoded for the reasons aforementioned.

However, the 1588333065.355824 [-1] resync at count 0 for protocol P25 (expected count 24) errors might be problematic to missing HDU's

A recent commit in the boatbod fork fixed excessive "resync at count 0 for protocol P25 (expected count 24)" errors that I was experiencing with the multi_rx.py application. If you haven't done so recently, try running a git pull from the ~/op25 folder then rerun cmake, make, and make install.

Bill
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,959
Location
Talbot Co, MD
Hmmm, well there's a reason you're not seeing full P25 protocol with multi_rx.py, mainly because by default it doesn't know anything about the protocol, unlike rx.py which does. That said, I do have something that fixes that particular problem if you are prepared to experiment a little :)

Code:
cd ~/op25
git pull
git checkout experimental
git pull
./rebuild.sh
Then go re-run your multi-rx.py at log level 10 and you should see protocol messages.
 

Old_Macca

Member
Joined
Oct 26, 2019
Messages
9
Hmmm, well there's a reason
That update worked great. I'm capturing more HDU's than I was previously. Thanks for the update.


Code:
05/02/20 12:37:09.134040 NAC 0x1a0 TDU15:  LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=0, grpaddr=65 : 00 00 44 00 00 41 00 00 00, gly_errs=0
05/02/20 12:37:09.135336 NAC 0x1a0 HDU:  ESS: tgid=65, mfid=0, algid=84, keyid=83, mi=14 d3 38 4a 44 94 97 e3 00, gly_errs=0, rs_errs=0
05/02/20 12:37:09.395929 NAC 0x1a0 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 : 62 00 31 ad 01 17 20 c4 70
05/02/20 12:37:09.395972 IMBE 33 7a 78 a7 bd 92 c7 cb 60 3e 3a errs 0
05/02/20 12:37:09.395980 IMBE 50 f2 02 5d 2d 18 e6 53 de fa 30 errs 0
05/02/20 12:37:09.395985 IMBE 3a ec 2c 44 25 17 cb 58 3b 3a 5d errs 0
05/02/20 12:37:09.395989 IMBE 74 a3 22 54 4b 5c b9 2b 4d de 6e errs 0
05/02/20 12:37:09.395993 IMBE c9 cf 9f cf af 7a 66 42 c1 25 0b errs 0
05/02/20 12:37:09.395998 IMBE 02 2f 0e 98 de da a8 8f cc 27 4a errs 0
05/02/20 12:37:09.396002 IMBE 99 63 22 80 69 2c 96 37 bb c2 20 errs 0
05/02/20 12:37:09.396007 IMBE d2 2e c9 81 6e fe 93 f5 8a ca c6 errs 0
05/02/20 12:37:09.396011 IMBE 76 e0 79 35 ad a6 db e3 89 b0 3b errs 0
05/02/20 12:37:09.527961 NAC 0x1a0 LDU2: ESS: algid=84, keyid=83, mi=32 f0 00 e8 da 50 6a 17 00, rs_errs=0
 

hrh17

Member
Joined
Mar 4, 2015
Messages
100
Location
.
Excellent just tested this new build and its picking up nearly every HDU :)
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,959
Location
Talbot Co, MD
Excellent just tested this new build and its picking up nearly every HDU :)
Cool :)

As an aside, my 'experimental' branch has some minimal support for P25 trunking using muti_rx.py. Configuration is via .json file. I'll leave this example here in case someone wants to play. Note that it does not (yet) support a terminal or streaming metadata.
Code:
{
    "channels": [
        {
            "demod_type": "cqpsk", 
            "destination": "udp://127.0.0.1:23456", 
            "excess_bw": 0.2, 
            "filter_type": "rc", 
            "frequency": 773843750, 
            "if_rate": 24000, 
            "name": "first", 
            "plot": "",
            "symbol_rate": 4800
        }
    ], 
    "devices": [
        {
            "args": "rtl=0", 
            "frequency": 773843750, 
            "gains": "LNA:39", 
            "name": "rtl0", 
            "offset": -200, 
            "ppm": 0, 
            "rate": 960000, 
            "tunable": true
        }
    ],
    "trunking": {
        "module": "trunking.py",
        "chans": [
            {
                "nac": "0x0",
                "sysname": "FiRST Talbot",
                "control_channel_list": "773.84375",
                "whitelist": "caroline.wlist",
                "blacklist": "",
                "tgid_tags_file": "first.tsv"
            }
        ]
    }
}
 

MattSR

Member
Joined
Jul 26, 2002
Messages
407
Location
Sydney, Australia
This has been known for a while, especially on conventional P25 using FSK4/C4FM modulation. In response I defined an alt filter type of "fsk4mm". In multi_rx.py this is just a config file option, but in the rx.py that I'm looking at there's apparently no direct way of invoking it. It looks almost as if it might be as simple as inserting [this, for test purposes]

filter_type = 'fsk4mm'

to the list of parameters of the following call in rx.py:

self.demod = p25_demodulator.p25_demod_cb( . . .

Looks like with this hack it would still be necessary to use "-D fsk4" on the command line...

Overall experience with the fsk4mm demod suggested improved recovery of HDUs but perhaps poorer error performance on noisy channels.

Max
Nice to see this finally getting used now :)
 
Status
Not open for further replies.
Top