Project Byzantium: Development Sprint #2.
During the last weekend of March in 2011, a few dedicated hackers met at HacDC for the second development sprint of Project Byzantium. Our goal this time was to improvise devices by which gateway nodes of two mesh networks could relay traffic beyond the range of wi-fi to solve the mesh density problem (not enough nodes covering enough ground for complete connectivity). We had a couple of ideas for making a serial link between two mesh nodes that would act as network gateways on each mesh to forward traffic. Traditionally, the easiest way of linking two different systems was over a serial connection. Ultimately, this is what modems do: they take bits from a serial port, convert them into sound which goes over a phone line (modulation), are received by another modem, and are converted back into bits. Representing bits is easy, all you need are two different symbols to differentiate one from zero. The lowest common denominator of all of our laptops was the sound card, so the bits were represented by alternating tones.
Additionally, you can run arbitrary network protocols over a serial connection. If you think back to the days of dialing up to an ISP to get online using SLIP or PPP, that's exactly what you were doing. SLIP and PPP were used to run TCP/IP over dialup (as opposed to Ethernet or wireless), though you could theoretically run any network layer protocols over it. The transmission medium doesn't have to be a phone line, it can be anything that you can signal ones and zeroes over.
Rather than excavate our respective closets to find the modems that are no doubt hibernating somewhere we opted to go for software emulation with soundmodem. Soundmodem has been used by the ham radio community for many years for packet radio; it uses the CPU to do the signal processing and the sound card to generate and receive tones over well documented interfaces (the headphone and microphone jacks). In a lot of ways it's easier to work with than hacked dialup modems which were designed to only work with the PSTN. Soundmodem implements selectable baud rates (1200, 2400, on up to 9600 bps) as well as different signaling modes (which only really apply when used with amateur radio, though as the later parts of this article may suggest it might be worth experimenting with them). It's been around for well over ten years and appears to have been designed specifically for running the AX.25 data-link protocol over radio.
For the purpose of this discussion, think of AX.25 in the way you'd think of SLIP or PPP - it lets your computer build network connections over top of communication technologies that you wouldn't ordinarily consider. Or to put it another way, it lets your computer access data networks the way it does in the movies (i.e., magickally).
The theory is that, once the AX.25 interface is activated and configured with an IP address and routes you can use it just like you'd use an Ethernet or wireless interface. Perfect for our experiment, or so we thought. The sound-to-modulated-something-else-circuit from issue number sixteen of Make Magazine was fairly easy to assemble. It had only four components (one of them an audio transformer) and looked flexible enough that different emitters could be connected to the output end. Our experiments involved connecting cables built using that schematic to the sound cards of our laptops to convert the audio generated by soundmodem into electrical signals that were then piped into the emitter. Our first idea was to use commodity FRS/GMRS transceivers to send and receive network traffic across the room at HacDC for proof of concept. For the record, the FCC says that this is illegal. Our reasoning was that, in a real emergency situation FRS radios are easy to get (many are basically childrens' toys but some nicer models exist), are relatively easy to modify, and do not interfere with other bands of radio traffic such as amateur radio, the command and control radio nets of law enforcement agencies, or rescue efforts.
Once again, doing this is against the law. Don't do it.
After monitoring the channels for a short time to make sure that no one else was using them we transmitted for brief periods at the lowest power available to us. For our purposes FRS radios that have jacks for headphone/microphone headsets are ideal, you just need a standard stereo phono plug to patch into them (you'll have to figure out how to wire them up with a multitester; it's possible to detect current by putting bare wires into your mouth but we don't recommend this). As stated earlier, it's relatively easy to open the casings of radios but it's not necessarily easy to patch your own circuitry into them. I found that unsoldering the speaker wires was easy but unsoldering the electret microphone element from the printed circuit board so I could replace it with a pair of wires was not possible. It might have been the soldering iron I was using at the time or it could have been something else. Either way, the solder wasn't melting but the PC board was beginning to scorch so the pair of radio's I'd picked up had to be set aside in favor of others that required less modification. Another problem we ran into was getting FRS radios to operate in half-duplex was difficult. A few of the radios had VOX (voice operated transmission) circuits, so whenever the microphone input was engaged the transmitter would turn on, otherwise they were in receive mode. Sadly, this does not mean that they are practical for data communication.
To call them unreliable would be an accurate assessment. On Friday night we tried pairs of FRS radios per laptop (one transmitting and patched into the headphone jack, one receiving and patched into the microphone jack), which seemed to work somewhat better than single radios receiving by default and transmitting in VOX mode (which didn't really work). Transceivers with VOX support were set to automatically transmit whenever current hit the microphone stage (i.e., whenever a packet hit the AX.25 interface), and radios that didn't had their push-to-talk keys held down with rubber bands, effectively claming one of the channels. We also had a bit of trouble getting organized at the start of the test - making sure that we were transmitting and receiving on the right channels (I was sending on 8 and receiving on 9, the other was receiving on 8 and sending on 9) (that I just had to rewrite that sentence because I got things backward should be illustrative). I also discovered that tcpdump doesn't support AX.25. We had to install the ax25-apps package on our laptops to get the /usr/bin/listen utility, which is a specialized packet sniffer designed for AX.25 interfaces.
After messing around with this configuration for a couple of hours we came to some conclusions. Getting packets from one laptop to another over FRS cleanly and clearly appears to be highly dependent upon many variables: the sound chipset in the laptop, the cables used to patch the laptop into the radios (and there are many crappy ones out there, as improvised ones are likely to be), the respective volumes of the headphone and speaker jacks on the laptop, and speaker volume of the receiving FRS radio. In point of fact, when audio circuits are driven too hard (i.e., the volume is too high) the sound is distorted and thus the information is corrupted. By the end of the night, after much tweaking, fussing, and cursing, only about 80% of the packets transmitted from laptop to laptop were successfully received, with an average latency of about 35000ms - significantly worse than dialup. The aforementioned copies of listen on either end displayed lots of ARP traffic and outgoing ICMP echo requests but not many ICMP echo replies. The verdict is that this particular technique is both unreliable and unsuitable for rapid deployment. In fact, this isn't even in the same ballpark as 'practical'.
Our next idea was to try building a laser communication system utilizing the other circuit from Make Magazine. On paper it's pretty simple: an audio transformer takes sound from a source (in our case, the sound card of a laptop) and modulates the electricity powering a laser diode with it, which in turn is emitted as a beam of light. On the other end, an optical pickup (we had photoresistors and a small selection of solar cells for our experiments) would measure the minute variations in the beam of light and modulate the electric current passing through it. That electric current would then be interpreted as sound by a copy of soundmodem on the other end, and converted back into network traffic. First, we ran into problems with the cheap-ass laser pointers I'd bought from Micro Center. The evening I tested them a few weeks ago they worked. The night we tried to patch them into the audio transformer they refused to light up. Also, almost in passing, we discovered that the voltage coming out of a sound card is quite small - millivolts at most - so an amplifier would be required to boost the gain on the received signal to usable levels. I'd bought some LM741 op-amps on the off chance that we'd have to do something like that, but my knowledge of electronics isn't terribly great and I ran into trouble near the end of the second evening. I understand some of the theory but when it comes to applying it I fall quite short, but I took a stab at it and didn't make a whole lot of progress.
When I got in the next afternoon I took another stab at it and came up with what I thought was a workable circuit. Elliot happened by at that moment, and we discussed what I was doing; he suggested an alternative circuit that would do the same thing with parts available at HacDC. With a borrowed breadboard I patched the circuit together along with a photoresistor that would act as the pickup for the modulated laser beam. We had to spend a little time debugging the circuit because it wasn't immediately apparent where to connect a few things to (I still don't quite get dual power supplies), but a little skull sweat and judicious application of an oscilloscope helped us figure out exactly what was going on. Once it was up and running the photocell immediately picked up the 60 Hz flickering of the overhead fluorescent lighting which manifested as a rapid scratching sound. Unfortunately, some experimentation showed that everything we shined on it manifested as a rapid scratching sound, including data, sound, and music. The ultimate verdict is that Make Magazine's lasercomm circuits are pants. Don't bother with them.
Long story short, the experiments we carried out during development sprint number two were failures. All of the techniques we tried appear to be unworkable for connecting network nodes. There are probably ways to make them work but we didn't know of any at the time. Additionally, the ways to make these methods work proabably do not lend themselves to low cost and improvisation, two of the design goals of Byzantium. As near as we can tell our best options at the moment will probably involve long-distance wi-fi, probably with improvised cantennas or woks (no, really). There is a chance that we could make use of another signaling mode supported by soundmodem, like FSK or newqpsk, but that is better left for another experiment after we all do more research.
Oh, and make sure that you buy rosin core solder. If you don't, you'll go bonkers trying to figure out why stranded wire won't tin.