Search
  • Starchild

So, how packet data transmission has evolved?

Yeah, what a boring subject I hear you say. For some of us, it’s been a part of life for a very long time.


As a sixteen year old (in the 1970’s), I had just built my own computer. Well, it was an 8 bit microprocessor with a little bit of RAM, a text terminal running on an old black & white TV monitor, keyboard and a simple BIN-BUG (in EPROM) user interface providing an on-screen prompt with just a few commands like (W)rite, (R)ead, (S)ave to audio cassette. No compilers back then. Everything was hand coded machine code using hexadecimal bytes. (e.g. 3F 01 FF .. jump to subroutine at address 01FF). It’s very sad how even today I can still remember the machine code as if it was yesterday.


Anyway, as I was playing with HF amateur radio, I wanted to marry my interests together so I decided to build a simple audio to logic state converter (and vice versa) and connect it to my computer. I began writing a program to decode the received MORSE CODE (yes dots and dashes) from the radio and displaying the decoded characters and words on the text terminal. The most difficult part was to automatically determine if the dots and/or dashes were for a single letter or actually letters themselves. e.g. “e” = DIT, “t” = DAH but wait “a” = DIT DAH together. I invented a simple software bit rate cyclic timer that was tickled slightly by the received periods of DIT or DAH sounds, to give me a variable stable bit rate period to synchronize and decode the incoming text. This was an idea I got from my limited understanding of a phase-locked-loop oscillator used to generate stable but variable frequencies required inside a radio itself.



Yep it worked great. Tune in a new signal on the radio to the required audio frequency and after a few seconds of garbage characters the decoded Morse Code would be typed up onto the screen. I also interfaced an old TeleType (Telex) machine as my physical printer. I needed to control the 60v solenoid from the computer, just a couple of switching transistors, and then the fact that the Teletype machine used a 5 bit (Baudot code) to represent character set or number set. Now I can printout received Morse code onto paper in real time. Pretty cool! Well this 16 year old kid thought so.


Ok. Packet data transmission, I hear you ask. That came a few years later. After several years of using microprocessors to control and sense things in the real world, I wanted to expand on the idea of sending and receiving data over HF radio signals. I knew that I needed to overcome the problems relating to the transmission medium, being HF radio. My system needed to deal with noisy signals, slow and rapid signal fading (QSB), dynamic multi-path phase cancelation, audio frequency errors due to side band modulation (USB, LSB) technology of HF radios and the time-of-day propagation issues of transmitting a radio signal around the country/world. To facilitate this, my brother and I created a small PCB containing a dedicated microprocessor, some memory, audio in/out interface circuitry which along with two years of my life in the development of my own error corrected, frequency corrected, a packet radio data transmission system emerged for sending data over HF radio.


I also developed an early PC styled, menu item driven message creation, post office, transmission and receipting program. In fact it was pre-PC days, it really ran on a Z80 micro-processor board which supported CP/M (a bit like PC-DOS), a floppy disk drive, and my program written in CBASIC (similar to but a text only version of QBASIC).


You would choose one of the available (pre-drawn) pro-forma documents, fill in the fields, and save it to the post-office in the program. The post-office would schedule the transmission and delivery to the recipient (using a unique numerical address). If it was unsuccessful the program would reschedule the transmission until it could be delivered (or cancelled). The data fields would then be placed back into the same form style it was created with and displayed on the screen. It was very rare that a data transmission would ever arrive error free (first go) over HF radio, so my packet radio protocol involved packet level error detection, byte level error detection and employed a technique of mid packet byte substitution to reconstruct a good and valid packet at the destination radio, combined with acknowledgement replies and of course repeat transmissions of the individual packets that make up the full message.


Sounds overly complicated. Well that’s what made it work reliably in the real world conditions it was designed for. In fact I lodged a patent for my method of packet data transmission. After teaming up with several corporate people we formed a Public listed company on the Australian Stock Exchange to manufacture and promote this and several other products.


We than applied derivatives of this technique for VHF and UHF radios (FM modulated systems) using multi-tonal transmission techniques to shift multiple bits with a single change in bit tone.

We then imbedded this packet data technology into several products;


1. wires-over-radio logic input/output digital control equipment (used in iron ore ship-loaders),

2. weigh bridge interface for automated truck weighing and printout receipts in the driver’s cab,

3. multi-station CCTV to control a video transmission system over wide-area mine sites.


There have been many radio data systems developed by many people over the years. Some are modular add-ons to standard radios and some integrated into new radio products. Most are proprietary protocols. In the HF radio market the radio manufacturers have also developed their own SELCALL and PAGECALL messaging packet data systems. Even an OEM version exists to satisfy universal compatibility concerns.


Jumping forward we now have the over-utilization of the 2.4Ghz (unregulated) band for technologies like Bluetooth and WiFi. Haven’t these become popular, even as the preferred means of networking. The mobile (or cell) phone technology went to digital back in early 1990’s. This made voice over data an everyday affair.


A few years ago I discovered the NRF24L01 packet data transmission module. It’s is a self-contained data system operating in the unregulated 2.4Ghz band (with everything else). It interfaces to a microcontroller with a simple serial SPI buss and supports a comprehensive control register array making small volume error corrected data transmission with an individual and grouped identity for a closed network solution. Although they are cheap (about $10 each module) they have a maximum range of about 50 metres (line of sight). Even so, they are a quick, simple and reliable solution to small volume private data transmission.


These days, of course we now have the “Internet Of Things” (IoT). What does this really mean? Well for a few dollars you can control, read, host, client, AP, almost anything you can think of within a WiFi environment. You can buy modules from $5 like the ESP12, ESP8266, ESP32, NODEHOST, etc. which makes the IoT very accessible to everyone. If you do want to play with (IoT), you can go to www.B4X.com and download the free B4R IDE suite. It’s a BASIC language wrapper for the Arduino suite with lots of great support via the forum. I even wrote a B4R library (available from the B4X forum) for controlling a NRF24L01 module from an ESP8266 (IoT) module.


The Downside! As I mentioned earlier, IoT modules are limited to a transmission distance of approx. 50 metres. This is a common limitation due to the 2.4Ghz unregulated band they operate in and the governing maximum power restriction that applies to them. Don’t forget the clutter of the thousand different things all trying to operate in this band.


We tend to take most aspects of packet data transmission for granted these days. Other established technologies and protocols do a pretty good job of getting error free data from one place to another. What would we do without TCP/IP?


I feel, that with everything that has evolved, we should all still maintain an understanding of packet data transmission (error correction, retries, validation/check summing) for moving information from one location to another, and always be prepared for those unlikely (but theoretically possible) data loss or corruption events.


Who said it was going to be boring?

0 views
512x512.jpg

Contact Us

P.O. Box 1091, Wangara, 6065, Australia
Fax: +61 8 9405 2055
Email: info@takethis.com.au

Recent Posts

Grasstree Layout For Store.png

© 2017 Take This