packet:history
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
packet:history [2025/06/09 16:44] – g4klx | packet:history [2025/06/10 14:19] (current) – g4klx | ||
---|---|---|---|
Line 3: | Line 3: | ||
===== The Beginnings of Packet Radio in the UK by Jonathan G4KLX ===== | ===== The Beginnings of Packet Radio in the UK by Jonathan G4KLX ===== | ||
- | This document is based on my memories of the time. I do not keep a diary so some of the dates may be a little off, although some of them stay with me and I can date them based on other events occurring at the same time. Although this document is split into sections, and will be read linearly, the realty | + | This document is based on my memories of the time. I do not keep a diary so some of the dates may be a little off, although some of them stay with me and I can date them based on other events occurring at the same time. Although this document is split into sections, and will be read linearly, the reality |
Technically the first packet radio in the UK was in the mid-1980s following on from an article in RadCom about a simple packet system called BBC Packet, using a BBC Micro. It was a remarkable program which included a simple terminal, and allowed simple point-to-point connections and chats. For a brief time this mode was quite busy, but was ultimately a technical dead end. However a number of us found it an interesting idea, and a latent interest in packet radio was created. | Technically the first packet radio in the UK was in the mid-1980s following on from an article in RadCom about a simple packet system called BBC Packet, using a BBC Micro. It was a remarkable program which included a simple terminal, and allowed simple point-to-point connections and chats. For a brief time this mode was quite busy, but was ultimately a technical dead end. However a number of us found it an interesting idea, and a latent interest in packet radio was created. | ||
- | I got my first TNC in late 1987, a Pac-Com TNC-220 which was a non compatible evolution of the classic TNC-2. In the UK Packet Radio was in a grey zone since it involved passing third party traffic (even when digipeating) and that was outside the scope of the licence at the time. Despite this dubious legality it was known that the RSGB and the DTI/RA or whatever they were called that year were looking into it, and we should continue playing with packet and don't do anything too silly until they worked out new rules, this would take a number of years. At the time it was still possible to just about do multi-hop digipeating with reasonable success, but the packet channel was starting to get extremely busy. | + | I got my first TNC in late 1987, a Pac-Com TNC-220 which was a non compatible evolution of the classic TNC-2. In the UK, Packet Radio was in a grey zone since it involved passing third party traffic (even when digipeating) and that was outside the scope of the licence at the time. Despite this dubious legality it was known that the RSGB and the DTI/RA or whatever they were called that year were looking into it, and we should continue playing with packet and just don't do anything too silly until they worked out the new rules, this would take a number of years. At the time it was still possible to just about do multi-hop digipeating with reasonable success, but the packet channel was starting to get extremely busy. |
- | At the time you could buy Proceedings of the Tucson Amateur Packet Radio Digital Communications Conference (TAPR DCC) which was held in various US cities in the Autumn and contained many interesting papers. There was plenty of hot air in them, from people who had outrageous ideas and no actual implementation | + | At the time you could buy Proceedings of the Tucson Amateur Packet Radio Digital Communications Conference (TAPR DCC) which was held in various US cities in the Autumn and contained many interesting papers. There was plenty of hot air in them, from people who had outrageous ideas and no actual implementation |
One such contributor was Phil Karn KA9Q, who in one publication described the KISS TNC and protocol and that suitable ROM images for the TNC-2 existed. He also described his own development work of a PC program that appeared to do almost everything. | One such contributor was Phil Karn KA9Q, who in one publication described the KISS TNC and protocol and that suitable ROM images for the TNC-2 existed. He also described his own development work of a PC program that appeared to do almost everything. | ||
Line 15: | Line 15: | ||
As an aside I went to the 30th TAPR conference in Tucson in 2006, and it was great fun. | As an aside I went to the 30th TAPR conference in Tucson in 2006, and it was great fun. | ||
- | Sometime around this time, the Tiny-2 was released which was a TNC-2 clone but using more modern components, for example a TCM-3105 modem instead of an AM-7910 which saved a lot of space. The original TNC-2 was a huge PCB while the Tiny-2 fitted in the hand, it has a number of advantages: you could actually buy them, and they weren' | + | Sometime around this time, the Tiny-2 was released which was a TNC-2 clone but using more modern components, for example a TCM-3105 modem instead of an AM-7910 which saved a lot of space. The original TNC-2 was a huge PCB while the Tiny-2 fitted in the hand, it has a number of advantages: you could actually buy them, and they weren' |
- | Being a technical sort, I wanted to know how it all worked, and what could be done to move things forward. Having a TNC in KISS mode offered access to the raw underlying packet data in a way that allowed for experimentation. Even then we knew that the KISS protocol was a little too simplistic as it didn't allow access to the timing of when a packet was transmitted which affected the timers within AX.25. | + | Being the technical sort, I wanted to know how it all worked, and what could be done to move things forward. Having a TNC in KISS mode offered access to the raw underlying packet data in a way that allowed for experimentation. Even then we knew that the KISS protocol was a little too simplistic as it didn't allow access to the timing of when a packet was transmitted which affected the timers within AX.25, however it was all that we had. |
===== Enter NET/ROM ===== | ===== Enter NET/ROM ===== | ||
- | In early 1988 we were becoming aware of a new packet system named NET/ROM that was appearing within audible range of my excellent RF location in Derbyshire. NET/ROM was a replacement ROM for a TNC-2 close which offered a simple networking and transport layer (layers 3 and 4 of the ISO model) on top of connected mode AX.25. Not bad running on a TNC with a 1 MHz Z80 and 32K of RAM and ROM. You had to buy a separate NET/ROM for each band and link them via their serial ports. The callsign of the node was burned into the ROM at manufacturing time but you could change other parameters including the sysop password, the node alias, and other items. Each ROM cost around £40 in 1988 money and had to be ordered from California from Software 2000. The arrival of the Tiny-2 was fortuitous. | + | In early 1988 we were becoming aware of a new packet system named NET/ROM that was appearing within audible range of my excellent RF location in Derbyshire. NET/ROM was a replacement ROM for a TNC-2 clone which offered a simple networking and transport layer (layers 3 and 4 of the ISO model) on top of connected mode AX.25. Not bad running on a TNC with a 1 MHz Z80 and 32K of RAM and ROM. You had to buy a separate NET/ROM for each band and link them via their serial ports. The callsign of the node was burned into the ROM at manufacturing time but you could change other parameters including the sysop password, the node alias, and other items. Each ROM cost around £40 in 1988 money and had to be ordered from California from Software 2000. The arrival of the Tiny-2 was fortuitous. |
- | 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 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, | + | 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 |
- | Around this time the [[https:// | + | Around this time the [[https:// |
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 35: | Line 35: | ||
His software was written in 8088 assembler as a Terminate and Stay Resident (TSR) program on MS-DOS, TSRs would sit in the background, would typically hook into the vertical refresh interrupt (at 18 Hz) and essentially operated invisibly to the other program on MS-DOS. Remember we didn't have multitasking as standard, Linux didn't exist yet and Windows was still a joke. Many people did not even own PC compatible computers, as they were termed then, as standard, and if they did, it may have only been an 8086 or 80286 running at 8 or 10 MHz. Also RAM was limited, 640K RAM was still expensive. | His software was written in 8088 assembler as a Terminate and Stay Resident (TSR) program on MS-DOS, TSRs would sit in the background, would typically hook into the vertical refresh interrupt (at 18 Hz) and essentially operated invisibly to the other program on MS-DOS. Remember we didn't have multitasking as standard, Linux didn't exist yet and Windows was still a joke. Many people did not even own PC compatible computers, as they were termed then, as standard, and if they did, it may have only been an 8086 or 80286 running at 8 or 10 MHz. Also RAM was limited, 640K RAM was still expensive. | ||
- | BPQCode in the very early days was in source form so you could configure (callsign, etc) and compile it. That stopped fairly quickly after some people changed the copyrights on it, which understandably annoyed John immensely. It had a fairly crude packet tracing format. It worked very well and became a big hit with people who ran BBSs. I wrote a more fully featured packet tracing code for it in either late 1988 or early 1989, I followed the TAPR format for the AX.25 level 2 part, but devised my own format for NET/ROM. | + | BPQCode in the very early days was in source form so you could configure (callsign, etc) and compile it. That stopped fairly quickly after some people changed the copyrights on it, which understandably annoyed John immensely. It had a fairly crude packet tracing format. It worked very well and became a big hit with people who ran BBSs. I wrote a more fully featured packet tracing code for it in either late 1988 or early 1989, while attending a course at the hotel used for filming the original series of Crossroads, I followed the TAPR format for the AX.25 level 2 part, but devised my own format for NET/ROM. |
- | John attended Sysop 2 and subsequent ones, and was often deferred to in technical discussions by most people. | + | John attended Sysop 2 and subsequent ones, and was often deferred to in technical discussions by most people. I mentally marked anyone who argued with him as morons. |
===== About BBSs ===== | ===== About BBSs ===== | ||
Line 47: | Line 47: | ||
There was an interface that ran parallel with the TAPR commands and that was host mode. This was created by the guy behind NET/ROM, and indeed NET/ROM implemented a subset of it for commanding it over the serial port. I think we both looked at host mode and declared it as being nonsense on stilts, even over thirty years later, I still feel that way about it. | There was an interface that ran parallel with the TAPR commands and that was host mode. This was created by the guy behind NET/ROM, and indeed NET/ROM implemented a subset of it for commanding it over the serial port. I think we both looked at host mode and declared it as being nonsense on stilts, even over thirty years later, I still feel that way about it. | ||
- | I got to know F6FBB in the late 1990s. I visited him a few times when he came to Paris for business. I was living in Brussels (and later Zurich) by then, and hopping over the border was pretty simple. We spent time talking about packet, but mostly eating good food and drinking excellent wine. I have a particularly strong | + | I got to know F6FBB in the late 1990s. I visited him a few times when he came to Paris for business. I was living in Brussels (and later Zurich) by then, and hopping over the border was pretty simple. We spent time talking about packet, but mostly eating good food and drinking excellent wine. I have a particularly strong |
===== 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. |
- | The groups | + | 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/ | + | 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/ |
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, | 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, | ||
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, | Although the location of RP was sensationally good, it did suffer from some pretty obvious drawbacks. The 2m packet frequency had 100% utilisation, | ||
- | 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, | 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, | ||
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 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 " | 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 " | ||
- | 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 |
- | 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, | + | 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, |
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 |
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 113: | Line 115: | ||
Only two groups worldwide used ROSE in reality. One was in the north-east of the USA and were named RATS, W2VY was my main contact with them, and he was developing a ROSE ROM for the TNC-2. The other group was in south-west France, which is how I made friends with F6FBB who was a part of that group. | Only two groups worldwide used ROSE in reality. One was in the north-east of the USA and were named RATS, W2VY was my main contact with them, and he was developing a ROSE ROM for the TNC-2. The other group was in south-west France, which is how I made friends with F6FBB who was a part of that group. | ||
- | One of the shocks of my life was when I received an email from Mr. Linux, | + | One of the shocks of my life was when I received an email from Mr. Linux, |
The kernel code spawned a large set of users, and some were very clever with leveraging programs to provide invisible links. For example we had ax25d which was the AX.25 version of inetd, and that could be used to spawn programs based on incoming packets using different SSIDs for differentiation. Some people had some pretty amazing plumbing between machines and programs using pseudo-ttys and other mechanisms. | The kernel code spawned a large set of users, and some were very clever with leveraging programs to provide invisible links. For example we had ax25d which was the AX.25 version of inetd, and that could be used to spawn programs based on incoming packets using different SSIDs for differentiation. Some people had some pretty amazing plumbing between machines and programs using pseudo-ttys and other mechanisms. | ||
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 | + | 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 |
+ | |||
+ | 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 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, | ||
packet/history.1749487440.txt.gz · Last modified: by g4klx