This is a proposal by Phil Cadman G4JCP for a new Packet Radio system.
Phil can’t be here today, so I have collected his ideas together into a presentation, which I will give on his behalf.
Everything here is at the ideas stage. There's no software written, and there's no hardware available although a development board is in preparation. The protocols discussed are based on Phil’s ideas as to how data could be passed efficiently over radio links so as to support both new and existing packet applications.
I must say that Phil has rather pre-empted me on this one, as I’ve been working towards a similar system for the last 3 years. So whilst we agree on many points, we may differ on others, but I will try to answer any questions from Phil’s point of view if I can.
ARMAPS stands for Amateur Radio Messaging and Paging System. It has nothing to do with MAPS!
It is a new packet data communication system suggested by G4JCP to encourage further experimentation in amateur data communications, and to assist in the development of new amateur radio applications which involve data transmission.
ARMAPS is designed to complement, rather than compete with, existing AX25-based packet systems.
In the March 2004 issue of Practical Wireless, G3LDI was bemoaning the fact that the Internet was killing Packet and users were becoming fewer. Whilst the Internet had revolutionised personal data communications, packet development had hardly progressed at all. Those comments inspired Phil to think about something new.
Phil’s original idea was to use a cheap TNC and PIC to look for his callsign in the "Mail For" beacons from a BBS. But there are no cheap stand-alone TNC’s, so he thought maybe he’d build his own.
He initially thought about building a TNC2 clone, but the TNC2 circuit is old and messy. And he'd still have to add another micro to look for his callsign in the BBS beacon transmissions. The obvious solution was to design and build his own hardware and write his own UI-frame packet 'sniffer'. In other words, make a TNC which performed a specific function, rather than have it behave simply as a TNC. This started him thinking about the kind of packet applications which would benefit from such an approach.
Most people use packet for accessing BBSs, APRS, the DX Cluster and other things, but seldom for one-to-one QSOs. The trend is for passing messages, not having QSOs. The AX25 protocol can handle unconnected message packets, but UI frames are not acknowledged, so you don't know whether they've got through or not. It doesn't matter with APRS, as packets are re-transmitted at regular intervals. But a single message needs an acknowledgement.
At this point Phil got hold of a copy of the AX25 protocol specification, and realised how complex and inflexible it was. Maybe the lack of packet progress was partly due to the AX25 protocol itself?
By now he'd begun to realise that he should forget AX25 and existing TNC hardware, and start with a clean sheet of paper. From that point the possibilities kept on growing. We need not just one protocol but a whole suite of related protocols, each protocol optimised for a specific task or radio channel. Similarly for the hardware; make the protocols available for several micro-controller, modem and memory configurations, so the hardware too can be designed and optimised for a given application.
Phil’s personal circumstances don't allow him time to build any of this stuff, or write the software. The ARMAPS Project needs help, lots of it. And that's where you come in....
The underlying philosophy behind the project is that the system should be simple yet expandable. Both the hardware and software should be as simple as possible, so long as the efficiency of the system is not impaired, nor its potential for expansion compromised.
Unlike APRS for example, the system should not be owned or controlled by any one person or group; it should be completely open for anyone to develop.
ARMAPS introduces messaging and paging to amateur packet radio. Basically, both messaging and paging use numbered but unconnected packets.
Messaging employs packets which are directed to a single recipient who acknowledges each packet.
Paging uses packets which are not acknowledged and so may be directed to any number of possible recipients.
ARMAPS will use new protocols which will be specifically designed for data transmission over radio links.
The bane of packet life is collisions, or rather, how to avoid them. The way to stop collisions becoming a problem is not to have them in the first place. Or at least try to make them very unlikely. The ARMAPS protocol should avoid collisions by two methods: Firstly. by not having a 'free for all‘, and secondly, where a free for all is unavoidable, having very low channel occupancy, say less than 10%
In many cases, ARMAPS will be used in an application which has some kind of central control. It makes sense, therefore, for one ARMAPS station to actively control the flow of packets on a channel. This is somewhat like a voice net where a net controller decides who can speak at any one time. Of course, there has to be some mechanism whereby new stations can join in, and stations already in the net can leave without the net controller being left wondering where they've gone.
In a voice net, everyone can usually hear everyone else, which is not generally the case with packet. Perhaps we need to look at the voice procedure used by the emergency services. That is, a full-duplex base station which indicates to other mobiles when a mobile is transmitting (the pip-pip-pip sound).
Whatever method we ultimately adopt, packet stations should only transmit either when actively instructed to do so, or else when their transmit frequency is indicated as not in use (no pips!). Packet should use half duplex operation far more than it does now, with the controlling station running full duplex.
Where no controlling station is present, or simply inappropriate, channel occupancy needs to be kept very low to reduce the probability of collisions to an acceptable figure. If this sounds like gross under-utilisation of a channel, go monitor a busy packet frequency and count the number of trashed packets.
Paging packets can be sent from one to seven times. Packets are transmitted in the sequence they are received from the application, and each packet is only transmitted when the previous packet has been transmitted the designated number of times. We should look at adding FEC to paging packets to make them more resilient. Paging packets should normally have relatively few data bytes to minimise packet loss. Short packets may also be essential where PIC micros are used in paging applications as they don't have a lot of RAM! As paging receivers may well have battery savers, paging transmitters should always transmit two seconds of unmodulated carrier before transmitting data.
Although paging packets are not explicitly acknowledged by the system software, they can be acknowledged by the applications programs that use them.
Paging packets can be used for any purpose and they can be fast, because with no waiting for acknowledgements, they can (potentially) be sent one after another with no gaps.
Phil writes: "Of course, paging packets need good links if packets are not to be lost. But that's up to us: we shouldn't use packet over grotty links. We should aim at 0.99 probability of any packet getting through. And that's end-to-end, not just over a single hop. We need to get this into our heads: we need not be concerned about lost packets because we shouldn't be losing them in the first place". (pzt - I’m not sure I agree with this, because you just have to accept whatever link you can get when you’re out portable)
Messaging packets may also be sent from one to seven times. And again, there can be only one packet outstanding at any time. That's like setting MAXFRAMES = 1. If an acknowledgement isn't received within a pre-set time, the packet is sent again. There should be no need for Receive-Ready packets as in AX25. The loss of a packet should be very much the exception, and RR packets just waste time (and channel capacity).
Full-duplex point-to-point links may have more than one packet outstanding, perhaps two or three, as one packet can be transmitted while an acknowledgement for the previous packet is being received. Not waiting for the corresponding acknowledgement means that there need be no gaps between transmitted packets. Transmitters on full-duplex links should not cut carrier between packets. They should only cut carrier when there's been no packet traffic for 30 seconds or more.
We should always try to minimise the time taken to get an acknowledgement back for a transmitted packet. Acknowledgements must be given priority. End-to-end round-trip times must be minimised.
| Width in bytes | Description |
| 1 (or more) | Flag = 01111110 |
| 1 | Packet type |
| 3 to 12 | Destination callsign |
| 1 | SSID etc. |
| 3 to 12 | Source callsign |
| 1 | SSID etc. |
| 1 to 12 | Network entry address (optional) |
| 1 | SSID/Control/etc.(required only when address above is present) |
| 1 to 12 | Network exit address (optional) |
| 1 | SSID/Control/etc.(required only when address above is present) |
| 2 to 4 | Control bytes |
| 0 to 256 | Data |
| 2 | Frame Check Sequence |
| 1 (or more) | Flag = 01111110 |
ARMAPS packets will be delimited by the usual HDLC flags and will use bit stuffing and NRZI coding. as in AX25. The first byte after the opening flag will be a packet type identifier. Chips like the 85C30 can be instructed to look for a specific address or group of addresses and only respond to packets with those addresses. The first address byte of an AX25 packet always has the LSB clear, so if we always set the LSB in the ARMAPS packet type byte, then ARMAPS TNCs can distinguish between the two protocols. Hence we can have a TNC that can handle both AX25 and ARMAPS packets. (I don’t know what a conventional TNC would do with this).
All ARMAPS paging packets will have the top bit set. And paging packets which begin binary 1111xxxx, will be reserved for internal system use. Paging packets with a type code of 0x80 to 0xEF are user definable. If the top bit of the packet type byte is clear - 0x00 to 0x7F - then it defines a messaging packet. All codes are user definable.
To allow for very long callsigns, such as those used when you operate abroad, the source and destination address fields are variable length, up to twelve characters long. Characters are 7 bit plain ascii, and the 8th bit is zero. For paging use, the destination callsign can be any word, and paging receivers can be instructed to only respond to that word. This allows paging users to share a channel.
The SSID is a hexadecimal character 0 to 9, and A to F, The MSB is set so as to identify the end of the callsign. The other three bits are unused at present. (Either I’ve misunderstood Phil here or he’s made a mistake, because if these characters are ascii there aren’t any unused bits. I presume he proposes an SSID byte similar to the AX25 one.)
The network entry and exit addresses could be used for digipeating, or they could be the node callsigns of the entry and exit points to a network. If we use the Internet as a means of routing packets around the country, these fields could contain dotted quad IP addresses without the dots. The exit address could be specified by the originator for manual routing, or inserted later by the network software.
The control bytes are not yet finalised. They might hold things like packet numbers, and distinguish data packets from acknowledgement packets.
The data field can be zero up to 256 bytes. This will usually be 7-bit ASCII, delimited by ASCII control characters, but some packets will need to carry pure binary so the packet’s control bytes will identify binary packets and give the length of the binary payload. Finally, The frame check sequence, will use the usual AX25 CRC, over all the bytes between the opening and closing flags.
The messaging hardware will be based on industry-standard 8032 micro-controller devices. An Am85C30 will handle much of the packet formatting, generation and checking. The amount and type of memory required will be flexible so as to accommodate both simple and more complex applications. Similarly, the support hardware may be extended far beyond the minimum requirement necessary to implement the basic protocols.
Whilst the messaging hardware will be more than capable of implementing the paging protocols, in most paging applications much simpler hardware will be more appropriate on cost, size and power requirement grounds.
The Microchip PIC family of micro-controllers, already widely used by amateur radio and electronics enthusiasts, are ideal candidates.
Phil suggests it’s probably best to stick to 1200 or 2400 bauds, making it easy to interface any rig or handheld with minimal effort. For 1200 bauds, the FX614 modem chip is suggested, and for 1200/2400bd, the FX469. I have a few samples of each, with documentation, to give to anyone who is serious about developing some hardware for the project. Phil has bought these from his own pocket, so I don’t want them to sit unused on someone’s shelf. See me afterwards if you are interested.
Software for this project will be 'free software', licensed under the GNU General Public Licence. Once the basic protocols have been implemented in software and released under the GNU GPL, individual amateurs can easily add their own specific software modules to provide whatever additional functions they require.
The Small Devices C Compiler, SDCC is primarily aimed at the 8032 and related processors. It's free, being released under the GNU GPL, it runs under both Win32 and Linux, and a shiny new version has just been released. It's a proper C compiler which comes with an associated assembler and linker.
The website at http://www.armaps.org/ contains everything in this presentation, and will be updated frequently as the project progresses.
Phil can be reached by packet: G4JCP @ GB7PZT.#24.GBR.EU
For those of you who’d like a hard copy, I have a limited number of handouts which give you all the information off the website.
Finally, there is a mention of ARMAPS in this month’s Practical Wireless.