RTLSDR-Airband
RTLSDR-Airband copied to clipboard
charlie-foxtrot
Some missing features
#After a few days of using the RTLSDR-Airband seems a great project but I find that I need some functions not available, mainly related to the recording or scanning.
A small list functions that are missing:
- Possibility of referring to the dongles by their serial number
- Squelch delay selectable in seconds for scan mode.
- Selectable file recording rotation (on every transmission, every hour, every day, every week, and one single file)
- File recording in scan mode to separate files by channel/freq
- FM bandwidth configurable for better reception of narrowbanded pmr, commercial radio, etc. ( This maybe can helps with the problem i have in NFM bleeding audio/noise even after setting low gain values)
- Support for other SDRs HW with higher bandwidth, eg Airspy
- Realtime raw output ¿ALSA loopback devide? to stream with external software (mumble) or pipe to software decoders (for acars, pocsag, etc) and/or Raw file output (wav) that allows the offline data decoding.
I am aware that some functions are more complicated to implement than others. I'm sorry cant collaborate directly but C++ is not a familiar language for me, however I am willing to provide testing for the functions that come to be implemented.
- referring to the dongles by their serial number - will do, it's already on my TODO list
- selectable squelch delay, separate files by channel/freq in scan mode - rather impossible with current implementation of scan mode, needs a rework first
- selectable file rotation interval - looks feasible
- configurable FM bandwidth - not possible, with FFT channelizer the channel bandwidth is fixed. There is no filtering at all.
- Airspy - hm, maybe. I don't have this hardware at hand.
- output to ALSA - will do, it's already on TODO.
- pipe to software decoders - not worth the effort. RTL dongles are so cheap, that you could just buy another one and do ACARS on it.
"pipe to software decoders - not worth the effort. RTL dongles are so cheap, that you could just buy another one and do ACARS on it." -- this could be achieved by outputing audio to a virtual audio device, then make acars decoder read that virtual device - in the future of course - when audio output is ready.
If I connected an Airspy to an externally available SSH host, would that be enough for you to make progress? If not, maybe we could work with the Airspy folks to get you a loaner or old prototype that would function well enough for your coding needs.
Right now it's not necessary. I'd rather go for a SoapySDR interface (see also https://github.com/szpajder/RTLSDR-Airband/issues/60), which would make the code hardware agnostic.
Possibility of referring to the dongles by their serial number
Please....
Serial numbers are now supported in unstable branch. Apologies for delay.
Quick HOWTO - instead of:
index = 0;
specify:
serial = "0123456";
Working flawlessly, thank you !!!
Jun 13 10:47:13 raspberrypi rtl_airband[24718]: Device #2: gain set to 25.40 dB Jun 13 10:47:13 raspberrypi rtl_airband[24718]: Device 2 started. Jun 13 10:47:13 raspberrypi rtl_airband[24718]: Device #0: gain set to 25.40 dB Jun 13 10:47:13 raspberrypi rtl_airband[24718]: Device 0 started.
Selectable file recording rotation (on every transmission, every hour, every day, every week, and one single file)
I don't see anything about this in the documentation yet - do you have a recommendation on how to forcibly rotate the files in the meantime? I tried to steal the recording manually to see if it would recreate it but it doesn't appear to.
Nope, currently there are no other rotation triggers, except of time.
Right now I'm working on variable source rates and FFT sizes, so that support for radios other than RTL could be added. Recording improvements will come after that.
- Support for other SDRs HW with higher bandwidth, eg Airspy - available in 3.0.0, via SoapySDR library.
- FM bandwidth configurable for better reception of narrowbanded pmr, commercial radio, etc. ( This maybe can helps with the problem i have in NFM bleeding audio/noise even after setting low gain values) - 3.0.0 supports configurable sampling rate and FFT size, which may help in such cases; see also the Troubleshooting section in the wiki.
- Realtime raw output "ALSA loopback device" to stream with external software (mumble) or pipe to software decoders (for acars, pocsag, etc) and/or Raw file output (wav) that allows the offline data decoding - piping audio to other apps may be accomplished with Pulseaudio and module-pipe-sink (available since 2.4.0, see also https://github.com/szpajder/RTLSDR-Airband/issues/43#issuecomment-338396636); rawfile output is available in 3.0.0 (refer to the docs for details)).
Please enable file rotation. To create a new file for a new record. I would also like the file name to have the full date and time the recording started. It would also be nice to be able to specify the frequency in the file name. Example: 2020-03-11_08h56m15s_0462.6250_MHz. mp3
The file rotation functionality is the feature I am missing the most. As it stands, I have modified the suffix chararray to include seconds, but this obviously generates a new file for every second of reception which is both difficult to process and has a propensity to generate a LOT of files.
Is this a feature you are currently actively working on? If not, I'll continue to hammer away at my own implimentation.
@dc-to-daylight this feature is not currently under active development, sorry.
If the goal is to enable better / quicker browsing of recorded content, then having the file rotated on every transmission IMHO won't achieve this goal.
@szpajder thank you for your response, it is most appreciated.
The goal is indeed better/quicker browsing of recorded content. I am currently building a web interface on top of the generated output - my intention was to watch the filesystem for each newly written "segment", perform post processing and then add each entry into a database where the list of recordings can be output as JSON for display in the web UI.
It is possible to use the hour long segments, however the issue with this is twofold - this creates an hour long delay from transmission to display in the UI and also creates a large amount of CPU usage for post-processing at the top of each hour.
If you have any suggestions on how better to achieve this, I would very much value your contribution.
In either case, thank you for maintaining this wonderful piece of software.
@dc-to-daylight I don't know what type of channels you are recording and listening to, but here is my most common use case for ATC:
-
If I want real time access to the content (eg. when Flightradar shows something unusual is going on on my local airport, like an interesting aircraft is about to arrive or a spike in holding traffic has popped up out of the blue), I just listen to the Icecast or Pulse feed as it happens. No recording / indexing / web presentation scheme can beat this in terms of realtime-ness (is there such a word?)
-
I reach out to recordings to catch up with interesting stuff which I missed (because I didn't spot it in time or was unable to listen when it was happening). One-hour recordings are fine for this purpose and the access delay is not a big deal (if something has happened already, then I missed it, but as I have it recorded, I can access it anytime later). Having them chopped to pieces of several seconds in length would just add me plenty of extra clicks to get to the interesting part.
Audio is an inherently linear medium. It is seekable, but it is not indexed by nature, hence not easily browseable - unless converted into a visual signal. Like this:
Now you know instantly where to seek, eh?
And this is how I browse / listen to my recordings quickly. I just use Audacity, not VLC.
This can be improved further by adding some metadata to the audio, for example:
Of course this couldn't be saved as an ordinary MP3 or WAV because these formats do not store metadata. But if the recorder produced Audacity project files, you could automatically get something like on the above screenshot.
Or maybe there are other formats on the market which are better suited for storing annotations alongside audio tracks? I don't know, I haven't researched this topic much yet.
@szpajder The file rotation feature would make RTLSDR-Airband compatible with Rdio Scanner. Would you reconsider adding such feature?
@chuot are there any file name format/content requirements for Rdio Scanner? Like does the file name need to include time stamp in seconds, be in local time vs UTC, etc? Or would simply creating a new file per transmission with a unique _# suffix to the existing file name be sufficient?
I’m wondering if this Rdio Scanner would be a better alternative to https://github.com/szpajder/RTLSDR-Airband/issues/155
@charlie-foxtrot I recently added a dirWatch.mask feature with which you tell how to extract the metadata from the filename. An example for another sdr decoder would be #DATE_#TIMEP25ABC_ #SYS_TRAFFIC__TO_#TG_FROM_#UNIT. However, audio files need to be split by conversation or based on a squelch timeout value. At the moment, an audio file is created every hour, which is too long to be used with Rdio Scanner. I would like to use RTLSDR-Airband, but until then, I use csdr piped to sox to split the audio by silences. There's a csdr-am script along with Rdio Scanner in the docs / examples folder.
@chuot is there an expected format for #DATE and/or #TIME?
Currently the filename is <free text>_<date>_<hour>.mp3 so a recording from 5pm-6pm on June 2nd PST would be named basename_20200603_00.mp3. Is the current <date> format of YYYYMMDD acceptable? Instead of <hour> would having HHMMSS match what is expected for #TIME? Will using UTC confuse things?
I think this ask boils down to adding a new mode for output file that:
- changes the filename format to include minute and second
- closes file on close of squelch instead of end of the hour
- make sure short open/close squelch bursts that happen in the same second append to the file instead of overwriting
Anything else?
@charlie-foxtrot It would also be nice to be able to specify the frequency in the file name.
It looks like trunk-recorder uses linux epoch in the filename as well as the frequency (in Hz), for example 1557-1591923151_770556250.wav for a recording of 770.55625 MHz on June 11, 2020 5:52:31 PM PST. There is also a .json file it produces.
@chuot please confirm filename format, either format of #DATE and #TIME or if epoch should be used, and if a .json file is needed to interface with Rdio Scanner
@charlie-foxtrot the meta tag #DATE looks for something like [\d-]+ and #TIME for [\d:], then I do new Date(`${date}T${time}`). See here
@dc-to-daylight @Andrew-Shtein @chuot see #163 for splitting files by transmission and including frequency in the filename