Experimentation seems lost in the hobby. This is my attempt to spread some new ideas and help enable those who want to explore something new..
Thursday, May 13, 2010
An Univeral Radio Interface
All of the various digital modes out there require some sort of interface to your soundcard. Most of these interfaces use the serial port (RS-232) for keying, or some of the newer "Rig-blaster" interfaces can do provide that over a USB connection in the absence of traditional com ports on the newer computers.
There is still one thing lacking. Their own dedicated sound card. There is nothing more embarrassing than forgetting to disable your computers system sounds. And on the same token having to mess with the mixer settings each time is also annoying.
Thanks to the hard work of Steven Henke, W9SH and Jim Dixon, WB6NIL, they have ground work for a Univeral Radio Interface.
You can build your own using inexpensive USB sound FOB's/sticks. Or you can buy a pre-manufactured interface from DMK Engineering.
The basis of it all is the C-Media electronics CM-108, CM-108AH, or CM-119 USB interface chips.
PTT and optional Carrier Detect are accomplished using unused general purpose I/O lines of the USB sound devices chipset. Just plug this into a USB port of your computer, no other connections to the PC are necessary!
If you build your own, the sound fob will require some modifications to bring out PTT, block DC on the audio outputs, and attenuate the receive audio to match the microphone levels.
http://www.qsl.net/kb9mwr/projects/voip/USB-FOB.pdf
http://www.qsl.net/kb9mwr/projects/voip/usbfob-119.pdf
Unfortunately the number of programs that support this type of interface are presently limited. The good news is any one coding a program like ham radio deluxe or the like can easily adopt support for this interface. The channel driver is open and authored by Jim Dixon, WB6NIL and Steve Henke, W9SH.
If you an author of such a program you can find the definition in file chan_usbradio.c. I encourage you to add support for this inexpensive to build interface.
Sunday, May 9, 2010
WinLink Failure
At the April 8th meeting of the Green Bay Mike & Key Club, Dennis, KC9OIS had an ARES report on a demonstration of a mobile Winlink station and it's emergency email capability.
The station was setup by Outagamie County ARES at the Paper Valley Hotel in conjunction with the WI ARES/RACES at the WI Governor’s Conference in March on Emergency Management....
While the demonstration was successful, John, NA9J and my (Dennis, KC9OIS's) messages never reached their destination successfully.
Paul, N5XMV writes:
I don't see the purpose of continuing to find new ways to use Ham Radio, whether for experimental, emergency, or commercial use, if the average Ham is not able to understand the full concept, build it, and implement it... What happens when it fails, reach over, and get a new piece out of a stockpile of new stuff??
Paul, N5XMV, makes a good point. Emergency communications weakest link is in the operator behind the equipment.
At the same time, exercises and demonstrations like this let you experience the mistakes and correct them before the time comes that you actually need to rely on it. My question is what is being done to prevent a repeat performance?
I don't know much about how the Winlink network works. But it seems to me that if "emergency" messages can be lost, this is Not a well thought out design.
Are outdated networking protocols are the basis of Winlink? It sound like a kludge of much how the old KA-nodes worked, and the hierarchical BBS message forwarding using a system of mail rewrites and mail exchangers.
Ouch!
RFC's for SMTP mail delivery ensure that the sender should get a return message in the event that a message is undeliverable to to a broken path route or server being down. If Winlink cannot at the very least support this, perhaps it's time to re-think the network topology.
Think "real-time network" .... it can be done. In the 90's we here in Wisconsin could test the deliverability of a message with the ping command.
traceroute is another good network debugging tool.
Here is an old reference on Emergency Operations and Packet Radio
http://www.qsl.net/kb9mwr/wapr/wiscnet/part31.html
Here is some interesting history on Winlink.
July, 2003: In cooperation with its partnership with Homeland Security & at their recommendation, the ARRL Board sought to provide a Nationwide digital system to enhance the communications capability of the Amateur Radio Emergency Service (ARES) There are situations, the Board said, when ARES "must have the capability to pass digital traffic across the Nation quickly and accurately.
ARRL Resources Volunteer Committee determined that the new network should: provide rapid transfer of emergency traffic between sections; use available and future digital modes, interface with commercial communications systems such as conventional telephone, cellular telephone, and the Internet, etc., have speed, performance and accuracy.
The digital network will provide a value-added service for ARES and will continue to be viewed very positively by our served agencies," the committee said in its report. "This allows ARES to be viewed as modern and necessary instead of antiquated and invasive."
A quote from the former FCC Director of Engineering and Technology:
In the past, hams have adopted more spectrally efficient technologies - for example, by migrating from double-sideband amplitude modulation to single-sideband modulation and, more recently, by shifting to more efficient modulation for digital modes. I would urge you to continue shifting towards more spectrally efficient communications techniques - especially digital techniques. Such a shift has a number of benefits:
First of all, it demonstrates to policymakers and regulators that you are good stewards of the public's airwaves even without direct economic incentives.
Second, by using what you have efficiently, it strengthens your case when you need to ask for additional spectrum.
Third, by allowing more users to access the available allocations simultaneously, it improves the amateur experience and ultimately increases the attractiveness of the service to new and old users alike.
Fourth, it provides the opportunity or "headroom" for increases in data rates to more closely match those available on wire line networks and, in the future, on commercial wireless networks as well.
Fifth, as the rest of the telecommunications world makes the transition to digital techniques - and there are very few exceptions to that trend - the amateur service will look antiquated if it is not making progress in that direction as well. So looking to the future of the amateur radio service in the new century, I would urge you to continue your traditional role in public service by being prepared for and providing communications in times of emergencies, conducting experiments, providing training in radio communications, and encouraging international comity. But I would also urge you to focus particular attention -- for the reasons I just mentioned -- on experimentation with digital techniques."
So far the basis of Winlink on a county/state level seems to rely on 30 year old packet radio technology.
For example it will take over and hour to send a 540 KB .xls file of names... or in just a half an hour you might be able to send a 270 KB attachment at 1200 baud.
So even if the demonstration messages would have made it, Winlink still appears as a failure to me in that regard.
Friday, May 7, 2010
NWR SAME software decoder?
Server weather season is upon us.
I have often thought it would be nice if there was an open source (soundcard/ FOB based) SAME decoder solution.
One could dedicate a cheap USB sound FOB to a receiver parked on their NOAA weather radio frequency that would sit and decode any SAME data bursts.
I am thinking for interfacing to repeaters to provide custom weather alert signaling.
It does appear that software to decode SAME data exists, just not open source.
http://www.dxsoft.com/en/products/seatty/
A SAME software decoder would benefit projects like thelinkbox, and asterisk app_rpt as well as other projects.
{Update 6/11}
Greg Hewgill, has updated the source to his NWR tools, now at:
https://github.com/ghewgill/nwr
"Drew" Kirkman, W4KMC writes:
"TECHNICAL INFORMATION:
NOAA’s Specific Area Message Encoding (or SAME) protocol is used to further streamline the Emergency Alert System. Information about an emergency message (such as locations affected, type of message, where it’s coming from, and how long it will be considered effective) is transmitted in the form of digital bursts at the beginning and end of said message. These bursts are AFSK-modulated data with a throughput of 520.83 bits per second. Mark tone (binary 1) is 2083.3 Hz and space tone (binary 0) is 1562.5 Hz, with each tone lasting about 1920 microseconds. Bytes are transmitted in reverse order (LSB -> MSB), that is, 00010111 would be transmitted as 11101000. There are other technical specifications regarding its use in the real world, but it’s irrelevant here. Essentially, if you handed the right text to it, I have a SAME encoder. It outputs true SAME-encoded data."
See his NOAA SAME web based audio encoder/decoder at:
http://www.drewkirhttp://www.blogger.com/img/blank.gifkman.com/projects/noaa-same/
I also stumbled into:
"Using an Arduino Uno and a few other external components, I've been able to reliably decode the SAME messages."
http://www.raydees.com/Weather_Radio.html
{Update 2012}
Someone updated multimon, and it now has EAS / SAME decoding support!
https://github.com/EliasOenal/multimonNG/blob/master/README
I have often thought it would be nice if there was an open source (soundcard/ FOB based) SAME decoder solution.
One could dedicate a cheap USB sound FOB to a receiver parked on their NOAA weather radio frequency that would sit and decode any SAME data bursts.
I am thinking for interfacing to repeaters to provide custom weather alert signaling.
It does appear that software to decode SAME data exists, just not open source.
http://www.dxsoft.com/en/products/seatty/
A SAME software decoder would benefit projects like thelinkbox, and asterisk app_rpt as well as other projects.
{Update 6/11}
Greg Hewgill, has updated the source to his NWR tools, now at:
https://github.com/ghewgill/nwr
"Drew" Kirkman, W4KMC writes:
"TECHNICAL INFORMATION:
NOAA’s Specific Area Message Encoding (or SAME) protocol is used to further streamline the Emergency Alert System. Information about an emergency message (such as locations affected, type of message, where it’s coming from, and how long it will be considered effective) is transmitted in the form of digital bursts at the beginning and end of said message. These bursts are AFSK-modulated data with a throughput of 520.83 bits per second. Mark tone (binary 1) is 2083.3 Hz and space tone (binary 0) is 1562.5 Hz, with each tone lasting about 1920 microseconds. Bytes are transmitted in reverse order (LSB -> MSB), that is, 00010111 would be transmitted as 11101000. There are other technical specifications regarding its use in the real world, but it’s irrelevant here. Essentially, if you handed the right text to it, I have a SAME encoder. It outputs true SAME-encoded data."
See his NOAA SAME web based audio encoder/decoder at:
http://www.drewkirhttp://www.blogger.com/img/blank.gifkman.com/projects/noaa-same/
I also stumbled into:
"Using an Arduino Uno and a few other external components, I've been able to reliably decode the SAME messages."
http://www.raydees.com/Weather_Radio.html
{Update 2012}
Someone updated multimon, and it now has EAS / SAME decoding support!
https://github.com/EliasOenal/multimonNG/blob/master/README
And this PHP-based SAME AFSK encoder: http://www.whence.com/minimodem/
Subscribe to:
Posts (Atom)