jolaf / radiochronicle

Tool for automatic logging of radio channel activity

The software is created to record the activities on amateur radio channels on LARP, airsoft and other activities using portable radio transmitters or walkie-talkies for communication.

Radio talks may contain information facts important for further activity, things to be analyzed and funny things to laugh at later, so recording them seems useful.

The software is written by russians, so many auxiliary documentations pages are in russian. They're not critical for the program use and further improvement though.

-- Moved from https://code.google.com/p/radiochronicle

radiochronicle's Issues

Video processor needed

Additional program (RadioChronicleProcess) should be developed that would
process a number of recorded .wav files and produce a single video file
with a timestamp in video.

The output may be a series of .png files plus a single .wav file with
combined audio track. Those could be further passed to ffmpeg of mencoder.

The configuration file should contain the following parameters:

- Mask of files to process (the same as in rc.conf)
- Optional start date and end date to process (otherwise all files matching
the mask would be processed)
- Operation mode, output files format etc.
- FPS (in many cases, fps of 1 or 2 seems convenient)
- Video resolution
- Background color (#rrggbb), "bluescreen" #0000ff may be actual
- A set of text strings, each of them configured as follows:

-- Text string, may include date format macros (additional macro may be
introduced for "blinking colon")
-- Font name
-- Font size
-- Font style (instead, HTML-like tags may be processed in the string)
-- Font color (#rrggbb)
-- Maybe text effects like shadow or border and their colors
-- Text location (x, y)

The video API to use is still to be defined.

Original issue reported on code.google.com by [email protected] on 24 May 2010 at 11:06

Short transmissions should be skipped

Config file should include an option [tuning].minRecordingLength so that
transmissions shorter than that value are not recorded.

Original issue reported on code.google.com by [email protected] on 24 May 2010 at 11:13

8 and 32-bit modes don't work

For some reason when audioBits is set to 8 or 32, noise gets recorded
instead of signal. Probably audio data are interpreted wrongly. Needs
investigation.

Original issue reported on code.google.com by [email protected] on 24 May 2010 at 11:09

Documentation is necessary

End-user would surely need documentation to understand how to use and tune the 
program.

Both English and Russian docs are necessary.

This text should be taken into account to prevent trivial mistakes by the 
users: http://code.google.com/p/radiochronicle/wiki/RealRadioCheck

Original issue reported on code.google.com by [email protected] on 6 Nov 2010 at 10:01

Recording timestamp correction due to latency is needed

Audio signal from hardware input takes some time to reach the processing 
engine. As a result, a new transmission is detected a bit later than the 
transmission actually started, and the recording file is timestamped wrongly.

Probably this delay can be measured and taken into account, so that file name 
could reflect the correct time when the transmission actually occured.

Probably methods like pyaudio.Stream.get_input_latency() could help in this 
matter.

Original issue reported on code.google.com by [email protected] on 6 Nov 2010 at 10:17

• Merged into: #5

Hardware testing is necessary

Our audio-recording functionality seems dependent on the particular hardware, 
e. g. see Issue #3.

We should test:
- 8, 16, 32-bit recording
- Single/multichannel recording
- Monitoring operation

on:
- Windows XP
- Windows Vista/7
- Linux

on computers with:
- Built-in audio cards, like Realtek
- Additional audio cards, e. g. Creative
- Notebooks

Original issue reported on code.google.com by [email protected] on 6 Nov 2010 at 10:05

Volume monitoring is necessary

For now, we have a feature ('volume' console command) to print current input 
signal volume level.

We should add a feature (e. g. 'print volume' console command) to turn on/off 
continuous printing of current volume, to save user from typing 'volume' 
multiple times while trying to determine the proper value for volumeTreshold 
setting.

Original issue reported on code.google.com by [email protected] on 6 Nov 2010 at 10:33

Audio library should probably be changed

PyAudio library (http://people.csail.mit.edu/hubert/pyaudio/) we currently use 
is rather limited in functionality and badly tested - quoting the authors: 
"PyAudio is still super-duper alpha quality. It has run on GNU/Linux 2.6, 
Microsoft Windows 7/XP, and Apple Mac OS X 10.5+ — but it could use more 
testing."

Probably another, more developed library could be used instead, e. g. PyMedia 
(http://pymedia.org).

PyMedia could be particularly useful, as it includes video processing 
functionality that could be useful for recording processing module (see Issue 
#2).

Changing the audio library should not be a complex process, as we only use very 
limited and simple functionality.

Original issue reported on code.google.com by [email protected] on 6 Nov 2010 at 10:23

GUI needed

The program could benefit from a compact GUI with the following functionality:
- real-time monitoring of input channel volume level, maybe a waveform
- showing currently recorded file, its length and size
- manual recording start and stop, as well as automatic mode
- showing a list of already recorded files with their length and size and
ability to play them
- visual adjustments of volume threshold and other actual parameters
- monitor on/off button

GUI should be optional, maybe it could run in parallel with console
application.

A first candidate for GUI API is PyQT:
http://www.riverbankcomputing.co.uk/software/pyqt/intro

Original issue reported on code.google.com by [email protected] on 24 May 2010 at 10:54

Recording timestamp correction due to latency is needed

Recording latency should be taken into account when naming an output .wav file.

Simple tests showed that it's not essential, but a careful measurement is
required.

Original issue reported on code.google.com by [email protected] on 24 May 2010 at 11:25