Sorry I haven't gotten this out the door sooner. SPLAT! 1.2.3 from John Magliacane has some bug fixes and accuracy improvements. More info is in the documentation. One feature that someone on the blog requested was the ability to save the GnuPlot temp files for post processing (re-scaling, etc.). This is the new -gpsav option.
Please let me know if you have any problems. If you are wondering what SPLAT! is, see this previous post.
http://people.missouristate.edu/jmcmellen/software/splat-1.2.3-win32.zip
Tuesday, August 26, 2008
SPLAT! 1.2.3 for Windows available
Posted by
John McMellen
at
10:20 AM
0
comments
Labels: engineering, gis, ham radio, prediction, radio, rf, windows
Friday, April 11, 2008
Orban releases public beta of Loudness Meter software
Orban announced today a public beta of a software Loudness Meter for Windows. The free download can be found here.
Here is an excerpt from the press release:
ORBAN INTRODUCES FREE LOUDNESS/LEVEL METERING SOFTWARE
San Leandro, CA, April 10, 2008 Orban today
announced that the first public beta of Orban
Loudness Meter software for Windows XP and Vista
is now available for free download from www.orban.com/meter.
This is the first of a family of Orban meters.
Future paid versions will offer upgraded features
including logging, surround monitoring, and
oversampled peak measurements that accurately
indicate the peak level of the audio after D/A conversion.
[snip]
The Orban software runs on Windows XP and Vista
computers having 1.5 GHz or faster Intel Pentium
4 or Intel-compatible processors that implement
the SSE2 instruction set. While the software can
be driven by any installed Windows sound device,
monitoring playback from an application like
Windows Media Player requires the sound hardware to support Windows Wave I/O.
Posted by
John McMellen
at
11:45 AM
0
comments
Labels: digital, engineering, media, monitoring, radio, software, windows
Friday, March 28, 2008
Get Internet Temperature Data for Automation
We had been using a Sine Systems CTI-2 temperature interface to get the outdoor temperature into our automation system. We recently developed a cable problem between the probe and the interface which prevented accurate readings. After some thought, I wrote this little program to simulate the response of the unit while getting temperature data from the National Weather Service. We have been using it for a couple of months now, and even though it only updates once an hour, it seems to provide a reasonable reading for the temperature. It could really be used with any program that is compatible with the CTI-2.
The software runs on a Windows PC with the Microsoft .NET 2.0 software installed. It will communicate on a pair of hardware serial ports if you have two to spare and can loop from one to the other. Or, what we did is use a virtual serial driver (com0com) to create a pair of serial ports in software, one for the program and the other for the automation system. This works great and you can install as many pairs as you might possibly need.
The download includes the source and a compiled executable that you can configure at runtime. It should hopefully be mostly self explanatory.
http://people.missouristate.edu/jmcmellen/software/serialwxget_0.5.zip
Posted by
John McMellen
at
4:06 PM
0
comments
Labels: electronics, engineering, hack, radio, serial, virtual, weather, web
Thursday, February 07, 2008
SPLAT! for Windows featured in TV Technology magazine
Doug Lung, a columnist for TV Technology magazine, recently featured the Windows version of Splat! in his RF Technology column. The article provides a good overview of how to use Splat! in Windows for generating Longley-Rice coverage data and maps.
Posted by
John McMellen
at
9:52 AM
0
comments
Labels: engineering, gis, ham radio, prediction, radio, rf, windows
Saturday, January 12, 2008
Alarm relay modification for Comstream demods
An engineer at public radio station KPLU, Lowell Kiesow, has shared a modification to the Comstream ABR700 demods that are now in use for the Squawk channel. This mod implements an EbNo Threshold Alarm contact that is listed in the manual, but was not installed by the PRSS. It is useful to set this as a way of getting notified of satellite system problems, most often as a "snow in the dish" alarm. It was posted with this disclaimer:
Official sounding legal disclaimer: If you break your satellite demod, burn yourself soldering, or get electrocuted, it's not my fault, or the fault of my employer. Don't go crying to the PRSS folks, either. :-)Link to modification http://www.plu.edu/~baumanja/ABR700/
Posted by
John McMellen
at
9:57 AM
0
comments
Labels: electronics, engineering, hack, monitoring, public, radio, satellite
Thursday, November 15, 2007
Measuring and logging HD Radio interchannel delay
The analog FM program audio and the main digital audio are supposed to be synchronized very closely to produce a clean blend between analog and digital when necessary at the receiver. With some work, you can synchronize these down to within a few samples. The problem now, depending on your installation, is keeping it synchronized. A lot of stations are finding that their digital signal drifts in time against the analog. The drift problem is being worked on, but for now, my concern is "How do I keep aware of how well I am synchronised?"
A ham operator and FM enthusiast, Brian Beezley (K6STI), wrote a command line program to cross-correlate the delay error between the two channels of a wave file and output the results to a text file. It seems logical to me that one could automate the recording of audio from a receiver in split mode to create many samples of audio for analysis. Then, another automated script could analyze the sample audio files and output the results in a statistical format. Since it doesn't have to be done in real time, all these data points (timestamped delay error values) could be saved and graphed, showing a nice graphical view of the drift. If you use a package like OpenNMS to collect and log the data, you could even get notification when it drifted outside certain limits. That is one way to keep on top of the drift and know how much it changes.
Posted by
John McMellen
at
11:21 AM
2
comments
Labels: digital, engineering, ham radio, HD Radio, monitoring, opennms, radio
Monday, November 05, 2007
Monitoring the network (and more) with OpenNMS
A thread on Pubtech about SNMP management prompted me to do a little searching on IT infrastructure monitoring and notification. Intermapper has been around for a while, but I didn't feel like hassling with trial serial numbers to try it out since it is commercial software. I did find a great project called OpenNMS. This is open source, free software, and it does a lot. It has been under development for several years and has been implemented in a number of large-scale IT shops. The newest versions have a ton of useful features, and there is a great web front end for managing the app. On the flip side, it was very difficult for me to install set up. Some of that I brought upon myself. I chose to install it on an Ubuntu server, which didn't have anyone to keep the opennms packages up-to-date like the RedHat folks do. I also chose to use the development version because it was said to be feature rich and stable, but I couldn't find precompiled installation packages for Ubuntu. So I downloaded the sources and compiled it myself. Since I had very little experience with that process, it took me a few tries to get all the dependencies worked out. I was ultimately successful, and it runs great. I notice that as of the 1.3.8 release there are packages available for Debian based distributions. Should make installation much easier.
The next hurdle was collecting SNMP data on some of our broadcast equipment. To add the correct SNMP OID's, I had to edit some XML files by hand, which, because of my lack of experience with the software, took a few tries to get right. I also had to edit other text files to build reports visualizing the new data that was being gathered. But, in the end, it still works great, and I can monitor data on generic network equipment as well as some special purpose hardware, like EbNo on our ContentDepot receivers, RSSI on our wireless link to the transmitter and more.
Even better, OpenNMS can send email, page, text message, even IM, if a value gets out of range. This makes it useful for getting notification if there is snow in the sat dish or interference to the wireless link or even if the transmitter shuts down. It can even be integrated into trouble ticket management software, like BestPractical RT. I really like this software and am looking forward to rolling it out for production use.
My next experiment will be to use the HTTP collection agent to pull data from our Burk ARC16 running Autopilot. I have never liked their data storage and reporting functions, so I think it would be neat to integrate the metrics like that into a system-wide monitoring app like OpenNMS. Now that I think of it, I could even turn status alarms into OpenNMS events. Back to work I go.
Posted by
John McMellen
at
1:33 PM
2
comments
Labels: contentdepot, engineering, management, monitoring, networking, opennms, services, snmp, trouble ticket
Thursday, September 13, 2007
RF propagation modeling with SPLAT! for Windows
Many are probably familiar with John Magliacane's RF Signal Propagation, Loss, And Terrain analysis software (SPLAT!). This software is useful for visualizing terrain and performing Longley-Rice path loss and coverage prediction using the Irregular Terrain Model. It had been only available for the Linux OS. I was able to compile it for Windows with a few minor modifications. This is a command line program, freely available under the GNU GPL. I would be happy to include the source code if you are so inclined.
http://people.missouristate.edu/jmcmellen/software/splat-1.2.3-win32.zip
There is a PDF version of the instructions for the Linux version, which is pretty much exactly how it works in Windows too. Some utilities are included as well as instructions for downloading free terrain data for your area. I have only tested it in Windows XP SP2, so if you have any problems, let me know.
Fixes for Windows Port
- 11-12-07 - Fixed error in srtm2sdf.exe that caused it to not work with hgt or bil files.
- 11-15-07 - Fixed error in splat.exe that caused it to generate coverage maps without any loss data plotted when analyzing sites with anything other than default settings.
- 11-15-07 - Changed a trailing "/" to a "\" in the data path option. This never caused a problem in my setup, but might have in others.
- 2-15-08 - Successfully ported the usgs2sdf.exe utility to Windows. Now those who prefer the USGS DEM's as raw terrain data can convert them to Splat data files.
Posted by
John McMellen
at
4:05 PM
79
comments
Labels: engineering, gis, ham radio, prediction, radio, rf, windows
Saturday, June 30, 2007
Moseley Starlink Tech Bulletin
Moseley has released a tech bulletin about a problem with a batch of their Starlink RF STL's. The modem cards develop a significant jitter problem in the oscillators made by Greenray, which causes high BER and audio problems. More information is in the tech bulletin.
http://www.moseleysb.com/mb/service_bulletin/starlink_9003q_service_bulletin_ocxo.pdf
Posted by
John McMellen
at
11:13 AM
0
comments
Labels: digital, engineering, radio, stl
Thursday, April 19, 2007
PREC 2007
What a great conference this year! I attended the PREC in 2005, and I feel like this year was even better than the first. As soon as I get some time, I want to try to summarize some of the things I learned here and at the NAB Broadcast Engineering Conference. Also, keep watching the APRE site as they will be posting many of the presentations and other material from the conference (I think even recordings of the sessions).
http://www.prss.org
http://www.nprlabs.org/apre
Posted by
John McMellen
at
9:52 AM
0
comments
Labels: conference, engineering, public, radio
Thursday, March 22, 2007
See you at the PREC
Posted by
John McMellen
at
11:38 AM
0
comments
Labels: conference, engineering, public, radio