FAQ

Frequently Asked Questions

Some recordings have a file size of 44 bytes, what gives?

That generally means that the digital recorder was unable to decode any audio.

Why that is happening is a tough question. It could be that the source isn't tuned correctly, signal drift of a device, or a bad retune. Try adjusting the amount of PPM, error, and gain. If you are using a FSK, try adjusting fskGain in the config for that source. Try "0.80" or "1.20" to see if that helps.

I am using 5 RTL dongles and I am getting the following error:

Failed to submit transfer 3!
rtlsdr_read_async returned with -5

This appears to be something weird with the osmosdr driver. Try decreasing the buffer size for each dongle in the source config. I have found the following to work: "device": "rtl=31,buflen=65536” where 31 is the serial number for the dongle and 65536 is the shorter buffer length. Make sure there is a comma, but no space in between the parameters.

The priority settings don't impact its recording state.

Set the priority for things you don't want to record to 999 in the talkgroup file. Also, the RR download doesn't put a value in the hex column/field, so put something in there (can be anything - just not blank.)

I am seeing a lot of 0000's or OOOO's in my console...

This can occur for a various amount of reasons. The most common reason that you will see a bunch of O's spammed back to back in your console is the computers CPU is under high load or is maxed out. There is also the off chance your SDR(s) are at max capacity due to a configuration setting (too much spectrum, too many recorders, etc)

squelch and P25 systems

The squelch option should be left at 0 or removed entirely from the sources config if it is a trunked system. If it is P25 conventional you need to adjust a and squelch so the recorder knows when to stop decoding and finish a recording file. Otherwise you end up with all calls over several hours in one recording back to back with no gaps.

SDR's and sample rates

Each RTL-SDR device should not exceed a rate (sample rate) more than 2400000. Any more and you may cause overloading of the RTL-SDR.

More powerful SDRs, such as the LimeSDR, HackRF, and the likes thereof, are generally safe to bump the samplerate to the entire spectrum wishing to be monitored.

If you dont need the bandwidth you will save processing power by reducing your bandwidth as much as possible. On RTL-SDR you can go down to 250000