search

robotastic / trunk-recorder

Records calls from a Trunked Radio System (P25 & SmartNet)
GNU General Public License v3.0
865 stars 194 forks source link

Errors with HackRF #71

Closed KyleKotowick closed 7 years ago

KyleKotowick commented 8 years ago

I have this software working perfectly with an RTL-SDR, using this config.json file:

{
        "sources": [
                {
                        "center": 857000000,
                        "rate": 2000000,
                        "error": 0,
                        "ppm": -2,
                        "gain": 30,
                        "digitalRecorders": 5,
                        "driver": "osmosdr",
                        "device": "rtl=00001"
                }
        ],
        "system": {
                "control_channels": [857287500,857787500,858787500,859787500],
                "type": "p25",
                "modulation": "QPSK"
        },
        "captureDir": "/home/ubuntu/radio/recordings",
        "talkgroupsFile": "ChanList.csv"
}

Now, I'm trying to use it with a HackRF One, but it's causing me quite a bit of grief. Here is my config.json file:

{
        "sources": [
                {
                        "center": 855000000,
                        "rate": 10000000,
                        "error": 0,
                        "ppm": -7,
                        "gain": 14,
                        "ifGain": 16,
                        "bbGain": 42,
                        "digitalRecorders": 5,
                        "driver": "osmosdr",
                        "device": "hackrf=7595cf"
                }
        ],
        "system": {
                "control_channels": [857287500,857787500,858787500,859787500],
                "type": "p25",
                "modulation": "QPSK"
        },
        "captureDir": "/home/ubuntu/radio/recordings",
        "talkgroupsFile": "ChanList.csv"
}

Everything looks like it's set properly. If I open up GQRX, it recognizes and works properly with the HackRF One. I found the PPM offset for it, tuned it all nicely. But when I try to run ./recorder with this, it keeps throwing the "Control Channel Message Decode Rate: 1/sec" error. Here's the output from when I start up the software:

linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown
[2016-10-14 21:49:05.797528] [0x00007fcfe88be8c0] [info]    Control Channels:
[2016-10-14 21:49:05.797623] [0x00007fcfe88be8c0] [info]    8.57288e+08
[2016-10-14 21:49:05.797643] [0x00007fcfe88be8c0] [info]    8.57788e+08
[2016-10-14 21:49:05.797658] [0x00007fcfe88be8c0] [info]    8.58788e+08
[2016-10-14 21:49:05.797672] [0x00007fcfe88be8c0] [info]    8.59788e+08
[2016-10-14 21:49:05.797679] [0x00007fcfe88be8c0] [info]
[2016-10-14 21:49:05.797710] [0x00007fcfe88be8c0] [info]    Capture Directory: /home/kotowick/radio/recordings
[2016-10-14 21:49:05.797721] [0x00007fcfe88be8c0] [info]    Config Directory: /home/kotowick/radio/trunk-recorder
[2016-10-14 21:49:05.797730] [0x00007fcfe88be8c0] [info]    Talkgroups File: ChanList.csv
[2016-10-14 21:49:05.797745] [0x00007fcfe88be8c0] [info]    Default Mode: digital
[2016-10-14 21:49:05.797782] [0x00007fcfe88be8c0] [info]    Center: 8.55e+08
[2016-10-14 21:49:05.797803] [0x00007fcfe88be8c0] [info]    Rate: 1e+07
[2016-10-14 21:49:05.797815] [0x00007fcfe88be8c0] [info]    Error: 0
[2016-10-14 21:49:05.797827] [0x00007fcfe88be8c0] [info]    PPM Error: -7
[2016-10-14 21:49:05.797846] [0x00007fcfe88be8c0] [info]    Gain: 14
[2016-10-14 21:49:05.797856] [0x00007fcfe88be8c0] [info]    IF Gain: 16
[2016-10-14 21:49:05.797866] [0x00007fcfe88be8c0] [info]    BB Gain: 42
[2016-10-14 21:49:05.797875] [0x00007fcfe88be8c0] [info]    Squelch: 0
[2016-10-14 21:49:05.797885] [0x00007fcfe88be8c0] [info]    Digital Recorders: 15
[2016-10-14 21:49:05.797901] [0x00007fcfe88be8c0] [info]    Debug Recorders: 0
[2016-10-14 21:49:05.797986] [0x00007fcfe88be8c0] [info]    Analog Recorders: 0
[2016-10-14 21:49:05.798003] [0x00007fcfe88be8c0] [info]    driver: osmosdr
[2016-10-14 21:49:05.798016] [0x00007fcfe88be8c0] [info]    Source Device: hackrf=7595cf,buflen=16384,buffers=8
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya
Number of USB devices: 11
USB device 1d50:6089: 0000000000000000909864c8357595cf match
Using HackRF One with firmware git-b9d333a
Using 8 buffers of size 262144.
[2016-10-14 21:49:05.806338] [0x00007fcfe88be8c0] [info]    SOURCE TYPE OSMOSDR (osmosdr)
[2016-10-14 21:49:05.806361] [0x00007fcfe88be8c0] [info]    Setting sample rate to: 1e+07
[2016-10-14 21:49:05.807386] [0x00007fcfe88be8c0] [info]    Actual sample rate: 1e+07
[2016-10-14 21:49:05.807406] [0x00007fcfe88be8c0] [info]    Tunning to 8.55e+08hz
[2016-10-14 21:49:05.808007] [0x00007fcfe88be8c0] [info]    Max HZ: 8.6e+08
[2016-10-14 21:49:05.808026] [0x00007fcfe88be8c0] [info]    Min HZ: 8.5e+08
Using Volk machine: sse4_1_64_orc
Project 25 IMBE Encoder/Decoder Fixed-Point implementation
Developed by Pavel Yazev E-mail: pyazev@gmail.com
Version 1.0 (c) Copyright 2009
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file ``LICENSE'' for details.
[2016-10-14 21:49:05.869136] [0x00007fcfe88be8c0] [info]    Loading Talkgroups...

[2016-10-14 21:49:05.870520] [0x00007fcfe88be8c0] [info]    Read 259 talkgroups.
[2016-10-14 21:49:08.877637] [0x00007fcfe88be8c0] [error]       Control Channel Message Decode Rate: 1/sec
[2016-10-14 21:49:11.879736] [0x00007fcfe88be8c0] [error]       Control Channel Message Decode Rate: 1/sec
[2016-10-14 21:49:14.881129] [0x00007fcfe88be8c0] [error]       Control Channel Message Decode Rate: 1/sec

I've tried it with different firmware for the HackRF, but no luck (currently loaded firmware is built from source, directly from the most recent master branch commit on the repo). The REALLY weird thing is, twice over the past few days it has actually worked, but I cannot for the life of me reproduce the conditions that cause it to work. For some reason, I get the feeling that it has something to do with the HackRF not providing data to the trunk-recorder software properly (if I use an RTL-SDR to capture the control channel, and the HackRF for all the voice channels, all the audio file it saves are 44 bytes and corrupt).

When I run the hackrf_infocommand, it returns:

Found HackRF board 0:
USB descriptor string: 0000000000000000909864c8357595cf
Board ID Number: 2 (HackRF One)
Firmware Version: git-b9d333a
Part ID Number: 0xa000cb3c 0x004b435c
Serial Number: 0x00000000 0x00000000 0x909864c8 0x357595cf

Any thoughts on what could be causing this issue?

robotastic commented 8 years ago

I am sorry about that! It is entirely possible I have not configured the PPM setting to work correctly. I would try using error instead of a PPM setting. So try figuring out the Hz difference between what it should tune to and where it is tuning. And then try flipping the polarity if that doesn’t work because I am never sure which way it should be.

The other thing to try is removing the BufLen and Buffers setting from here: https://github.com/robotastic/trunk-recorder/blob/master/source.cc#L220 https://github.com/robotastic/trunk-recorder/blob/master/source.cc#L220 They automatically get pinned on to the osmodo dev string and they are probably wrong for the HackRF.

On Oct 14, 2016, at 9:53 PM, Kyle Kotowick notifications@github.com wrote:

I have this software working perfectly with an RTL-SDR, using this config.json file:

{ "sources": [ { "center": 857000000, "rate": 2000000, "error": 0, "ppm": -2, "gain": 30, "digitalRecorders": 5, "driver": "osmosdr", "device": "rtl=00001" } ], "system": { "control_channels": [857287500,857787500,858787500,859787500], "type": "p25", "modulation": "QPSK" }, "captureDir": "/home/ubuntu/radio/recordings", "talkgroupsFile": "ChanList.csv" } Now, I'm trying to use it with a HackRF One, but it's causing me quite a bit of grief. Here is my config.json file:

{ "sources": [ { "center": 855000000, "rate": 10000000, "error": 0, "ppm": -7, "gain": 14, "ifGain": 16, "bbGain": 42, "digitalRecorders": 5, "driver": "osmosdr", "device": "hackrf=7595cf" } ], "system": { "control_channels": [857287500,857787500,858787500,859787500], "type": "p25", "modulation": "QPSK" }, "captureDir": "/home/ubuntu/radio/recordings", "talkgroupsFile": "ChanList.csv" } Everything looks like it's set properly. If I open up GQRX, it recognizes and works properly with the HackRF One. I found the PPM offset for it, tuned it all nicely. But when I try to run ./recorder with this, it keeps throwing the "Control Channel Message Decode Rate: 1/sec" error. Here's the output from when I start up the software:

linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown [2016-10-14 21:49:05.797528] [0x00007fcfe88be8c0] [info] Control Channels: [2016-10-14 21:49:05.797623] [0x00007fcfe88be8c0] [info] 8.57288e+08 [2016-10-14 21:49:05.797643] [0x00007fcfe88be8c0] [info] 8.57788e+08 [2016-10-14 21:49:05.797658] [0x00007fcfe88be8c0] [info] 8.58788e+08 [2016-10-14 21:49:05.797672] [0x00007fcfe88be8c0] [info] 8.59788e+08 [2016-10-14 21:49:05.797679] [0x00007fcfe88be8c0] [info] [2016-10-14 21:49:05.797710] [0x00007fcfe88be8c0] [info] Capture Directory: /home/kotowick/radio/recordings [2016-10-14 21:49:05.797721] [0x00007fcfe88be8c0] [info] Config Directory: /home/kotowick/radio/trunk-recorder [2016-10-14 21:49:05.797730] [0x00007fcfe88be8c0] [info] Talkgroups File: ChanList.csv [2016-10-14 21:49:05.797745] [0x00007fcfe88be8c0] [info] Default Mode: digital [2016-10-14 21:49:05.797782] [0x00007fcfe88be8c0] [info] Center: 8.55e+08 [2016-10-14 21:49:05.797803] [0x00007fcfe88be8c0] [info] Rate: 1e+07 [2016-10-14 21:49:05.797815] [0x00007fcfe88be8c0] [info] Error: 0 [2016-10-14 21:49:05.797827] [0x00007fcfe88be8c0] [info] PPM Error: -7 [2016-10-14 21:49:05.797846] [0x00007fcfe88be8c0] [info] Gain: 14 [2016-10-14 21:49:05.797856] [0x00007fcfe88be8c0] [info] IF Gain: 16 [2016-10-14 21:49:05.797866] [0x00007fcfe88be8c0] [info] BB Gain: 42 [2016-10-14 21:49:05.797875] [0x00007fcfe88be8c0] [info] Squelch: 0 [2016-10-14 21:49:05.797885] [0x00007fcfe88be8c0] [info] Digital Recorders: 15 [2016-10-14 21:49:05.797901] [0x00007fcfe88be8c0] [info] Debug Recorders: 0 [2016-10-14 21:49:05.797986] [0x00007fcfe88be8c0] [info] Analog Recorders: 0 [2016-10-14 21:49:05.798003] [0x00007fcfe88be8c0] [info] driver: osmosdr [2016-10-14 21:49:05.798016] [0x00007fcfe88be8c0] [info] Source Device: hackrf=7595cf,buflen=16384,buffers=8 gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9 built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya Number of USB devices: 11 USB device 1d50:6089: 0000000000000000909864c8357595cf match Using HackRF One with firmware git-b9d333a Using 8 buffers of size 262144. [2016-10-14 21:49:05.806338] [0x00007fcfe88be8c0] [info] SOURCE TYPE OSMOSDR (osmosdr) [2016-10-14 21:49:05.806361] [0x00007fcfe88be8c0] [info] Setting sample rate to: 1e+07 [2016-10-14 21:49:05.807386] [0x00007fcfe88be8c0] [info] Actual sample rate: 1e+07 [2016-10-14 21:49:05.807406] [0x00007fcfe88be8c0] [info] Tunning to 8.55e+08hz [2016-10-14 21:49:05.808007] [0x00007fcfe88be8c0] [info] Max HZ: 8.6e+08 [2016-10-14 21:49:05.808026] [0x00007fcfe88be8c0] [info] Min HZ: 8.5e+08 Using Volk machine: sse4_1_64_orc Project 25 IMBE Encoder/Decoder Fixed-Point implementation Developed by Pavel Yazev E-mail: pyazev@gmail.com Version 1.0 (c) Copyright 2009 This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; see the file ``LICENSE'' for details. [2016-10-14 21:49:05.869136] [0x00007fcfe88be8c0] [info] Loading Talkgroups...

[2016-10-14 21:49:05.870520] [0x00007fcfe88be8c0] [info] Read 259 talkgroups. [2016-10-14 21:49:08.877637] [0x00007fcfe88be8c0] [error] Control Channel Message Decode Rate: 1/sec [2016-10-14 21:49:11.879736] [0x00007fcfe88be8c0] [error] Control Channel Message Decode Rate: 1/sec [2016-10-14 21:49:14.881129] [0x00007fcfe88be8c0] [error] Control Channel Message Decode Rate: 1/sec I've tried it with different firmware for the HackRF, but no luck (currently loaded firmware is built from source, directly from the most recent master branch commit on the repo). The REALLY weird thing is, twice over the past few days it has actually worked, but I cannot for the life of me reproduce the conditions that cause it to work. For some reason, I get the feeling that it has something to do with the HackRF not providing data to the trunk-recorder software properly (if I use an RTL-SDR to capture the control channel, and the HackRF for all the voice channels, all the audio file it saves are 44 bytes and corrupt).

When I run the hackrf_infocommand, it returns:

Found HackRF board 0: USB descriptor string: 0000000000000000909864c8357595cf Board ID Number: 2 (HackRF One) Firmware Version: git-b9d333a Part ID Number: 0xa000cb3c 0x004b435c Serial Number: 0x00000000 0x00000000 0x909864c8 0x357595cf Any thoughts on what could be causing this issue?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/71, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG53FxRM3Wz0QE8pKE0LMsCX4adAgRdks5q0DItgaJpZM4KXlJh.

KyleKotowick commented 8 years ago

I switched it to using error instead (-2 kHz, tried 2 kHz as well) but no luck. Also tried removing the BufLen and Buffers from lines 217 & 220 in source.cc, recompiled, no luck. I appreciate the assistance though. Any other thoughts?

dreinhold commented 8 years ago

Pretty sure a 7ppm at 857.MHz should be an error of 6kHz

KyleKotowick commented 8 years ago

Hmmm. I tried changing it back to -7ppm, and it worked! Then I stopped the program and immediately started it again, and it showed the error messages again (no changes to any settings or antenna placement).

I'm almost certain that this has something to do with device input or USB drivers or something. It seems that the first time I plug the device into a given USB port, it works, then the next time I try to start it, it doesn't. Very bizarre. I've tried it on 3 different machines too, always with the same result. Works once, then will never work again (even after restart).

robotastic commented 8 years ago

Ahh! I seem to remember this problem. You have to reconnect the HackRF between programs I think because something wasn’t getting reset in the driver.

Also, the Master branch of the program currently doesn’t scan the control channels automatically. I just add some support for that in the Smartnet-Fun branch, but things area little rough on that branch.

On Oct 14, 2016, at 11:02 PM, Kyle Kotowick notifications@github.com wrote:

Hmmm. I tried changing it back to -7ppm, and it worked! Then I stopped the program and immediately started it again, and it showed the error messages again (no changes to any settings or antenna placement).

I'm almost certain that this has something to do with device input or USB drivers or something. It seems that the first time I plug the device into a given USB port, it works, then the next time I try to start it, it doesn't. Very bizarre. I've tried it on 3 different machines too, always with the same result. Works once, then will never work again (even after restart).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/71#issuecomment-253958703, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG53DlU34J7mhcFRoImxm7DSsRGY-PPks5q0EJMgaJpZM4KXlJh.

KyleKotowick commented 8 years ago

Unfortunately, it doesn't seem quite so simple. Not only does an unplug/replug not work, but even a hard reboot doesn't work. There's nothing more frustrating than an issue that is not reproducible! :)

Regarding the control channels thing you mentioned, are you referring to the fact that I have multiple control channels listed (i.e. I can list multiple, but it will only ever look at the first one)?

I'm not familiar with Smartnet, is it another trunking or encoding scheme? Like an alternative to P25 or something?

robotastic commented 8 years ago

Bummer!

For the control channels, it will only try to first control channel even if multiple are listed. Make sure the system is actively using the first control channel in the list. Sometimes different systems will rotate through the control channels, so it could be that sometimes it is using that control channel and other times it is not.

SmartNet is motorola’s proprietary trunk radio protocol. It came before P25.

On Oct 14, 2016, at 11:17 PM, Kyle Kotowick notifications@github.com wrote:

Unfortunately, it doesn't seem quite so simple. Not only does an unplug/replug not work, but even a hard reboot doesn't work. There's nothing more frustrating than an issue that is not reproducible! :)

Regarding the control channels thing you mentioned, are you referring to the fact that I have multiple control channels listed (i.e. I can list multiple, but it will only ever look at the first one)?

I'm not familiar with Smartnet, is it another trunking or encoding scheme? Like an alternative to P25 or something?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/71#issuecomment-253959235, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG53MLd5VvwB5z_UYrEhmxzB5FBubjAks5q0EWugaJpZM4KXlJh.

KyleKotowick commented 8 years ago

AHA! I figured it out I think. It turns out that my HackRF One has a noticeable amount of thermal drift. So what was happening was that when I plugged it in the first time, it was cool and worked at the error setting I had in the config file. Then after running for a couple minutes, if I stopped and started the program again, it would be warm/hot so the error was different, and it didn't pick up the control signal. If I unplugged it and let it sit for a while, it would cool off and work again when I plugged it back in. I solved this by setting the error at regular operating temperature, now it works continuously.

A different issue has started popping up though. A lot of the recordings are sounding like they do when the CPU is overloaded (a stream of "O"s popping up from gnuradio), i.e. the decoding partially failed. But, it's weird because it sounds like this when the CPU usage is at 10% or so, definitely not overloading. Any tips for cleaning up the decoded transmission?