Some missing features about rtlsdr-airband HOT 27 OPEN

from rtlsdr-airband.

Right now it's not necessary. I'd rather go for a SoapySDR interface (see also #60), which would make the code hardware agnostic.

from rtlsdr-airband.

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

from rtlsdr-airband.

Serial numbers are now supported in unstable branch. Apologies for delay.

Quick HOWTO - instead of:

index = 0;

specify:

serial = "0123456";

from rtlsdr-airband.

• 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.

from rtlsdr-airband.

"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.

from rtlsdr-airband.

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.

from rtlsdr-airband.

Possibility of referring to the dongles by their serial number

Please....

from rtlsdr-airband.

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.

from rtlsdr-airband.

Thank you very much.

from rtlsdr-airband.

Serial working for me. serial = "liveatc"

from rtlsdr-airband.

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.

from rtlsdr-airband.

• 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 #43 (comment)); rawfile output is available in 3.0.0 (refer to the docs for details)).

from rtlsdr-airband.

Right now, testing the SoapySDR Airspy support. Excellent work, thank you!

from rtlsdr-airband.

File rotation per transmission it's implemented?

from rtlsdr-airband.

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.

from rtlsdr-airband.

@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.

from rtlsdr-airband.

@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.

from rtlsdr-airband.

@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.

from rtlsdr-airband.

@szpajder The file rotation feature would make RTLSDR-Airband compatible with Rdio Scanner. Would you reconsider adding such feature?

from rtlsdr-airband.

@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 #155

from rtlsdr-airband.

@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.

from rtlsdr-airband.

@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?

from rtlsdr-airband.

@charlie-foxtrot It would also be nice to be able to specify the frequency in the file name.

from rtlsdr-airband.

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

from rtlsdr-airband.

@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

from rtlsdr-airband.

@dc-to-daylight @Andrew-Shtein @chuot see #163 for splitting files by transmission and including frequency in the filename

from rtlsdr-airband.