Monday, September 16, 2013

SK: Wayne Green, W2NSD

By now I am sure you have heard that publisher Wayne Green has past away.

There are a number of people posting fond memories of Wayne on the net.

Here is one that I especially liked:

It starts off pointing how important Magazines and people like Wayne who were on the ball with publishing new ideas and technologies was to the dissemination of information and advancement of technology. Wayne often was ahead of the curve, which I suspect is not easy to do in the publishing business. I have noticed at least with QST, it takes a year or better for articles to be published on happening topics. (I figure next year I will read something about the Raspberry Pi and ham radio in QST)

"Before there was a PC revolution, before the days of PC Magazine and MacWorld, before COMDEX, there was Wayne Green."

Now days that role is somewhat diminished, with the internet an all. But some people won't go research things on their own, so shoving the ideas in front of them monthly is still important to keeping things active and moving forward.

David Sumner, K1ZZ on the ARRL website notes a an important technique to keeping things lively in the hobby:

In the early days of packet radio he (Wayne Green) gave me some good advice as to how the ARRL should promote the new technology: ‘Talk about it as if everybody’s doing it, and eventually they will be.’”

A while back a took on a big project in hopes 73 magazine would live on. Wayne did give the okay to place his publications in the public domain. So he maybe be gone, his his legacy lives on.

73 Magazine Archive

Byte Magazine Archive

80 Micro Magazine Archive

Kilobaud Microcomputing Archive

His last three missions toward the end where to change the world on health and oil and education. In his honor it would seem logical to share his Secret Guide to Health and maybe track down the Cold Fusion Magazines.

I think a local New Hampshire paper coined him in the 1980's as the "World's Most Interesting Man," and I have to say that fits him well. I look forward to reading the Wayne Green biography when it comes along. 73 OM!

Wednesday, September 11, 2013

Amateur Radio in 2037

As the focus of my blog has been more of a modern ham radio theme, it seems appropriate to share this video about ham radio in the future.  This is a must-view by all as it provides us timely perspective on the future challenges.

It's from a 2012 webinar, where Chris Imlay W3KD and Ed Hare W1RFI predict and speculate what ham radio will be like in 25 years.

The first part is more a regulatory look by Chris Imlay W3KD, where as the second part is a bit more of a technical/operational look by Ed Hare, W1RFI.

Ed Hare predicting the continued use of Amateur Radio MESH networks, and Software Defined Radio all entangled with the internet.

~57:00 "Software defined radio super stations perhaps accessible by the internet put at locations where you can put up antennas (future antennas restrictions).  This could allow licensed amateurs to log on to that transmitter, that's generating a broad signal across the entire band, filling each little channel within that band with an different actual amateur signal.  So that that all those hams have an easy way to operating from a good location, even if they are operating from an apartment....
Amateur radio will have developed a nationwide amateur radio digital back bone, using a broad range of frequencies and technologies.  I think its going to grow ad-hoc.  Planning is all good, but if you look at the same way the radio relay network was developed in the spark days, we are going to see that same type of approach.  That same type of pioneering spirit.  Ham equipment will be fully integrated with the internet.... 
Analog repeaters will be real legacy technology, replaced by digital repeaters that will allow multiple users on the same spectrum channel.  Right now the repeater paradigm is such that we are limited by the maximum number of possible users.  Where we have a lot of repeater that are used, but might spend 50%, 90% or more of their time not being used.  And in the meantime, nobody else can use that pair.  If we can imagine ways of multiplexing all of these repeaters together so that anytime someone wanted to get on the two meter band on a quote "repeater", a virtual repeater could be created out the multiple repeaters that are there.  Kind of a trunking system on steroids."


At the September 2013 DCC, Heikki Hannikainen, OH7LZB, presented on Friday morning a talk about authenticating amateur radio services on the Internet.

Some of the interesting sites allow you transmit RF, directly or indirectly.  Such as IRLP, EchoLink, Allstar APRS-IS, etc.  And there is more potential for that.  I.e. text messages for DMR, APRS, SDR, and remotely operated stations.

Presently each such service has a different manual authentication method.

The ARRL Log of the World Certificate conforms to the X.509 standard used all over the internet.   It may be installed on web browser, and used to log into web services.  Any third party can technically validate that the web user connecting really has an ARRL LoTW certificate.  Any one implementing this method on their website to restrict access to hams, does not get access to the users private key.   This is the same crypto used by banks and the military.  The ARRL doesn't need to do any addition work to make this happen.  Websites implementing this do not need to query the ARRL anything about the user.  No single point of failure.

There are plenty of developers who would be happy to create new web services for hams.  They just don't have the time or motivation to go though all the license papers to manually authenticate them. - Providing authenticated amateur radio services on the Internet - OH7LZB Video presentation from the DCC
Notes on setting up a OpenVPN server that uses LoTW keys - authentication demo site - Apache configuration and PHP scripts

From the client/user end it looks like this:

Add the LoTW CALLSIGN.P12 file to your browser like so.  Options -> Advanced -> Certificates in FireFox

In the future websites seeking authentication will show this.

If you've ever logged into a third-party web site with your Google, Facebook, or Twitter account by granting the app permission to that respective account, then whether you knew it or not, you've used OAuth (an open standard to authorization.), and it's a great way to dole out permissions.  

Ham Radio needs something simple like this.   It would be great if it could be implemented at the regulatory level (FCC), where your FCC ULS login could be used to log in to other ham radio websites, that seek to authenticate you as a ham.  Fat chance of that, so the next best would probably be the ARRL login.

I also recommend watching Vint Cerf's Re-thinking the Internet, if you haven't already:

Peter, K4PNG did a forward-looking article of his own in his local newsletter (see page 8).

When you are ready to start messing with software defined radio, look into HackRF (capable of transmission or reception of radio signals from 10 MHz to 6 GHz): 

Saturday, September 7, 2013

Remote Ham Radio Station Control

The concept is increasing in popularity, due to renting or whatever the case maybe be that prevents one from setting up a home station.

Oddly enough there are very few straight forward ways to do this.

Not to long ago I detailed how to set up a web based receiver, using a Raspberry Pi, Icecast, and a CIV/CAT capable radio using hamlib:

Think; two cheap Raspberry Pi micro computers.  One with a speaker mic.  Stream with speakfreely, over a VPN, and use the hamlib php web for remote frequency control.
Many are familiar with hamradio deluxe for local station control. It does have remote server and client functionality. What it lacks is a way to transport the audio. You have have to use other software such as Skype to transport the audio.

One of perhaps the most elegant ways to operate remotely is with a fairly new product (2010) from Remote Rig. The RRC-1258MkII consists of two devices; one placed at the host, and the other at the client. They handle remote control and audio. They require no computer either (after setup), just a compatible radio with remove-able head. The head connects to one device, the RF guts to the other, and just ethernet between them.

It's not the cheapest solution, but perhaps one day radio manufactures will adopt this idea of a an ethernet transport cable between the head and radio deck. Till then, ham clubs could invest in one. Many club stations see little use, and this way a number of members (some not able to afford a nice station or able to put up antennas) would benefit.

I have to say however the remote rig guys figured out the TTL communication between the head and deck and managed to encapsulate that in standard TCP/IP is truly awesome.

It even works with radios that don't have direct CIV/CAT control, like the FT-8800, FT-7800, so you don't need to own a really expensive radio to be able to use it remotely.

Perhaps in the future there will be more radios that are remotely tunable (CAT/CIV). It would be awesome if the cheaper handhelds like Baofeng, would support this. Till then, the Kenwood F6A HT works great with Hamlib.

It would be nice if future base/mobiles like the Yeasu ones would just have an ethernet jack on them.
Yeah I know, but it's nice to dream!

Here is some good info about remote transceiver operation: 

Tuesday, August 27, 2013

Microwave data application in Dubus Magazine

Dubus is a quarterly magazine for technology, construction, DX and propagation on VHF/UHF and Microwave bands. It is edited in English and German languages by an international group of hams, printed in Germany.

I have blogged a few times before, on how the amateur microwave bands are so seldom used, and are our greatest allocation, as well as potential area for new development.

The problem is for the most part, the microwave bands sit idle, except for a few contests a year. Dubus is mostly what you'd expect, hams building microwave stations for the quest of a contact record.

I have never been that type, to each their own.

I am more interested in building infrastructure or something a number of hams can use. Which is why I like data networks, as I feel it can support a variety of applications while keeping some constant use of the frequencies.

Dubus 4/2006 - Microwave Japan Seiji Fukushima, PH.D, JH6RTO

High-speed IP connection on 5760 MHz by Hiroyuki, JH1UGF and Tsugno, JN1AYV

We report a 63 km high-speed IP connection on 5760MHz using ICOM ID-1's and modified transverters, UTV5600BIIP. The throughput was measured as about 100 kb/s at the application of layer .

Here are the details.

On the 29th of October, 2006, Hiroyuki, JH1UGF moved to Mt. Toogasa (altitude about 900 metres) and Tsugno, JN1AYV stayed at home in Chagasaki, Kanagawa for this experiment. The distance was 63km and both of us were within the line-of-sight. We used the same systems as follows. Our 1295MHz, digital transceiver was ICOM's ID-1 . To up/down-convert frequency, the 5760MHz transverters UTV5600BIIP were employed but some circuits were modified for this experiment. Since fast T/R switching is quite important, we removed the coaxial relay and added a circulator instead, as shown in Fig.1. In addition, two anti-parallel diodes were Inserted at the RX front end in order not to damage the preamplifier. These diodes cannot be seen In Fig, 1 unfortunately . The driver amplifier is MGF0904A and the final amplifier is 2xMGF1302, which outputs about 1W. We used a homebrew 25cm dish antenna with a horn radiator. Its gain was 25dBi.

We started our experiment. The voice QSO on FM was quite successful, RS 59+, as the distance was short enough . Then, we switched to direct digital mode for IP connection but the result was poor . Using a ping command of MS-DOS, Its connection rate was lower than 10%. Considering the multipath effect, we changed the frequency and/or antenna direction, but in vain. Lastly, Tsuguo moved his entire system , which was initially set in his room, to a balcony. Tsuguo had thought the experiment would have been successful even through a glass window since they had been within the line-of-sight. We got 100% ping connection after this trial.

Then we tried an application experiment. Using IP Messenger (IPmsg) software, Hiroyuki loaded an Tsuguo's image file into the Hiroyuki's PC. Look at our evidence of Fig. 2. The front is Hiroyuki and the back is Tusguo in the inset photograph. The 90KB file transfer took 6 or 7 seconds and, then, its application-layer throughput was calculated to be approximately 100kb/s . We learned that any thin obstacle in the path might make the multi-path interference at high-speed data communication. We would like to make the distance longer and to make the throughput higher in future.

What I did pay attention to in this article was that for the fast T/R switching they used circulators. I am not sure why this never occurred to me. I noticed this concept in 2006 Microwave Technology Letter, titled "Switchless Bidirectional Amplifier For Wireless Communication Systems."

So far this is the only microwave data application I have read in Dubus. I find that a bit odd, as there is a huge microwave data radio network in Germany and Europe.

If anyone else knows of good reading in these areas, I'd appreciate a note.

Saturday, August 10, 2013

HSMM-MESH on Raspberry PI

Recently John Wiseman, GM8BPQ of Scotland wrote a good starting guide (full documentation is still being prepared) on how to use the Raspberry Pi for Broadband-Hamnet/ High Speed Multi-media Mesh networking. John's message was posted on the Amateur Radio Experimenters Corner and Raspberry Pi 4 Ham Radio yahoo groups.


I've tried it with several, including a 1 Watt unit with option for an external antenna. ( . It is worth adding that to power the 1 watt dongle you need a version 2 PI, and a pretty high current PSU.


As there seems to be quite a bit of interest, I've put together some preliminary installation instructions. More technical info, build detail, etc will follow.

Download latest Rasbian image from and write to an SD Card in the usual way. (2GB is enough, but larger can be used). Leave card in PC.

Download and unzip, You should end up with a folder meshautoconf0.4.3.

Check that you have folders lib, proc, sys, dev, etc, bin, files, OpenWRTFiles, PIFiles. I've sometimes had problems with winzip not creating empty folders.

Open the boot partition of the SD card, and copy all the files and folders from meshautoconf0.4.3 into it.

Unmount the SD card, install in PI, and power up, If you have a monitor it is worth connecting it so you can see what is going on.

The PI should boot 3 times. The first time it uses the boot partition as the root partition, and copies a few files to the main partition on the PI. This takes a few seconds. The second time it uses the rc.local file just installed to install some packages (from the boot partition, so no internet is needed). and configure the node. This can take several minutes. It then boots again to activate the MESH configuration.

The files are set up to work the same as a WRT54 node - the LAN port is configured as, with DHCP enabled - so you can connect a PC and configure the node in the usual way (web browser to localnode:8080). Sometimes I've found the PC doesnt get an IP address the first time. If this happens, rebooting the PI should fix it.

I've found it easier to configure the LAN port with an address on my LAN, so I don't have to unplug the PC and connect it to the PI. You can edit file "interfaces" to set an address on your LAN instead of the 172.27 address. If you do this, remember to set the same address when you configure the Node. or you will loose access. You'll need to connect to the IP address:8080 to configure.


(Footnote: The userid/password is the standard HSMM-MESH root/hsmm)

KK6DCI also has a project for building a BBHN node ("Broad Band Ham Net", the new name that replaces HSMM-MESH) on a RasPi at It has been used with a 1 watt Alfa AWUS036 USB wireless adapter (using the aircrack-ng driver for the rtl chip in the Alfa).

So what is the advantage of rolling your own this way, you may be asking?

The real advantage is that you can drive a cheap, relatively high-power USB wireless device, like the 2 watt Alfa AWUS036NH... Also the Alfa devices use the Atheros chipset, instead of the Broadcom chipset used in the WRT54.. devices. Atheros devices can be programmed to work outside of the normal Part 15 overlapping channels.

In addition utilizing different supported-rates, you can take advantage of the different channels with minimal or no overlapping. You may also be able to fit a ham only channel in in band segments not shared with Part 15, resulting in a lower noise floor.

The WRT54 and other embedded devices have a limited amount of on board memory and processor power. This is not an issue if you roll your own using a Raspberry Pi. The Pi will also be able to easily support many running services, like FTP, IRC, etc.

Wednesday, July 10, 2013

The HT of the Future?

Bob, K0NR wrote back in 2012 about the theory of dualband (2M/70cm) handheld transceiver that is built on top of the Android operating system.

He wrote:
"While this hardware configuration is exciting, the real power comes from having a software developers kit (SDK) with a stable Application Programming Interface (API). This would unleash the creativity of all those software-oriented hams out there and a plethora of apps would emerge"
I agree.

Since then, smartphones like the Runbo X5 are available, these have a built in UHF two way radio.

More recently Bruce Perens K6BP has been giving talks about his vision of the "HT of the Future."
Some of his points are:

Narrower bandwidth, not more than 3 KHz
Higher end units run Android, and host applications which communicate over digital radio.

-The prototype we are working on is based on Chris Testa's Whitebox design, and an Android touchscreen computer as the user interface and application host.
-It can run Android applications in conjunction with it's packet, digital voice, or FM two-way radio.

- It has WiFi, Bluetooth, GPS, USB, Ethernet.

The problem is Apps use data to transfer information to work.  If we are talking 1200 or even 9600 baud, then the app space is doomed by this limitation.  There really isn't any talk about apps as those will be a third party thing. However I feel you should identify what some potential ones would be, so that the hardware can be designed to accommodate. I don't see that, so it's more or less; here it is, if you can make it do what you want, cool.  Else not cool. In short I think the data rate will significantly impact what you can do with it.

Whitebox is SDR design optimized for a handheld.  It uses a Flash based gate-array for low power consumption.  The problem is it's a narrow band I/Q modulator design.  This version probably isn't good for spread spectrum. However HackRF, an open source SDR platform by Michael Ossmann would be.

I have written many times that ham radio needs to embrace spread spectrum.  I have also pointed out that is somewhat incompatible with our gentlemen's developed bandplans.

So I'd like to compile a list of things (think big) you'd like to see your future HT do. Here are some of my initial thoughts:

Mesh style, were if your HT can't reach the repeater/ other person it will find a relay (your mobile etc - think same band crossband)

GPS for APRS as well as auto downloading/programming local repeater frequencies on the fly. Street level map display for APRS (android interface)

Voicemail - if your not answering a directed call it will go to a hunt group, and lastly voicemail till next time you PTT (SIP integration)

Ability to use the HT as a remote base for your frequency agile home station.

RTL like ability- able to monitor public safety trunked systems out of of the ham band, while simultaneously monitoring the ham channel.

Please put your thinking hat on. 

Monday, June 17, 2013

Amprnet - net 44

For those who don't know; the amateur radio service has a good chunk of the IPv4 Internet address space (, and it's not being used to its fullest potential. Meanwhile, the rest of the Internet is crowding into the remaining address space and will no longer have any left in the near future.

The address space isn't being used because of a chicken-and-egg problem: the necessary digital repeaters aren't available for users, and there are no users to justify building the repeater network. A background I wrote some time ago.
For mote info see:
Historically the 44 net space has been used by packet radio starting in the 1970's when the IP allocation was first obtained.

But it doesn't have to be limited to just slower packet radio for TCP/IP, either. Some of the newer 802.11 wireless ethernet devices use frequencies that meet with amateur radio spectrum in the 2.4 GHz area. As a result, amateurs can modify the Part 15 compliant devices to increase the power and use better antennas, providing more gain and increasing usable range. These devices are considerably faster at up to 54 megabits per second than the 1200 and 9600 bit per second speeds of VHF and UHF packet radio.

Good connectivity enables a number of applications that were not previously practical to experiment with due to bandwidth requirements; among these could be digital voice repeater linking, digital quality facsimile picture transmission, television (D-ATV), Web-SDR, multimedia, and so on.

European amateurs are the most active users and builders of HSMM/WiFi radio networks.  They have been busy since 2009 building networks.  Most of their network is not directly reachable from the internet as it is an independent radio network.  It can be reached via tunneling from other 44 net addresses.

In the United States there has been debating a bill to create an Internet kill switch, also known as the PCNAA bill. Echolink, IRLP, APRS gateways, and many other services assume the Internet's original distributed design won't allow a single entity to take out the entire network. If the PCNAA passes, this will no longer be true. For true redundancy, a non-critical network can and should be built by the amateur service to avoid this single point of failure.

The cost of the equipment has finally come down to the point where even a modestly funded amateur radio club can afford to set up a small regional network by themselves. Through advocacy and standards development.

Ham radio used to be a good starting place for many who later entered broadcast and electronics careers.  Today those positions are few and far between due to disposable electronics and consolidation of engineers with mega broadcast groups.  What is the most notable/abundant "tech" career today is IT (information technology) work.    Building these networking helps ham radio stay relevant.  These networks have the potential to draw new blood into the hobby.  New hams who have software skills that can help the community with software defined radio and so forth.

In the USA the Broadband Hamnet HSMM-Mesh website is the most active collection of people trying to accomplish the same thing our European amateur friends have.  What their firmware build lacks in a way to use the amprnet and the 44 net address space and it's automatic tunnel connectivity.  The firmware so far also lacks a way to address channels outside of the Part 15 overlap where there is typically a better noise floor.

Attached are some screen shots of interesting things I have stumbled into on the Amprnet.

Sunday, June 16, 2013

Amateur Radio in the 21st Century

Many of today’s experienced engineers got their start in electronics through amateur, or ham, radio.

Over the years, however, the demands of these engineers’ work, families, and communities took precedence, and many hams lost interest and let their licenses lapse. Meanwhile, with the rise of personal communications and Internet connectivity in homes, many young engineers never needed ham radio as a way to explore electronics. They’ve missed the opportunity that this fascinating hobby presents.

The first wireless communicators were by definition all amateurs. Guglielmo Marconi himself, generally regarded as the inventor of radio, once famously remarked that he considered himself an amateur.

Experimenters have created modulation schemes and accompanying protocols, complete with forward-error correction, which enable direct keyboard-to-keyboard contacts even with low power and small antennas.

(Intro taken from an excellent EDN Magazine article written by Doug K1DG)

Above are some current books that help us fulfill part of the basis and purpose of ham radio; to contribute to the advancement of the radio art.

Ham radio is a hobby for those who like to learn (usually by experimentation) and would never be satisfied being just a mere consumer of today's technology and gadgets.

The engineer and hams mindset is "how does this work, how can I make it better?"

There is an excellent fairly new website that I stumbled into along this theme:

And old stand by is the website.

The local club that I belong to recently took a look at their bylaws basis and purpose.

1. The promotion of the interest in amateur radio communication and experimentation.
2. The establishment of amateur radio networks to provide electronic communications in the event of disasters or other emergencies.
3. The furtherance of the public welfare.
4. The advancement of the radio art.
5. The fostering and promotion of non-commercial inter-communication by electronic means throughout the world.
6. The fostering of education in the field of electronic communication.
7. The promotion and conduct of research and development to further development of electronic communications.
8. The dissemination of technical, educational and scientific information relating to electronic communication.
9. Provide encouragement and educational opportunities to any person interested in participating in the radio art.
10. The printing and publishing of documents, pamphlets and other information necessary or incidental to any of the above purposes.
The hard question is how specifically have we fulfilled these in the last year.

I think this is a good idea for clubs, to annually review what there have done in the name of what they are about.

An idea was presented at our most recent meeting to donate some ham radio books to the local libraries (both public libraries and at the colleges). A special committee was formed to investigate what is currently on the shelves.

Being on that committee, license manuals are at several public libraries, along with small scattering of other traditional books.

Ward Silver's "Ham Radio for Dummies" I feel replaces the old Now Your Talking Book. Now Your Talking was not only was a license manual, but also gave a pretty good explanation of the different facets of the hobby. Ward's book does a great job explaining the different facets. There were a few copies of this floating around at the different libraries, which is good.

At the local technical college, there weren't any books specific to ham radio. When I attended, QEX magazine was in the periodicals area. Today there isn't anything of the sort, nor any Circuit Cellar, Elektor, Nuts and Volts or really anything of the nature. I was saddened to see this.

So to help the hobby in the right direction, the books above, I'd love to see in the colleges.

If your club decides to donate books, you can put a sticker on the inside cover to read something like "Donated by the Green Bay Mike & Key Club." To point them in the right direction if the book interested them.

There is plenty of information about ham radio on the internet, but the newer areas currently being explored by hams, isn't as prominently displayed to would-be hams or even the existing hams.

Tuesday, June 11, 2013

Big Bend 50 race use of HSMM-MESH(tm) cover story of July QST

---------- Forwarded message ----------

The July 2013, QST magazine contains an article on page 68 on the use of HSMM-MESH(TM) / Broadband-Hamnet(TM) in support of the Big Bend 50 Ultramarathon foot race.

Beyond that, it is the cover story of the July QST. Our Austin mesh crew made the cover!

Some of you may have known K8OCL, John Champa, who was the first ARRL HSMM Working Group chairman. He is now a Silent Key.

He had a photo taken of him back in 2003, with a "dream" photo-shop edition of QST in his hands with HSMM on the cover. He worked hard for many years to help hams realize that we have been gifted with some mass produced consumer gear ( like the LInksys WRT54G ) that allows hams to get into wireless broadband radio at prices of a lifetime!

I am glad to see that we managed to carry on his efforts with HSMM gear and have actually made the cover of QST, 10 years after he held up his "dream" copy of QST.

Your printed copy of the July QST should arrive soon. Please do what you can to help raise interest in HSMM efforts in your area. It would make John happy to know that the word is getting out - cheap ham gear with massive bandwidth capability, so hams can have their own version of a wireless broadband tool.

-Glenn KD5MFW

Friday, May 31, 2013

A modern ham outlet and open ham authentication

I am very happy to see that Gigaparts has Arduino and the Raspberry Pi available from their online store. They also have Ubiquiti gear.

So let say you want to offer a service to hams, and only hams. How do you verify they are hams? Perhaps you are creating VOIP network, with Asterisk, like Allstar. Or maybe you want to offer a dynamic dns service only to hams or, maybe some web hosting.

It can be a major pain to manage an user account database for thousands of hams and check if your users around the Internet are, in fact, licensed.

It turns out that ARRL's Logbook of the World has already given out cryptographic X.509 certificates to 57334 amateur users, after verifying their license status against the FCC database (they send a postcard with a random token code to the FCC-listed snail-mail address to make sure they give the certificate to the right guy) or after looking at a paper photocopy of a license + a photo ID.
If your registered with LoW, it's not to hard to extract your certificate. This could be used for any number of authentication purposes. One big one comes to mind. Repeater frequency coordination.
Seems this is still done by mailing reminder renewals, and signing and mailing back. If only there was a way to modernize this, and still have a (digital) signature... :-)

Friday, May 10, 2013

APRX running on a Raspberry PI using a sound card

Here are the steps to take to get APRX (as a receive only I-Gate)  to run on a Raspberry PI using a sound card.  Special thanks to Bob, KB8ZXE for providing the info.

This approach is cheap as it doesn't require a TNC or hardware tracker board.  You should be able to throw together everything minus a radio (The Pi, power supply, sound FOB, case etc) for less than $60.

This is assuming that you have taken the steps to make your usb soundcard your default soundcard.  You should refer to my earlier post about how to get that going.  Since then (using the latest Wheezy), I have been successful with USB other FOBs.  I did not need to manually provision /etc/asound.conf

Once you have that going, install the following:

1.) apt-get install libax25 libax25-dev ax25-apps ax25-tools soundmodem screen

2.) Then edit /etc/ax25/soundmodem.conf.  Here is an example:

 <?xml version="1.0"?>  
 <configuration name="AX25">  
 <chaccess txdelay="150" slottime="100" ppersist="40" fulldup="0" txtail="10"/>  
 <audio type="alsa" device="plughw:0,0" halfdup="1" capturechannelmode="Mono"/>  
 <ptt file="none" hamlib_model="" hamlib_params="" gpio="0"/>  
 <channel name="sm0"><mod mode="afsk" bps="1200" f0="1200" f1="2200" diffenc="1" inlv="8" fec="1" tunelen="32" synclen="32"/><demod mode="afsk" bps="1200" f0="1200" f1="2200" diffdec="1" inlv="8" fec="3" mintune="16" minsync="16"/><pkt mode="MKISS" ifname="sm0" hwaddr="W1AW-14" ip="" netmask="" broadcast="" file="/dev/soundmodem0" unlink="1"/></channel></configuration>  

3.) Next, edit /etc/ax25/axports
 # /etc/ax25/axports  
 # The format of this file is:  
 # name callsign speed paclen window description  
 #1     W1AW-14     1200     255     2     144.390 MHz (1200 bps)  
 sm0 W1AW-14 1200 255 2 VHF APRS (1200bps)  

At this point soundmodem should be installed and ready to run. To test this you can feed a radio or test audio file into your soundcard. If you start soundmodem in the background (soundmodem &) and then run axlisten -c -a you should see packets being received.

4.) Download aprx and compile it, (I am using version 2.07 SVN 539) Grab the latests tarball from here:
untar, run the configure script, make, make install.

5.) Edit /etc/aprx.conf  ( I have included a very simple conf file for aprx rx-only i-gate)
 # Simple sample configuration file for the APRX-2 -- an APRS iGate and Digipeater  
 # This configuration is structured with Apache HTTPD style tags  
 # which then contain subsystem parameters.  
 # For simple case, you need to adjust 4 things:  
 #  - Mycall parameter  
 #  - Select correct type of interface (ax25-device or serial-device)  
 #  - Optionally set a beacon telling where this system is  
 #  - Optionally enable digipeater with or without tx-igate  
 mycall W1AW-14  
 pidfile /var/run/  
 # rflog defines a rotatable file into which all RF-received packets  
 # are logged. The host system can rotate it at any time without  
 # need to signal the aprx that the file has been moved.  
 rflog /var/log/aprx/aprx-rf.log  
 # aprxlog defines a rotatable file into which most important   
 # events on APRS-IS connection are logged, namely connects and  
 # disconnects. The host system can rotate it at any time without  
 # need to signal the aprx that the file has been moved.  
 aprxlog /var/log/aprx/aprx.log  
   ax25-device $mycall  
 #  #tx-ok   false # transmitter enable defaults to false  
 beaconmode aprsis  
 cycle-size 20m  
 beacon symbol "R&" lat "4427.28N" lon "08756.22W" comment "sound modem"  

At this point your soundmodem is running and when you start aprx everything should work.  You may want to create scripts that will start soundmodem and aprx on boot. If you run mheardd you can use the command mheard to display recently heard stations.

Friday, April 12, 2013

Raspberry Pi web based rig control?

A while back my friend and I found hamlib, a development library designed to remotely control nearly any CAT/CIV capable transceiver or receiver.  It compiles and works just fine on the Raspberry Pi.

 Before-hand ensure you have these dependencies installed:  
 libltdl-dev or libltdl-devel or libtool-ltdl-devel (use yum/apt-get)  
 tar -xvzf hamlib*  
 cd hamlib*  
 make install  


So we have been using SSH and hamlib to control a remote Icom 706.  We have been using speak freely to stream the audio.

I have been meaning to try and create a PHP/CGI web based front end for this.  Couple that with darkice and icecast for a way to stream audio to that browser.

There is network daemon version of rigctl that works like so:

rigctld -r /dev/ttyUSB0 -m 311 & 

Then control can be done via TCP port 4532:
 root@darkpi-ice:/# telnet localhost 4532  
 Connected to localhost.  
 Escape character is '^]'.  
 f <---- I sent this and got back below:  

Here is a screen shot of my web control front end:

Here is the radio with the Raspberry Pi, USB sound input, USB TTL converter for CIV.
Basically a way to enable web based control of a radio with CIV.  Remi, F4ECW has some example PHP code for this that I snagged from a Yahoo group.  It also appears to have a start for remote fldigi.


Another good project would be to layout a small board with jumper selectable COR and PTT transistor configurations than can be interfaced to the Raspberry Pi GPIO.  So far I have just been bread-boarding this.

I just haven't had the time to create such art work and submit it to Far Circuits.

Again if anyone wants to beat me to the punch on either of this, please do.
Worth reading: "Raspberry Pi: A Tiny Computer for Big Projects" by; Matt, KB3TAN - CQ Magazine, March 2013

Monday, April 1, 2013

HSMM-Mesh to become Broadband-Hamnet


Name will change to Broadband-Hamnet™
Written by Rick Kirchhof, NG5V
Wednesday, 27 March 2013 22:46

A firmware release is scheduled in the 2nd quarter. Some major changes will be included. The list below gives a bit of detail but some changes are already in place. For example or already bring up this site. will  still work but the site will now answer to both. Other things to expect are:

SSID changes to Broadband-HamnetV1

Upgrade ALL is necessary as SSID and the actual format of data flowing will be changing.

SSID minor level (V1) will roll when succeeding firmware requires another upgrade all.

Interoperability with Ubiquiti hand loaded systems (simple web page config for Ubiquiti comes later)

DNS changes from the Austin.TX.mesh style to local.mesh

More FAQs to be written, better documentation on the way

YouTube videos becoming more popular, see "videos" in left menu or search YouTube.

More mesh elmers have joined, more are needed.

Over 1200 registered users on the forums, rising by nearly 100/month.

Web site hits growing at an increasing pace, Google hits for hsmm mesh search terms growing.

QST article in July with more to follow.

Watch here or in the developers newsgroup for updates.
Rick, NG5V

Here are some excellent starter videos from Kevin, N7RXE:


Dave AD5OO has officially released the 1.0.0 Broadband-Hamnet firmware. (8/2013)
This new firmware is NOT backward compatible and has some significant changes upon install by default. Any nodes flashed with this new 1.0.0 will NOT talk in any way shape or form with 0.4.3 (or older) firmware. Its All or Nuthin.

The major change you will notice is that instead of the LAN being in NAT mode, it is now in 5-host DIRECT mode (formerly called DMZ). NAT mode is still available for those who wish to switch back, but give Direct Mode a try, as it makes devices/servers easier to put out onto the mesh.

Also, this firmware now allows those who hand-craft firmware onto other manufacturers' hardware to be able to mesh back with the WRTs we have all come to know and love.

You can read the change log on the site (below the WISH LIST, dont get those confused like I just did myself...), and get the new firmware from the software download page. OR, if your node(s) have internet access, you can go to the Setup-Administration page, click REFRESH next to the Firmware Download section, then use the pull-down to pick the 1.0.0 TRX file.

IF you have mesh nodes already at 0.4.3, you can just choose the generic TRX file without needing to use the hardware-specific BIN files.

But remember, this is a FULL flash: You WILL need to setup as if from scratch (set the nodename and new passwords) once you flash. If you have any services running on a node, backup in some way any customized settings before flashing (dummy me lost a custom script I wrote on one node because I forgot to copy it off the node to somewhere else before I flashed it---LEARN FROM MY MISTAKE!BACKUP BACKUP BACKUP)

I HIGHLY suggest you read the documentation again to refresh your memory, and if you have any questions, the Documentation on the site, Help files, and forums are a great place to start.
Happy Meshing! Jim K5KTF Webmaster & Mesh Geek

Here are some screen shots from the web GUI to show the features of the Broadband HamNet firmware (BBHN).

The purpose of what follows is to show network throughput speeds in a direct verses indirect scenario. There are concerns about significant bandwidth preference hits in a mesh network, when you have to hop though a couple nodes to get where you are trying to go.

The simulation will use three mesh nodes. Where "A' has a HTTP server attached to it, and "C" is the client trying to reach "A". All are spare WRT54 series Linksys units that were floating around. The output power was adjusted to 1 dBm and TX and RX antenna were set the same on the basic configuration page. The use of dummy loads, and a little physical distance will then help simulate a situation where nodes "A" and "C" cannot reach each other directly. This is where we will introduce node "B".

The HTTP server is a Raspberry Pi B+, running apache. It is connected to Node "A" via the LAN port of the WRT54G.

The client computer is an old Sony PIII laptop running XP. It has a Windows version of Wget installed to retrieve the file from the Raspberry Pi Webserver since it has a convenient throughput output. The laptop is connected to the LAN port of node "C".
MB/s = MegaBytes per second KB/s = KiloBytes per second

First some baselines for comparison:
Wired Direct:
C:\Program Files\GnuWin32\bin>tracert

Tracing route to over a maximum of 30 hops

1 1 ms 1 ms 1 ms localnode.local.mesh []
2 3 ms 2 ms 2 ms

Trace complete.

C:\Program Files\GnuWin32\bin>wget
--2014-10-17 03:38:07--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 7.89M/s in 4.2s

2014-10-17 03:38:11 (7.91 MB/s) - `file.tar.gz' saved [34764375/34764375]

With DD-WRT, standard Wireless AP/Client configuration
(DD-WRT AP has the Pi at
C:\Documents and Settings\Owner\tracert

Tracing route to raspberrypi [] over a maximum of 30 hops:

1    20 ms     1 ms     1 ms  raspberrypi []

Trace complete.

--2014-10-18 22:23:42--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'

100%[======================================>] 34,764,375 2.80M/s in 12s

(2.79 MB/s) - `file.tar.gz' saved [34764375/34764375]

Using BBHN, direct, from node C to A (100 % Link Quality):
C:\Program Files\GnuWin32\bin\tracert

Tracing route to over a maximum of 30 hops 

1     1 ms     1 ms     1 ms  localnode.local.mesh [] 
2     3 ms     1 ms     3 ms  kb9mwr-A.local.mesh []
3     3 ms     2 ms     2 ms

Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'

100%[======================================>] 34,764,375 1.90M/s in 17s

2014-10-17 02:58:02 (1.06 MB/s) - `file.tar.gz' saved [34764375/34764375]  (1900 KB/s)

Using BBHN, direct, from node C to A (16 % Link Quality):
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'

100%[======================================>] 34,764,375 1.11M/s in 31s

(1.06 MB/s) - `file.tar.gz' saved [34764375/34764375]

BBHN indirect, through B (100 % Link Quailty):
C:\Program Files\GnuWin32\bin\tracert

Tracing route to over a maximum of 30 hops 
1     1 ms     1 ms     1 ms  localnode.local.mesh []
3     6 ms     6 ms     6 ms  kb9mwr-A.local.mesh []
4     6 ms     6 ms     7 ms 
--2014-10-18 17:49:18--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'

100%[======================================>] 34,764,375 279K/s in 1m 43s

2014-10-18 17:51:02 (329 KB/s) - `file.tar.gz' saved [34764375/34764375]
82.68 % slower throughput, compared to the  direct A to C connection!

The automatic routing that a Mesh network provides is very handy for issues; of interference between nodes, fading and other temporary obstructions that crop up in the path. It is beneficial because the connection can continue, instead of dropping out completely. It also simplifies configuration, which is a real benefit for end users or quick deployments, where the users might not be familiar with the network topology.

However, as you can see, there really isn't a replacement for good network planning. Hops should always try and be minimized in the network design. Dedicated back bone channels should exist between high profile user end access points, to essentially provide a full duplex radio link back. This will help eliminate the throughput problem that occurs with half duplex radio links.

Suggested reading: 

Now using Ubiquiti gear:

With Nano M2 to M2 using UBNT firmware one as AP the other as station, standard 20 MHz channel:
C:\Program Files\GnuWin32\bin\tracert

Tracing route to over a maximum of 30 hops

1 3 ms 1 ms 1 ms

Trace complete.

--2014-11-04 15:17:24--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'

100%[======================================>] 34,764,375 3.50M/s in 9.5s

2014-11-04 15:17:34 (3.48 MB/s) - `file.tar.gz' saved [34764375/34764375] (3500 KB/s)

BBHN indirect using Ubiquiti gear, through B (100 % Link Quality):

C:\Program Files\GnuWin32\bin\tracert

Tracing route to over a maximum of 30 hops 
1     1 ms     1 ms     1 ms  kb9mwr-c [] 
2     4 ms     4 ms     3 ms  kb9mwr-b.local.mesh []
3 7 ms 8 ms 7 ms kb9mwr-a.local.mesh [] 4 6 ms 8 ms 5 ms Trace complete. 
--2014-11-04 17:10:18--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'

100%[======================================>] 34,764,375 965K/s in 36s

2014-11-04 17:10:53 (955 KB/s) - `file.tar.gz' saved [34764375/34764375]
72.71% slower throughput, compared to the  direct A to C connection! Note that there is about a 10 % improved throughput using the Ubiquiti gear over the Linksys!  A large part of the throughput hit is related to the fact that collisions are likely going on, as the relay node is transmitting, the server is likely sending its next frame, for example. I was told that 802.11n capable chipsets (like the Ubiquiti M2 line), there are enhancements related to the RTS/CTS mechanism to help with this.  And apparently this is so after performing these tests. A large part of the significant slow down (50-60%) between the direct and the second  is because the channel becomes a half duplex link that has to repeat the content (same as 1200 baud through a digipeater) but would expect it to taper off the more hopes you get as you get to a point where one set of nodes is receiving while another is transmitting.

Family Guy - Ham radio

Last night's episode of Family Guy was a re-run from Season 11, Episode 3 that originally aired  10/21/12, titled "The Old Man and the Big 'C'."  It had a quick reference to ham radio.

At a ballgame, Quagmire accidentally loses his toupee going for a fly ball. When he becomes a laughingstock, he decides to ditch the wig. The change in his appearance affects his attitude, changing him into a old man.  Quagmire runs a radar gun in-front of Peters house asking hot rodders to slow down.  "My ham radio interferes with my radar gun.  Talked to some fella in Papua New Guinea last night, you should stop by some time."

Wednesday, February 27, 2013


I posted a link to the Advanced Repeater Systems Webpage, titled No Ham Narrowband FM on twitter. Subtitled: "If you're not upgrading to digital, don't downgrade to Narrowband FM!"

For the most part I agree with it.  Mostly I liked the technical analysis of the issue.

I received a tweet back, asking if I was for or against narrowbanding on Ham bands.  He seemed to think I would be for it, being more of a tech guy.

I responded I think we need to go wider.

Several years back, I explained why I feel this on my VOIP/DV page.

Hams are not bound by these narrowband rules, refarming nor will there ever likely even ever be a rebanding.  We have oodles of spectrum available to us, most of it un-used.
What is actually disappointing about D-Star is that  it's only a 4800 baud total data stream equivalent signal.  2400 bps is reserved for actual digital voice, 1200 bps is reserved for FEC (forward error correction)  on the digital voice.  (This is for callsign and short message data.)  1200 baud is reserved for serial data low speed digital data .  (This is for APRS, and text messages/text query's.)  The sad part is 1200 baud data is what we were doing in the 1980's. 
So if 4800 baud can fit into a 6kHz bandwidth, we could have had a 12800 (12.8k) baud total data stream equivalent signal fit into our existing 16 kHz bandwidth plans.  This could have left us with 9.2k left for data.  Or at the very least more could have been given for the digital voice codec, so that we could use other license free-codecs that sound more natural.

Less far back, I blogged about the problems with frequency coordination.

What bothers me is that most of the VHF-UHF bands are inundated with mostly inactive repeaters.

The problem is frequency coordinators have broken the bands into channels most fairly narrow in width, with conventional input and outputs. I think this image/model discourages potential other use, that may not fit the convention.
And my last blog was about a potential rules re-write to encourage some new developments in the hobby.

Ham radio has always used hand-me-down gear from the commercial world.  And I would be absolutely irate if some coordination body told me as an existing repeater owner that I had to narrow band.

I think a some guidelines would be;

-If you are putting a new analog repeater on the air, if it's narrow band capable, it should be.   To start a 5-year phase-in plan for 6.25kHz channel centers and mandatory 2.5 kHz narrowband FM deviation on analog. 

-The number of wide band and narrow band analog channels needs to be rationed.  I'd like to see some effort to slowly over time (via attrition)  clear out and reserve some wider channels on the VHF and UHF bands for new techniques.

-I think when it comes to coordination requests, newer modes should be given priority.  If there are 10 analog repeaters in a given area, and someone proposes to put up a P25 system, but there are no channels available... back to rationing space for older modes.

Of all the VHF/UHF digital radio modes I have played with.  I like TETRA the most, as it's the most versatile.   The biggest problem is price.

It supports 4 TDMA channels in a 25 kHz bandwidth channel.  Mototrbo/DMR does 2 TDMA channels in a 12.5 kHz bandwidth channel.

The main reason I like it is because it doesn't sound digital.  It sound like a telephone grade voice path.  This is because the radios also function like mobile phones.  There is Asterisk SIP tie in support.

And for IP packet data services, DMR offers a throughput of 2.0 kb/s per timeslot, whereas TETRA offers 3.5 kb/s per timeslot.  So if you code an application for DMR that uses both slots, the max is 4 kb/s.  With TETRA 4 timeslots can be combined into a single data channel to achieve higher rates.

And if you are not in range of the repeater system, DMO mode allows you to repeat though a sequence of one or more TETRA terminals as relays to reach your destination.  (Think same-band crossband using alternate time slots)

So in summary, narrow banding just so we can have more of the same (under used analog repeaters) is just plumb stupid in my opinion.

Here are some relation observations that I made early in 2011:

During an interview, the Beaver Valley ARA revealed that ARRL President, Kay Craigie, N3KN got licensed in 1983 because she was jealous of all the fun her husband was having with ham radio. She was a computer hobbyist at the time and became a ham just when computers were starting to be integrated with amateur radio.

So it would seem natural to assume her stance on the future of digital communications is strong.

Brennan Price, N4QX is the new Technical Relations Manager filling the vacancy created by the retirement of Paul Rinaldo, W4RI.

It was Paul, W4RI's recommendation (back in 2001), to the Board that  the HSMM Working Group be founded and he has written many-many articles over the years on packet radio and other digital aspects.

I don't know much about Brennan, N4QX, other that his stated goal is  to "defend Amateur Radio spectrum. So it would seem that encouraging new uses and techniques would be logical.

I fell strongly about the ARRL Technology Task Force. I hope he can  fill the shoes as well as Paul did.

So far I haven't really seen anything happen at the league level that affirms my above assumptions of these two.  I kind of expected these jokers to file comments to the FCC along the lines of what Bruce Perens did in terms of getting some rules relaxed to help move things forward.

Tuesday, February 5, 2013

Bruce Perens pushes for a major rules re-write.

Bruce Perens, K7BP a well know open source advocate and proponent of Codec2 filed FCC comments to the on-going petition for rules chance to allow TDMA used by MotoTrbo.

Some back ground:

The KA9FLX repeater in Chicago, IL was the first Mototrbo Amateur Radio Repeater. It was put on the air in 2008.

In March 2011, some overly concerned fellow Amateurs brought a emission rule technicality to the forefront.  Apparently the classified emission type doesn’t match those specifically allowed for ham radio.

At the time of the petition, there are more that a dozen Mototro repeaters in service on amateur frequencies.  Since then, over 90 repeaters have been reported as up and running.

The processing time of requested FCC rule changes for all services is enormous.  For example, the  request to Eliminate the Spread Spectrum Automatic power control Requirement took 4 years to be approved.

For the past several years, all the ARRL initiated petitions for FCC rule changes have been very narrow requests. 

In Bruce’s comments he points out that the regulatory framework continued by this NPRM would not handle software-defined radio well.

The point is that development is already rapid, and will only increase. The current regulatory framework will not keep up with this development.

This contrasts starkly with Amateur Radio's mission to advance the state of the art.

The present system that FCC must approve each significantly different modulation type to reach Amateur Radio only causes Amateur Radio to fall further and further behind in terms of developments.

Continuation of this piecemeal process of authorization would place severe regulatory hurdles and hinders the capability of Radio Amateurs to experiment and innovate.

I wrote Bruce to thank him for his comments.   A major rule revision like he is proposing is long over due in my opinion. 

Why the ARRL hasn’t gotten behind a major rule re-write like he is proposing is beyond me.

Apparently, their ideology on getting more amateur activity has focused on consolidating the license classes, instead of helping enable new technologies that might help foster more interest in the hobby.

Monday, January 14, 2013

Raspberry Pi and Sound Input

If you are a Ham Radio Operator you've probably been looking at the Raspberry Pi with a lot of possibilities.

One of it's downfalls if the lack of an on-board input.  But once you add a USB sound fob, Echolink, remote rig applications, IRLP, and decoding various digital modes like PSK, and so on, are all a reality.

Finding a USB sound device and setting it up can be aggravating.

I recommend the SYBA SD-CM-UAUD USB CM119 audio adapter.

If lsusb doesn't report it as below, you have the wrong one:

root@pi:~# lsusb 
Bus 001 Device 005: ID 0d8c:000e C-Media Electronics, Inc. Audio Adapter (Planet UP-100, Genius G-Talk) 

Next you need to make the usb sound card (0) the default audio device
Check yours like so: cat /proc/asound/modules
0 snd_bcm2835
1 snd_usb_audio

Edit /etc/modprobe.d/alsa-base.conf comment out "options snd-usb-audio index=-2"
You want ""options snd-usb-audio index=0"

After a reboot it should always appear in this order:
0 snd_usb_audio
1 snd_bcm2835

Take this one step further and comment out the kernel module for the onboard sound and add the usb

cat /etc/modules should look like:

While, I did not find the following necessary in my case, I have read to get better latencies out of USB audio devices, it is suggested to also add:

options snd-usb-audio nrpacks=1

Setup /etc/asound.conf to this:

 pcm.dmixer {  
   type dmix  
   ipc_key 1024  
   slave {  
     pcm "hw:0,0"  
     period_time 0  
     period_size 1024  
     buffer_size 8192  
   rate 48000  
   bindings {  
     0 0  
     1 1  
 pcm.asymed {  
     type asym  
     playback.pcm "dmixer"  
     capture.pcm "hw:0,0"  
 pcm.dsp0 {  
   type plug  
   slave.pcm "asymed"  
 pcm.!default {  
     type plug  
     slave.pcm "asymed"  
 pcm.default {  
   type plug  
   slave.pcm "asymed"  
 ctl.mixer0 {  
   type hw  
   card 0  

Since there are some USB issues, I suggest setting the device to boot the USB hub in  USB 1.0 mode, this should fix choppy audio. (I did not find this necessary in my case, but it's not a bad idea)
Add "dwc_otg.speed=1" to /boot/cmdline.txt.

Pulseaudio might be part of your raspberry wheezy default image.  Personally I am not a fan of it, and have read it wasn't working well on the Pi.  I am not sure if that still holds true.  I just removed it:
apt-get purge pulseaudio
I recommend replacing it with Alsa.  It has been around a bit longer:
apt-get install  sox alsa-oss alsa-utils alsa-tools  

Also, I suggest updating the firmware on your Pi.

This should be a good starting point for most.  Hopefully in the future, newer Raspberry wheezy images can make this a bit easier, and more kernel support for other USB sound FOBs.

For my fellow hams you may want to check out these places to congregate:

And for those of you still interested in D-Star: 

I have been running my Pi using a 5 volt, 1 amp supply via the micro USB power port.  I do not use a USB hub.  My model B rev 2 has been running reliably for a few weeks now.

Just as a note.  If you are making connections to the GPIO for keying a radio or whatever, check your local Radio Shack for "Schmartboard Jumpers ."  These are a new thing they are carrying, and are handy.

Sunday, January 6, 2013

Raspberry Pi Autofox?

I stumbled into a wiki on Turning the Raspberry Pi Into an FM Transmitter.

The code uses the hardware on the raspberry pi that is actually meant to generate spread-spectrum clock signals on the GPIO pins to output FM Radio energy.  Just add a quarter wave length of wire to GPIO 4 to act as an antenna.

root@raspberrypi:~# ./pifm
Usage:   program wavfile.wav [freq] [sample rate]

Looking at the source, it seems simple enough to narrow it a bit: 
In pifm.c look for:

float dval = sample*15.0;  // actual transmitted sample.  15 is bandwith (about 75 kHz)

Obviously this isn't a clean transmitter implementation, so don't expect much more than an autofox.

For a low power foxhunt it might amusing to wire a motion sensor to the other GPIO to adjust your transmit and announce timing cycle, when folks are getting close.

{Update 3/13}
Apparently some people think like me:

Plenty of folks using the basis of this for Weak Signal Propagation Reporting


It would also be interesting to use it as a Part 15 FM transmitter with modified code to allow a GPS for transmitter phase locking.

{Update 8/14}
Alessandro, IK1PLD released a binary to the Yahoo Raspberry_Pi_4-Ham_RADIO group:
Narrow Band FM transmitter derived from pifm. It is able to transmit FM from VLF to UHF with a settable deviation and pre-emphasys, frequency correction and subtones. It runs under debian distr.   In a SSH session type ./nbfm.out for help.