sc5, An audio stripchart recorder

Stripchart as a lightning monitor

This was inspired by H. Ward Silver N6AX's Recording Signals, experiment # 114 in his Hands-On Radio series in QST for July 2012. It has its origins in my Audread program before that, but instead of recording for 1 second this runs for typically an hour. There's also a fairly simple little subroutine added so it records audio amplitude rather than raw audio samples.

This was done with the Radio Jove project in mind, but it makes no attempt to have its files be compatible with those from Radio Skypipe. This is a totally open source project, and it uses ASCII text files for recording data. It also has no GUI interface, mostly because creating one is 10 times as much work as writing the program itself. Also the emphasis was on creating a program that can run automatically in the background 24/7 as long as the computer's turned on.

It's written for OpenBSD, but it may run under NetBSD. The main consideration is the way different the free Unix-like systems handle the sound card. FreeBSD is more like Linux than OpenBSD. OpenBSD sound seems to have come from NetBSD, and Sun before that. Each operating system has had various compatibility layers glued onto the way it handles sound over the years. This doesn't use Alsa, OSS, PortAudio or SNDIO to name a few. I may try to get it working under Debian Linux, but I hardly ever use that. The way the program's written is fairly modular so by replacing one sound card section with one for a different system everything else should work about the same. There aren't any software dependancies like libraries, but Gnuplot and Qiv are the defaults for output.

It usually doesn't load the CPU enough so it even shows up in top, so it has no problem coexisting with just about anything. The only exception to that is that it does tie up the sound card. For that reason either a dedicated computer or a second sound card is advisable if you plan to record 24/7. Running on an old laptop is a good solution at low power consumption. I've got a couple that the displays don't work on anymore but they work fine with external monitors.

This image is a GIF generated by Gnuplot and it's 8050 pixels wide. No interesting event, just a noisy computer got turned off at 18:32. Scroll it sideways with the scrollbar under it.

I use an 8 KHz soundcard sampling rate, then average each 800 samples together to get 10 data points per second. The signal is essentially peak to peak voltage, being the difference between the level of each negative sample and the next positive sample. It probably doesn't directly compare to anything because I thought it up myself. There were about 35,000 datapoints that went into making this plot, and that's after the 800:1 downsampling.

The configuration this was written for used Gnuplot to read in the data and plot to a gif, then Qiv to show the gif. It will work without either or both of those programs, just making the text files of data points. You can use whatever plotting and viewing programs you want. Both Gnuplot and Qiv are free programs but each has a fair number of dependancies, so if you're setting up a new machine you may spend a considerable amount of time installing the dependancies.

Gnuplot, or whatever else you use, will probably have some upper limit on the number of data points it can handle. I've used Gnuplot with 2 hour runs having over 70,000 data points, but the plots look sort of squashed together. I used an image width of 8050 pixels, left over from when I wanted to sample 1 second of audio at 8000 samples per second and have at least 1 pixel horizontally for each sample. When you cram an hour of data (36000 points) into that width you start to lose sight of individual peaks and at 2 hours it starts to become one big smudge. Each data point is still there, they're just so packed together you can't see individuals. Makes me think of New York City for some reason.

The original data is still there of course, in the ascii files, this is all just a matter of how you plot it. If you see something you want more detail on you can copy that part of the data out of the ascii file and plot it by itself. There are no X values in the data, relying instead on having 10 points per second. But every minute the date and time are written into the file in a line starting with #T so Gnuplot ignores it as a comment. Occasionally you might want to edit an ascii file and replot: because Gnuplot autoscales Y by default, if a really big noise spike gets through the averaging it will mess up the Y scale for the rest of the plot but you can edit it out.

At the beginning of the program itself, after the initial comments, are some #define lines and those contain the things you're most likely to want to change. You need to recompile afterward (just type 'make'). If you set MYTZ to 0 the program uses UTC, if you set it to 1 it uses local time. If you set GNUPLOT to 0 it won't call Gnuplot on each run, the same for the QIV line. In a crontab situation running in the background you probably don't want Qiv popping up every time it finishes a run, or you might prefer a different viewer. If you use Qiv it will pop up with the image scaled to fit the screen. Hit m to toggle maxpect mode then you can scroll left and right with the arrow keys. Escape quits, use F1 for help or see the Qiv manpage.

Set SECONDS in the #defines to control the maximum run length. 3600 seconds is 1 hour. SHOWVAL turns on and off the lines of 10 data points per line after the time remaining. These are live so they're the first place a signal or noise increase will show up.

59 minutes, 19 seconds left.
346 335 330 335 329 339 349 375 355 352 

59 minutes, 18 seconds left.
359 344 350 368 374 373 359 358 366 369 

59 minutes, 17 seconds left.
367 335 338 345 355 338 344 331 362 375 

Seconds may seem like a strange way to keep track of time, but it uses a standard time_t, which is an unsigned integer representing the time in seconds since 00:00:00 UTC, 1970-01-01. Firefox/Mozilla/Netscape use them too. They nicely handle being able to add and subtract time without having to worry about borrowing from minutes and carrying to seconds, that sort of junk. See man time (3) or man ctime (3). The dates and time in the filenames are when each run started, not finished.

Because there's a little processing time involved and a little rounding error, the time remaining lines as shown above won't count down to 0 before another mechanism stops the run. In a 1-hour run, they usually get down to about 56 seconds before they stop and have somewhat less than the theoretical 36000 data points. A 5 minute run may stop with 6 seconds left. If you're setting these up in a crontab to run every hour, it's good to have SECONDS set to a few seconds under an hour so they don't collide. Avoiding collisions is another reason to set QIV to 0 if you're calling the program from a crontab.

The program runs Gnuplot by feeding it a file named plot_<date>_<time> (like plot_2012-07-10_1932) that gets created in the directory where the program is. This contains the Gnuplot commands plus the filenames with dates in them, and information for defining time tick marks on the X axis, image size and type (you could make pngs or pdfs for example). They can be edited and run again by typing 'gnuplot <filename>'. If you archive the data somewhere, the plot files, gifs, and ascii files should be kept together, although the gifs can be recreated from the other two. Use something like "qiv audio_2012-07-10_1212.gif" to see the last one or "qiv aud*.gif" to see them all. See the Qiv man page for navigating, or hit space to go forward, backspace for backward, F1 for help. You can only scroll within the file in Qiv when it's in fullscreen mode.

A line like:
0 * * * * cd /usr/programs/c/sc5/cron ; ./sc5 > /dev/null
is all you need in your crontab to run the program every hour. Change the /usr/programs/c/sc5/cron to match the path to where you put the program. Use crontab -e to put it there. Once you get it set right, comment it out with a # when you want to turn it off temporarily. I made a different copy of sc5 configured for calling from a crontab in a subdirectory so I don't have to make changes to the main one, or so development work doesn't mess up the cron version. For debugging your setup, try setting SECONDS to something like 5 minutes and using a crontab entry like
*/10 * * * * cd /usr/programs/c/sc5/cron ; ./sc5 */>> /var/log/sc5.log
to run every 10 mintes and sent output to a log file. You can make changes and recompile and the new version gets run next time. A command like "ps ax | grep sc5" will show whether it's currently running or not. Within sc5.c is a hard-coded path to gnuplot like /usr/local/bin/gnuplot which is because cron jobs don't usually inherit the normal environment (like path). This may be different on your system, try "whereis gnuplot" to see where it is.

If you want to monitor the data from sc5 running as a cron job, cd into where it's making the files, then do "ls -lrt aud*.txt", then "tail -f" on the latest file shown. The screen should update once a second, but the filename will change every hour, so you'll have to start tailing a different file.

I haven't decided on the best way to do it yet, but it's entirely feasible to have a daily webpage generated under program control with thumbnails of the day's hourly plots.

A sample section of a data file, with a timestamp, looks like this:

335
366
384
383
369
#T 2012-07-10 14:12:00
372
394
364
378
The timestamps are written once per minute, plus at the beginning and end. If UTC mode is enabled they also say utc.

If it's Jupiter you want to watch for, I find XEphem does a fine job of tracking it, agreeing with the Naval Observatory website without the need for an internet connection. If you want to be really close, set up your location in Xephem with latitude, longitude, elevation. Once you have that set, go to View -> Data Table -> Control -> Setup. Add a row for Jupiter, then columns for RiseTm, TrnTm amd SetTm. Click Ok and it should show in the data table. Some of the changes are better made directly in /etc/X11/app-defaults/XEphem when the program's not running. It's an old-style resources file so use a text editor. XEphem's in the ports or packages of several Unix-like operating systems. It does need Openmotif.

AB1JX / toys/