Can't compile

[gettyhub]

Trying this project out on ArchLinux.

When I run the compile, it gets down to a point where several functions I believe are in p25rx itself are complaining about borrowed variables that don't last long enough [E0597] in descramble.rs VoiceFrameDescrambler.

[kchmck]

Hi @gettyhub, can you verify if you're on the latest nightly rust? I did a rustup update nightly (resulted in rustc 1.36.0-nightly (a9ec99f42 2019-05-13) today) and it seems to be compiling alright for me. Can you post the output of rustc --version?

[gettyhub]

My first attempt was back in the end of March, with rustc --version currently being 1.35.0-nightly (befeeb7c0 2019-03-30). Trying rustup update now, indicates latest update now 1.36.0-nightly (372be4f36 2019-05-14).

[gettyhub]

Looks like I was able to build it now, but running the binary causes Illegal Instruction (core dumped)

[kchmck]

Are you compiling and running on the same machine?

In any case, the build command in the readme might be complicating things. Can you try building with just cargo build and running with ./target/debug/p25rx and see what happens with that? If that works you might try building with cargo build --release and running with the original command.

[gettyhub]

Ok so that worked and now I don't have any audio...does it follow like a scanner or does it actually need another dongle like sdr# or maybe even sdrtrunk? And nothing on the http access. Says it starts the http server, but nothing connects to it.

[kchmck]

It works off one dongle, so when it sees a talkgroup on the control channel it will switch to the associated frequency. I also should note it will likely only work with more modern dongles containing a TCXO.

Are you seeing any log messages on the console? If you run with -v, you should see something like

 INFO 2019-05-16T21:42:06Z: p25rx: opening RTL-SDR at index 0
Found Rafael Micro R820T tuner
 INFO 2019-05-16T21:42:06Z: p25rx: enabling hardware AGC
 INFO 2019-05-16T21:42:06Z: p25rx: setting frequency offset to -3 PPM
 INFO 2019-05-16T21:42:06Z: p25rx: using control channel frequency 851462500 Hz
 INFO 2019-05-16T21:42:06Z: p25rx: starting HTTP server at http://0.0.0.0:8025
DEBUG 2019-05-16T21:42:06Z: p25rx::recv: moving to frequency 851462500 Hz
 INFO 2019-05-16T21:42:06Z: p25rx: writing audio frames to /dev/null
DEBUG 2019-05-16T21:42:07Z: p25rx::talkgroups: selecting from 0 talkgroups
DEBUG 2019-05-16T21:42:08Z: p25rx::talkgroups: selecting from 0 talkgroups
DEBUG 2019-05-16T21:42:09Z: p25rx::talkgroups: selecting from 0 talkgroups
...
DEBUG 2019-05-16T21:42:24Z: p25rx::talkgroups: selecting from 0 talkgroups
DEBUG 2019-05-16T21:42:25Z: p25rx::talkgroups: selecting from 0 talkgroups
DEBUG 2019-05-16T21:42:26Z: p25rx::talkgroups: selecting from 0 talkgroups
DEBUG 2019-05-16T21:42:26Z: p25rx::talkgroups: collecting talkgroup 273
DEBUG 2019-05-16T21:42:27Z: p25rx::talkgroups: selecting from 1 talkgroups
DEBUG 2019-05-16T21:42:27Z: p25rx::talkgroups: using talkgroup 273
DEBUG 2019-05-16T21:42:27Z: p25rx::recv: moving to frequency 852675000 Hz
DEBUG 2019-05-16T21:42:27Z: p25rx::policy: receiving voice message
DEBUG 2019-05-16T21:42:28Z: p25rx::policy: pausing for voice message continuation
DEBUG 2019-05-16T21:42:28Z: p25rx::policy: voice message terminated
DEBUG 2019-05-16T21:42:28Z: p25rx::recv: moving to frequency 851462500 Hz
...

If it never finds any talkgroups to select from, then there's likely some issue decoding the control channel... maybe encryption or some signal differences than what we have locally or just poor receiver performance (wouldn't surprise me). It's also only capable of P25 phase I, if that makes a difference.

If you run with -vv and it's decoding properly you'll see stuff like

TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode NetworkStatusBroadcast
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode ChannelParamsUpdate
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode SystemServiceBroadcast
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode AltControlChannel
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode RfssStatusBroadcast
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode NetworkStatusBroadcast
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode ChannelParamsUpdate
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode SystemServiceBroadcast
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode AltControlChannel
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received NID TrunkingSignaling
TRACE 2019-05-16T21:39:23Z: p25rx::recv: received TSBK with opcode RfssStatusBroadcast

If you don't see any talkgroup messages at all, then it's probably waiting for something to connect to the other end of the audio fifo.

The http server is more like a http API/SSE server at this point, so if you run

curl http://0.0.0.0:8025/subscribe

you should see a stream like

data:{"event":"updateStats","payload":{"bch":{"errWords":1,"fixedSymbols":0,"totalSymbols":64,"totalWords":1},"cyclic":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"golayExt":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"golayShort":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"golayStd":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"hammingShort":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"hammingStd":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"rsLong":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"rsMed":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"rsShort":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"viterbiDibit":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0},"viterbiTribit":{"errWords":0,"fixedSymbols":0,"totalSymbols":0,"totalWords":0}}}

data:{"event":"srcUnit","payload":1801263}

data:{"event":"sigPower","payload":8.421017}

data:{"event":"sigPower","payload":7.3906937}

data:{"event":"srcUnit","payload":1801263}

data:{"event":"sigPower","payload":5.2041225}

data:{"event":"curFreq","payload":851462500}

data:{"event":"altControl","payload":{"freq":852400000,"rfss":1,"site":1}}

data:{"event":"altControl","payload":{"freq":853875000,"rfss":1,"site":1}}

There are also a few other endpoints defined currently.

Apologies for the lack of documentation.

[gettyhub]

It might've been my antenna/reception but the -vv helps me see what's going on when there's a call going on. But still no audio. I see a call and a transfer to a frequency going on in verbose.

The http output looks like JSON output.

I've noticed something else here. When I go into gqrx, my ppm works for the local wx/noaa and a motorola smart zone II. But when I go to a p25 I have to adjust ppm down otherwise the same ppm that works for wx/noaa and m36 is low cut on p25. It's supposed to be linear across the spectrum on rtlsdr, but something else maybe going on there.

I've tried op25 on Mint, because it won't compile on Arch, but I can't seem to get anything out of it.

[kchmck]

If you're using the paplay method, it might be as simple as opening up pavucontrol (pacman -S pavucontrol if need be) and checking that the volume is high enough for that source.

You could use something like sox -n -t raw -r 8000 -e floating-point -b 32 -c 1 p25.fifo synth brownnoise (pacman -S sox) to put a noise signal into the fifo to check if that works at least.

I've noticed the same thing with ppm... seems to require more offset at higher frequencies. I use the gqrx method too, not sure if there's a better way out there to get that number.

[gettyhub]

There appears to be nothing going over the fifo pipe. No activity shows up in pavucontrol under paplay, silent like there is no audio at all going through the pipe. I can verify that the correct talkgroup is being read with a real scanner, but still no audio. I've even tried mplayer and ffplay. Nothing.
The frequencies were even right, so I had to figure it was ppm error. And after I got the ppm error resolved, it gave me audio. Funny how it receives the trunking info with a little error, but when it switches over to the audio, it has to be accurate on the ppm error.

[kchmck]

That's good it started working to some extent. Things are still pretty janky and manual unfortunately.

[gettyhub]

I don't know why more projects don't use single dongle operation like this (as a real scanner only uses one radio to track). Seems odd that it needs one for control channel (where available), and one for voice. Unless you using it for tracking multiple conversations.

[kchmck]

Yeah there are tradeoffs to both approaches, but for a realtime scanner use case it seems like 1 dongle would hopefully be good enough in most scenarios.

[gettyhub]

SDRangel looks like it has potential as something different to gqrx which seems to crash occasionally.