Online Amateur Radio Community Wiki

User Tools

Site Tools

Trace: • history
packet:history

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
packet:history [2025/06/09 17:48] – g4klxpacket:history [2025/06/10 14:19] (current) – g4klx
Line 25: Line 25:
 There was already a single port digipeater at Alport Height (IO93FB) on 2m, and it was decided that we could make use of this site on multiple bands to provide trunking links and user access. I bought a number of NET/ROMs and over a short amount of time we had nodes on 4m, 2m, 70cms, and two links on 23cms. The latter was using about one Watt and one set to the north to Emley Moor with one polarisation, and the other was to the Birmingham area with the other polarisation. It worked well considering it was all operating with 1200 bps AX.25. We didn't link to our friends in Leicester since they always appeared to be in a constant state of disarray, lovely chaps though. There was already a single port digipeater at Alport Height (IO93FB) on 2m, and it was decided that we could make use of this site on multiple bands to provide trunking links and user access. I bought a number of NET/ROMs and over a short amount of time we had nodes on 4m, 2m, 70cms, and two links on 23cms. The latter was using about one Watt and one set to the north to Emley Moor with one polarisation, and the other was to the Birmingham area with the other polarisation. It worked well considering it was all operating with 1200 bps AX.25. We didn't link to our friends in Leicester since they always appeared to be in a constant state of disarray, lovely chaps though.
  
-Around this time the [[https://wiki.oarc.uk/_media/packet:uk_sysop_meeting_no_1_-_nov_1987.pdf|first sysop meeting]] was arranged. Many of us who had an interest in packet radio met at a hotel in Crick and spent the day talking about what we were doing and what we could do in the future, and how we should co-ordinate with each other. The RSGB attended in the person of G3XDV who explained that they were negotiating about new guidelines with the powers that be. It was all very exciting, and NET/ROM was discussed a lot.+Around this time the [[https://wiki.oarc.uk/_media/packet:uk_sysop_meeting_no_1_-_nov_1987.pdf|first sysop meeting]] was arranged. Many of us who had an interest in packet radio met at a hotel in Crick and spent the day talking about what we were doing and what we could do in the future, and how we should co-ordinate with each other. The RSGB attended in the person of Mike G3XDV who explained that they were negotiating about new guidelines with the powers that be. It was all very exciting, and NET/ROM was discussed a lot. A memory of that Sysops meeting was how exciting it all was, we were meeting for the first time, although we'd probably seen each others callsigns floating around on air. It was very bizarre to go to the toilets and have to fight through groups of people have conversations about packet radio to get to the urinal! Please don't read that last sentence the wrong way, the excitement at the meeting was palpable and very innocent.
  
 I had known John G8BPQ for a number of years. We both had an interest in V/U/SHF and we both lived in good RF locations, we would often work on 23cms SSB. I don't think we had met at this stage however. I had known John G8BPQ for a number of years. We both had an interest in V/U/SHF and we both lived in good RF locations, we would often work on 23cms SSB. I don't think we had met at this stage however.
Line 51: Line 51:
 ===== DANPAC and GB3RP/GB7RP ===== ===== DANPAC and GB3RP/GB7RP =====
  
-Every area had its own packet group. The Birmingham area had MAXPAK and a pretty good magazine to go with it. The Leicester area had LURPAC, and we had DANPAC, the Derbyshire and Nottinghamshire Packet Radio Group, or something similar.+Every area had its own packet group. The Birmingham area had MAXPAK and a pretty good magazine to go with it. The Leicester area had LURPAC, and we had DANPAC, the Derbyshire and Nottinghamshire Packet Radio Group, or something similar. Compared to the horrible politics that seeped into other groups, ours was almost entirely sweetness and light.
  
-Compared to the horrible politics that seeped into other groups, ours was almost entirely sweetness and light. We became responsible for GB3RP/GB7RP and later some other nodes and GB7xxx BBS systems. By now, the powers that be had worked out the rules of packet radio and it all became a little less like the wild west. When I ran my BBS, G4KLX, it ran with 100W into a 16 element yagi on 2m, an ERP of around 4 kW. It never ran as a GB7, even though I did eventually get GB7KLX allocated after I'd closed it down.+By now, the powers that be had worked out the rules of packet radio and it all became a little less like the wild west. When I ran my BBS, G4KLX, it ran with 100W into a 16 element yagi on 2m, an ERP of around 4 kW. It never ran as a GB7, even though I did eventually get GB7KLX allocated after I'd closed it down.
  
-The groups would have a meeting every few months, and had a nicely produced magazine. Richard G4NAD was one of the main movers and shakers in the group.+The group would have a meeting every few months, and had a nicely produced magazine. Richard G4NAD was one of the main movers and shakers in the group.
  
-Luckily we had G8BPQ as one of our members, and early one we were to run a version of his code on the Kantronics Data Engine. This was a dual port TNC, with each modem on a plugin board so you could choose the modes, it had a fast 80188 CPU and a decent amount of RAM. It was a TNC on steroids. It came with a single 1200 bps AFSK modem as standard, and you could have a 9600 bps RUH modem board. The one at GB3RP/GB7RP had two 1200 bps AFSK modems.+We became responsible for GB3RP/GB7RP (RP=Raynet Packet) and later some other nodes and GB7xxx BBS systems. RP started as a single band (2m) digipeater which was clearly inadequate for how things were developing, we added extra bands/ports and NET/ROM using authentic NET/ROMs. Luckily we had G8BPQ as one of our members, and early on we were to run a version of his code on the Kantronics Data Engine. This was a dual port TNC, with each modem on a plugin board so you could choose the modes, it had a fast 80188 CPU and a decent amount of RAM. It was a TNC on steroids. It came with a single 1200 bps AFSK modem as standard, and you could have a 9600 bps RUH modem board. The one at RP had two 1200 bps AFSK modems.
  
 However RP needed three extra ports. We had the Tiny-2s from the NET/ROM days, and so we used G8BPQ multidrop KISS. The idea behind it was simple, hang all of the extra TNCs from one serial port on the host device, and give each TNC an Id and use that to address them explicitly. Each TNC could only talk to the host when asked to do so by the host. In addition each packet passed over the serial link was protected by a checksum. Finally it also included ACKMODE where each TNC reported back to the host when a particular packet had been transmitted, so that the AX.25 protocol timers could be set correctly. However RP needed three extra ports. We had the Tiny-2s from the NET/ROM days, and so we used G8BPQ multidrop KISS. The idea behind it was simple, hang all of the extra TNCs from one serial port on the host device, and give each TNC an Id and use that to address them explicitly. Each TNC could only talk to the host when asked to do so by the host. In addition each packet passed over the serial link was protected by a checksum. Finally it also included ACKMODE where each TNC reported back to the host when a particular packet had been transmitted, so that the AX.25 protocol timers could be set correctly.
Line 65: Line 65:
 Although the location of RP was sensationally good, it did suffer from some pretty obvious drawbacks. The 2m packet frequency had 100% utilisation, and was almost completely useless, even the 70cms channel was pretty well full also. The 2m node did get to transmit from time-to-time, due to interference. In the same hut and mast as RP was a high power paging transmitter on 156 MHz (I think), and when it transmitted, 2m went very quiet! So RP would get its long line of packets out. Although the location of RP was sensationally good, it did suffer from some pretty obvious drawbacks. The 2m packet frequency had 100% utilisation, and was almost completely useless, even the 70cms channel was pretty well full also. The 2m node did get to transmit from time-to-time, due to interference. In the same hut and mast as RP was a high power paging transmitter on 156 MHz (I think), and when it transmitted, 2m went very quiet! So RP would get its long line of packets out.
  
-The other problem was the weather. Alport Height is a very exposed location, in the summer it can be glorious, but in the winter it used to suffer from some extremely serious snow drifts and horizonal wind and rain. Luckily most of my visits were done in pretty good weather, but I did feel for the people who maintained the equipment in the other buildings and masts, they had to be there. I remember going up there after a particularly intense storm, RP had gone off, and I went up fearing the worst. I opened the hut and saw no obvious damage to our equipment, I restarted our equipment and it all came to life as if nothing had happened, I was relieved. A moment afterwards a guy turned up at the door with a short white stick in his hand. He was maintaining equipment in another hut and he'd come to see if he could help, and be nosey. He explained that the short white stick was originally a long colinear that had borne the brunt of the lightning. I followed him to his hut, which I saw was bigger, cleaner, and emptier than ours, it also had a horrible burnt electronics smell and dome smoke! Basically all of his equipment was fried. Other engineers turned up, so I made my getaway, since I was probably late for dinner or something.+The other problem was the weather. Alport Height is a very exposed location, in the summer it can be glorious, but in the winter it used to suffer from some extremely serious snow drifts and horizonal wind and rain. Luckily most of my visits were done in pretty good weather, but I did feel for the people who maintained the equipment in the other buildings and masts, they had to be there. I remember going up there after a particularly intense storm, RP had gone off, and I went up fearing the worst. I opened the hut and saw no obvious damage to our equipment, I restarted our equipment and it all came to life as if nothing had happened, I was relieved. A moment afterwards a guy turned up at the door with a short white stick in his hand. He was maintaining equipment in another hut and he'd come to see if he could help, and be nosey. He explained that the short white stick was originally a long colinear that had borne the brunt of the lightning. I followed him to his hut, which I saw was bigger, cleaner, and emptier than ours, it also had a horrible burnt electronics smell and a lot of smoke! Basically all of his equipment was fried. Other engineers turned up, so I made my getaway, since I was probably late for dinner or something. 
 + 
 +You'll find no mention of TheNet in this section. This seemingly came out of nowhere in (I think) later 1988 and was a complete functional clone of NET/ROM but was open source and had no encryption or callsign locking like the original. It didn't take too long for Software 2000 to take legal proceedings against the people behind TheNet. An independent software source code analyst verified that TheNet appeared to be an almost perfect copy of the Software 2000 code, but with the arguments to the functions reversed compared to the original. Ultimately the court ruled against the creators of TheNet, but the damage was done, and sales of true NET/ROMs fell through the floor. DANPAC had very little to do with TheNet, not for legal reasons, but because BPQCode was considerably more powerful and flexible. Later versions of TheNet also included IP over AX.25 routing which made it unique, but that wasn't enough of a selling point for us to use it.
  
 I believe RP closed down sometime in the late 1990s, although by then I was doing other things and was no longer responsible for it. I believe RP closed down sometime in the late 1990s, although by then I was doing other things and was no longer responsible for it.
  
-===== KA9Q Net/NOS =====+===== KA9Q NET/NOS =====
  
 In the TAPR DCC proceedings were articles by Phil Karn KA9Q about his developments. He wrote an MS-DOS program that offered a terminal with a great many commands that implemented, AX.25, TCP, and UDP all over a KISS TNC. It was, and is, a lovely piece of software, and even included a mailer for SMTP data transfers! I think it expanded to include NET/ROM but I could be wrong about this. One thing that was great about this software was that it was open source which was still pretty rare at the time. I got my first version of it (dated 871225.33n) from Keith G4LZV of the Kent packet group. I was in London on business for a few weeks in early 1988 and I offered to buy him dinner if he could give me a copy of the KA9Q software. Luckily he knew of an excellent Chinese restaurant in Bayswater that we could eat at. We talked nothing but packet that evening. In the TAPR DCC proceedings were articles by Phil Karn KA9Q about his developments. He wrote an MS-DOS program that offered a terminal with a great many commands that implemented, AX.25, TCP, and UDP all over a KISS TNC. It was, and is, a lovely piece of software, and even included a mailer for SMTP data transfers! I think it expanded to include NET/ROM but I could be wrong about this. One thing that was great about this software was that it was open source which was still pretty rare at the time. I got my first version of it (dated 871225.33n) from Keith G4LZV of the Kent packet group. I was in London on business for a few weeks in early 1988 and I offered to buy him dinner if he could give me a copy of the KA9Q software. Luckily he knew of an excellent Chinese restaurant in Bayswater that we could eat at. We talked nothing but packet that evening.
Line 81: Line 83:
 One of my diversions was acquiring an Acorn Archimedes in the late 1980s. This was a marvelous machine, using an early iteration of the ARM processor, and for its time was a very powerful computer. Mine had 4MB of RAM, and although a little quirky, the operating system was pretty impressive. The OS used cooperate multitasking and required each program to voluntarily give up access to the CPU regularly. People were already using KA9Q NET/NOS under emulation on the Archimedes but the experience wasn't very pleasant. I decided to port KA9Q NET to the architecture. One of my diversions was acquiring an Acorn Archimedes in the late 1980s. This was a marvelous machine, using an early iteration of the ARM processor, and for its time was a very powerful computer. Mine had 4MB of RAM, and although a little quirky, the operating system was pretty impressive. The OS used cooperate multitasking and required each program to voluntarily give up access to the CPU regularly. People were already using KA9Q NET/NOS under emulation on the Archimedes but the experience wasn't very pleasant. I decided to port KA9Q NET to the architecture.
  
-I chose the NET version because the central commutator loop lent itself to giving up the CPU after each iteration to allow the whole machine to multitask. I did add the ability to have a separate window for each session, AX.25, TELNET, etc. I ported the software in about one day. I was very pleased with the results and so were a number of other people since it ran much quicker and was also a good neighbour on the computer. I maintained that software for a few years before getting into Linux.+I chose the NET version because the central commutator loop lent itself to giving up the CPU after each iteration to allow the whole machine to multitask. I did add the ability to have a separate window for each session, AX.25, FTP, TELNET, etc. I ported the software in about one day. I was very pleased with the results and so were a number of other people since it ran much quicker and was also a good neighbour on the computer. I maintained that software for a few years before getting into Linux.
  
 I can now say that I know Phil very well, and have met him a number of times. He's moved on from packet radio, and I recommend his KA9Q Radio project if you want to try something exciting. I can now say that I know Phil very well, and have met him a number of times. He's moved on from packet radio, and I recommend his KA9Q Radio project if you want to try something exciting.
  
-===== Sysop 2 and 9600 bps FSK =====+===== Sysop 3 and 9600 bps FSK =====
  
-I have already mentioned Sysop 1 earlier, in early 1988, sysop 2 was held in Bradford, I was the first John went to, and I travelled with him in his camper van. BPQCode was still not massively known, but was taking off (remember this was pre Internet so software distribution was more challenging) and many still hadn't heard of it.+I have already mentioned Sysop 1 earlier, in early 1988, sysop 3 was held in Bradford (I missed Sysop 2 I think), I think it was the first John went to, and I travelled with him in his camper van. BPQCode was still not massively known, but was taking off (remember this was pre Internet so software distribution was more challenging) and many still hadn't heard of it.
  
 I remember two things from this meetings. The first was a talk by a visiting ham from California who described packet radio there. It was a fascinating talk and in turns scary and hilarious. The way he described after midnight on 2m in his area as "weirdo prime time" was memorable. Unfortunately I don't remember much about him, but it made the meeting more interesting than it could otherwise have been. I remember two things from this meetings. The first was a talk by a visiting ham from California who described packet radio there. It was a fascinating talk and in turns scary and hilarious. The way he described after midnight on 2m in his area as "weirdo prime time" was memorable. Unfortunately I don't remember much about him, but it made the meeting more interesting than it could otherwise have been.
  
-Also at the meeting, G3RUH gave a demonstration of his 9600 bps modems, and we were mightily impressed, although no RF was involved. Both John and I got RUH beta boards (only difference was a missing pull-up or pull-down resistor on the DCD line). They were Eurocard sized and interfaced to standard TNC-2 modem breakout pins.+Also at the meeting, G3RUH gave a demonstration of his newly developed 9600 bps modems, and we were all mightily impressed, although no RF was involved. Both John and I got RUH modem beta boards (the only difference was a missing pull-up or pull-down resistor on the DCD line). They were Eurocard sized and interfaced to standard TNC-2 modem breakout pins.
  
-As impressive as the modem was, the problem we had was the lack of suitable radios to use with them. Tapping into the discriminator for receive was relatively simple, but not all radios used true frequency modulation on transmit, many used phase modulation. For FM use this difference was unimportant, but for high speed packet, it was fatal. This is one of the reasons why we didn't get 9600 bps links running at GB3RP/GB7RP, we wanted to, but no-one seemed to have the skill to design or market a suitable radio.+As impressive as the modem was, the problem we had was the lack of suitable radios to use with them. Tapping into the discriminator for receive was relatively simple, but not all radios used true frequency modulation on transmit, many used phase modulation. For FM use this difference was unimportant, but for high speed packet, it was fatal. This is one of the reasons why we didn't get 9600 bps links running at RP, we wanted to, but no-one seemed to have the skill to design or market a suitable radio.
  
 Kantronics came out with a special 9600 bps capable radio in the early 1990s, but they were very expensive. By all accounts they were very good, but I never got to use one. Kantronics came out with a special 9600 bps capable radio in the early 1990s, but they were very expensive. By all accounts they were very good, but I never got to use one.
Line 101: Line 103:
 ===== Linux Kernel AX.25 ===== ===== Linux Kernel AX.25 =====
  
-At one of the later sysops meetings in 1995, held somewhere near Birmingham I think, I approached Alan GW4PTS about taking over the Linux kernel AX.25 code from him. At this time Alan was responsible for the whole Linux kernel networking, and the AX.25 was somewhat lacking in features, I think it was only AX.25 v1 which was already old by then. He readily agreed. One advantage I had over earlier was that I was now Internet connected which helped massively with communications with interested people.+At one of the later sysops meetings in 1995, held somewhere near Birmingham I think, I approached Alan GW4PTS about taking over the Linux kernel AX.25 code from him. At this time Alan was responsible for the whole Linux kernel networking, and the AX.25 was somewhat lacking in features, I think it was only AX.25 v1 which was already old by then. He readily agreed. One advantage I had over earlier times was that I was now Internet connected which helped massively with communications with interested people.
  
 Using the SDL diagrams in the TAPR DCC, I implemented AX.25. This is when I found that the SDL diagrams were not complete, however I had the narrative description of the protocol, so I was able to finish it based on that. I think I probably found a mistake in the published SDL diagrams at the same time. I was able to ask Alan to include my code which he did with almost no comments. I then went onto adding further protocols. Using the SDL diagrams in the TAPR DCC, I implemented AX.25. This is when I found that the SDL diagrams were not complete, however I had the narrative description of the protocol, so I was able to finish it based on that. I think I probably found a mistake in the published SDL diagrams at the same time. I was able to ask Alan to include my code which he did with almost no comments. I then went onto adding further protocols.
Line 121: Line 123:
 ===== Afterword ===== ===== Afterword =====
  
-So I think that's my complete journey in packet radio. What people reading this don't realise is how much of the wild west this all was. We genuinely felt that we were doing something new, the Internet was only a rumour for most people, and for the rest of us, NET/ROM seemed like magic. It was the first time we'd seen networking operating and we could get our hands dirty doing so. It was helped, or hindered, by the activity levels of the time which were huge, finding a free channel on 2m FM was very difficult at that time, and that also applied to packet, everyone had a TNC or a Baycom modem.+So I think that's my complete journey in packet radio. What people reading this don't realise is how much of the wild west this all was. We genuinely felt that we were doing something new, the Internet was only a rumour for most people, and for the rest of us, NET/ROM seemed like magic. It was the first time we'd seen a network operating and we could get our hands dirty doing so. It was helped, or hindered, by the activity levels of the time which were huge, finding a free channel on 2m FM was very difficult at that time, and that also applied to packet, everyone seemed to have a TNC or a Baycom modem.
  
 I have not really come back to packet radio, I do have two Nino TNCs which are everything we wish we had in the 1980s and 1990s, as well as 9600 bps capable radios. I have introduced the idea of using C4FSK to the high speed packet world, to get 19200 bps into a 25 kHz channel whereas previously we stopped at 9600 bps from the G3RUH modem technology. I have not really come back to packet radio, I do have two Nino TNCs which are everything we wish we had in the 1980s and 1990s, as well as 9600 bps capable radios. I have introduced the idea of using C4FSK to the high speed packet world, to get 19200 bps into a 25 kHz channel whereas previously we stopped at 9600 bps from the G3RUH modem technology.
  
-Things like IL2P show the way forwards by simplifying the packet header and adding strong FEC to the header and payload. This is all stuff we could imagine back in the glory days of packet, but we didn't have the CPU power nor suitable RF hardware. We would have loved to have had Raspberry Pis then, but of course they would have counted as supercomputers in that era. So don't criticise us for what we achieved, but we didn't have the hardware, we were ahead of the curve and would have to wait a long time for the manufacturers and computers to catch up. It was a kit if fun though, probably more than you can imagine.+Things like IL2P show the way forwards by simplifying the packet header and adding strong FEC to the header and payload. This is all stuff we could imagine back in the glory days of packet, but we didn't have the CPU power nor suitable RF hardware to even attempt. We would have loved to have had Raspberry Pis then, but of course they would have counted as supercomputers in that era. So don't criticise us for what we achieved, but we didn't have the hardware, we were ahead of the curve and would have to wait a long time for the manufacturers and computers to catch up. It was a lot of fun though, probably more than you can imagine.
  
-I have left out some parts, I have not always named names, and most of the controversies have been glossed over. Packet became very political at times, although DANPAC always managed to stay out of it. On a couple of occasions we threatened to block certain BBSs traffic coming over our part of the network if they didn't sort out their differences, and our representations were accepted as we usually stayed neutral in most arguments. It's interesting that some of the same issues are to be seen in the DMR world, and for pretty much the same reasons. This is one of the reasons why I tried to make most of my digital voice networking to be decentralised so that no one group has power over another. You'll find no mention of G1NNA and G1NNB here!+I have left out some parts, I have not always named names, and most of the controversies have been glossed over. Packet became very political at times, although DANPAC always managed to stay out of it. On a couple of occasions we threatened to block certain BBSs traffic coming over our part of the network if they didn't sort out their differences, and our representations were accepted as we usually stayed neutral in most arguments. It's interesting that some of the same issues are to be seen in the DMR world, and for pretty much the same reasons. This is one of the reasons why I tried to make most of my digital voice networking be decentralised so that no one group has power over another. You'll find no mention of G1NNA and G1NNB here!
  
packet/history.1749491295.txt.gz · Last modified: by g4klx