I listened in to the SAQ Alexanderson transmissions from Grimeton in Sweden to my shack in the west of Ireland. Reception went well.

In my mobile setup, I want to run a Direwolf instance with two ports (VHF and HF) on an Orange Pi Zero. APRSDroid is used to monitor both ports and send messages through them. Since …

Source

The Alexanderson transmitter in Grimeton is due to broadcast a message on 30 June 2024. I plan to listen to it using a soundcard and GNURadio Companion: this is what I have set up to do so.

In this edition: * Starliner Brings Another Ham to ISS * Q&A Session with AMSAT...

In this edition: AMSAT Mail Alias Service to End August 1, 2024 2024 AMSAT Field...

In this article I will expose how I built a VHF (1200bps AX25 APRS) to UHF LoRa APRS Bridge without going through APRS-IS (Internet). This is work in progress, feel free to comment and come …

Source

Growing up as the youngest of 4 boys, I was well positioned to receive all the hand-me-downs. Although that might sound as if I just ended up with second-rate stuff, that was not the case at all. I inherited a lot of great things from my older brothers. I couldn’t have cared less that they’d had them before me. The stash consisted of all sorts of board games, Dinky toys, and books, as well as something that would fuel my imagination for many years to come – a crystal set. My very own crystal set! Manufactured by Ivalek, this little beauty sat in it’s white plastic case by my bedside, delivering quality programming from the BBC 24/7 –

In truth, in the big world of crystal sets, this little mass-manufactured set wasn’t a very good performer at all. In fact, I’d go as far as to say it was pretty awful, having the following schematic, which I don’t think should ever be used for anything other than a teaching tool, but not a practical build –

The above is almost the simplest crystal set you can build. The Ivalek also has a switch that switches in extra inductance for the long wave band, but we’ll ignore that. The main problems with the above schematic are –

1. The antenna is not impedance-matched to the coil, so it will load it down, reducing Q and therefore, selectivity.
2. The diode is not impedance-matched to the tank, loading down the tank, and also affecting Q, and selectivity.
3. The headphones may not be matched to the diode affecting – yes, you guessed it, circuit Q and, therefore, selectivity.

A lot of simple “toy” crystal sets that were marketed to kids in the 50’s, 60’s, and 70’s employed this simple schematic and, as a result, we all got the idea that crystal sets were fun, but not very good, and not to be considered as a “serious” receiver for extended periods of listening. In my case, making things worse, was that I thought the telephone earpiece I was using was high impedance. 8 year-old me had no idea the impedance was actually closer to 150 ohms. The end result of all of this was that my crystal set had very broad tuning indeed. On the other hand, it was very loud, because we lived only a few miles from the BBC Droitwich transmitters. The longwave transmission, on 200KHz at the time, was 500KW in power, and covered most of the UK. The medium wave signals, though not quite as powerful, were certainly not QRP either.

The lackluster performance of my Ivalek crystal set didn’t put me off. I just thought it was the neatest thing that I could leave it on all the time, and would never have to change the batteries. Plus, I had plenty of chances to listen surreptitiously under the covers at night, when I was supposed to be sleeping!

I also had this magnificently compelling book –

The Boys Book of Crystal Sets contained construction details for 12 different sets of varying complexity and, presumably, performance. The young me spent hours and hours gazing at all the articles and schematics, and thinking how grand it would be if I had an air-spaced variable capacitor or two, some litz wire to wind a coil with, and an empty tobacco tin or chassis, to build my crystal receiver in. I’d be the king of the hill! But an 8 year-old boy living in the countryside in the early 1970’s didn’t have the means to procure such elite and specific luxuries, so I settled for reading each article a couple of hundred times, and day-dreaming.

About 10 years ago, I came across a web-site belonging to Jim Frederick W4LF. Jim is a big fan of Cushman scooters, which are uniquely American motor scooters that boast an earnest following of enthusiasts. The Cushman Scooter company was formed in Lincoln, Nebraska in 1903, and produced their last scooters in 1965. The majority of Jim’s site is given over to discussion of these machines. As you might guess, it wasn’t these that interested me, but a single page on Jim’s site that is dedicated to another of his interests – little radios and crystal sets. On this page Jim shows pictures, with brief descriptions, of the neat little radio receivers he has built over the years. They include regenerative receivers, crystal receivers, and some amplified crystal receivers. I loved not only the fact that he was using double-tuned circuits with, in many cases, adjustable capacitive coupling between the tank and the detector for greater control over the selectivity of the circuit. I also really appreciated the attention paid to the casing and overall appearance of the final product. These were some really appealing little receivers!

Recently, I had the honor of assembling a pre-production beta build of the 3rd generation of Jim W4LF’s Hobbydyne Crystal Set Receiver kit. I won’t go into details of the build here, but the kit should be available soon, at this site. If it is not yet active, save it in your bookmarks, and check back later. When the site is up and running, it will be the place to get more info on this kit.

I’m very happy with the end result, and I hope you’ll agree that it is a very good-looking little crystal set, with it’s African mahogany base, and garolite front panel –

From top left to top right, the knobs are – a rotary switch to add extra capacitance to the antenna tuning capacitor, for help in tuning different lengths of antenna, the variocoupler, which controls the coupling between the coils, and also the selectivity and, on the far right, the Hobbydyne selectivity enhancement control. The circuit of this set is heavily based on, and very similar to Jim’s original Hobbydyne circuit, which was featured in Dave Ingram’s column in the Nov 2005 issue of CQ Magazine.

The brass binding posts on the left are for antenna and ground connections, and those on the right are for the headphones.

The headphones are a set of Western Electric 509-W’s. They’re about 100 years old and work well, if you’re looking for a set that will plug directly into a crystal receiver without the need for impedance matching.

As soon as I had constructed Jim’s Hobbydyne kit, I started looking for two things in quick succession –

1. A good set of high impedance headphones and
2. An impedance matchbox, to experiment with different types of headsets/headphones.

While planning the construction of an impedance matchbox, to match a variety of crystal set detectors with a range of headphone impedances, I also kept an eye out on eBay for headphones, and the necessary parts to build a sound-powered headset. That is the subject of a whole new post, which will come after this one. The construction of just one crystal set, which you’d think would be a simple affair, while not quite turning into a rabbit hole, was certainly becoming quite involved!

I have a habit of over-estimating how involved I’m going to become in pursuits when still in the beginning stages. For instance, when digital photography was really starting to take hold, in the early-mid 2000’s, I decided to get back into photography, which had first grabbed my interests as a teenager. This time though, I was an adult with more disposable income. I went a bit hog-wild, buying a nice camera and a whole slew of lenses, accessories, and even some studio lighting equipment (not the cheap kind either). Although I had a lot of fun with all that gear, I realized over the next few years that I had overbought, and spent a fair bit of time selling all the photo accessories that were surplus to my needs, eventually distilling them down to only the essentials. All this is a prequel to me saying that if you want a crystal set which performs well but, being realistic, you’re not going to want to eke out the very last drop of high performance from it, you might be happy with connecting a set of high impedance headphones directly to the output of your new crystal set, and leaving it at that. I wanted to be able to test out a variety of different types of headset, headphones, and earbuds, so an option that offered a variety of output impedances was definitely on the cards for me. A selection of different input impedances would also allow experimentation with other crystal sets in the future.

Crystal set builders have used various methods to match the diode detectors on their receivers to headphones over the years, with a variety of transformers being used. Darryl Boyd’s very informative site at crystalradio.net has a section devoted to detector to headphone impedance matching, with a number of approaches detailed. One of the most recent solutions has been the very useful Bogen T725. More recently, an auto-transformer has come onto the market that is wound specifically for the needs of crystal set builders. The KPB-02 auto-transformer has both inputs and outputs (on the same terminals, being an auto-transformer) of 200KΩ, 100KΩ, 40KΩ, 20KΩ, 10KΩ, 5KΩ. 2.5KΩ, 1.5KΩ, 800Ω, 500Ω, 300Ω, 150Ω, 64Ω, 32Ω, 16Ω, 8Ω, and 4Ω. It was custom-made for our needs and, as such, has input and output impedances that satisfy any possible need a crystal set builder could conceivably want. Look for the KPB-02 on eBay, being sold by seller mkmak222. This auto-transformer formed the basis for my all-purpose crystal set impedance matchbox.

On the input of the box is a Benny, consisting of a 0.1µF capacitor and a 500K audio taper potentiometer. The Benny is named after Ben Tongue, who wrote a series of detailed technical articles on the subject of crystal sets, which, taken together, probably represent the most detailed analysis of this type of receiver architecture ever published. Ben is no longer with us, but you can find his articles here. You might want to save them all just in case one day, they are no longer hosted anywhere online. He talks about the Benny in article 01. Very briefly, it helps to reduce audio distortion on strong signals, by equalizing the DC and AC audio loads on the diode detector.

Both rotary switches are 12 position types but on the first one, on the input side, I only used 7 positions. Some switches have an adjustable stop, so that the switch will only rotate to the number of positions set by the user. You’re highly unlikely to encounter a detector with an impedance lower than 2.5K, so there is little point in going any lower. The last two positions, of 5K and 2.5K, are included in case a device such as a MOSFET is used as a detector; with diode detectors, the impedance is going to be somewhere in the 200K to 10K range.

There is more potential for variety when it comes to the output impedances, so you’ll probably find yourself using all of the positions of a 12 position switch. There are 20 position switches available, which would allow a builder to make all of the 17 impedance taps available. However, they are a bit pricey. On top of that, the one I found didn’t have a lug to prevent a loose switch from rotating, and I like to make use of those.

In my matchbox, all of the taps from 100K down to 1.5K were utilized. I found that range covered all of the vintage high impedance ‘phones I tried out, as well as the piezo earpieces in my collection. Kevin Smith, when building his impedance matchbox, divided his ranges a little differently from mine. His ranges were 100K down to 10K for magnetic and piezo ‘phones, 1.5K down to 300 for sound-powered headsets, and 32 to 8 for modern low impedance ‘phones and earbuds. The sound-powered headset that I put together turned out to have an AC impedance at 1KHz of about 3K, so the middle impedance range in the hundreds of ohms wasn’t needed. When describing his impedance matchbox, Kevin talks about the lack of a need for exact impedance matching, due to a listener’s inability to distinguish much of a difference in volume when the mismatch creates a volume difference of 3dB or less. He calls it “the 3dB slop”. If you build your own matchbox you will notice, when stepping through the impedance taps, how for any given set of ‘phones, there are several switch positions that give acceptable and almost equal volume. Looking at the schematic above you can see how, if you did happen to have a headset with an impedance of 800 ohms, for example, the closest tap available at the switch, is 1.5K, which would still give an acceptable match. Likewise, if your headset had an impedance of 500 ohms, the 300 ohm position would be adequate.

The KPB-02 auto-transformer doesn’t have a built-in mounting bracket. I cut a strip of flexible plastic from the top of a small storage container and used to it mount the transformer to the lid of an ABS plastic project box –

In the next photo, you can see an earlier version of the matchbox, which utilized chunkier, more modern binding posts. They are the type often marketed for speaker connections. I discovered that it is not as easy to connect the bare wire ends of the metal tips often used on vintage headphones to them, as it is with the more traditional style of brass binding post. I also ended up changing some of the impedance taps from the ones shown in this photo. There are vinyl bumper feet on two sides of the box, so it can be used in two different orientations –

Although a single pair of binding posts are used for the input, more output options are provided, in the form of a 1/4″ jack wired for mono, and a 3.5mm jack wired for stereo headphones, with the velements placed in parallel, in addition to the binding posts for the metal pins on vintage headphones as well as bare wire ends –

The internal wiring in the first version of this matchbox, before the wiring to the impedance taps was changed a little –

On realizing that traditional brass binding posts were going to work better in this application, I took out the speaker posts, made a trip to Ace Hardware, bought the appropriate brass hardware, and fitted the impedance matchbox with 2 handsome sets of brass binding posts. I also changed the wiring to some of the impedance taps on the transformer. Note the new labeling –

Unfortunately, swapping the location of the binding posts necessitated a lengthening of the wiring, and made it a bit more untidy. Nevertheless, I wanted brass binding posts on this matchbox, and am glad I added them –

The brass nuts on these binding posts are called brass flanged knurled-head thumb nuts on the McMaster Carr site, though I got mine from my local Ace. The 3.5mm jack is wired so as to place the 2 elements in parallel. I did this so that they would be fed in phase. If you use the ring and tip connections to feed them in series, you will end up feeding them 180° out of phase, though I’m not sure if that makes a noticeable difference in practice. The 1/4″ jack is wired to the sleeve and the tip only, for mono jacks. Another change I made, was to place the binding posts on the end of the enclosure that faces the operator. In the previous version, they were at the back, causing the metal tips of vintage headphones that were connected to the binding posts, to foul the two jacks. Small ergonomic details like that make quite a difference to the usability of a piece of gear –

One thing I noticed, stepping through the different output impedance positions for a given headset, was that although nearby switch positions to the optimum one produced almost exactly the same volume, the tonal quality changed. If the switch position is set higher than the headset impedance, higher audio frequencies are favored. As you rotate the switch through the optimum position to impedances that are lower than optimum, more bass response is favored. This could possibly be used with very weak signals, as a switch position that favors higher frequencies could, if copy was very marginal, perhaps improve intelligibility enough to be able to ID a station.

An impedance matchbox is a useful piece of gear in an experimental crystal set receiving station. It makes constructing subsequent crystal sets easier, as the builder doesn’t have to keep replicating the audio circuitry after the detector diode.

In the next post, I plan to show you the various vintage as well as modern headphones and headsets that I tested with the Hobbydyne Crystal Set and impedance matchbox combination.

In the meantime, more information on Crystal Sets, and DX’ing with them, can be found in the following, as well as the various individual blogs on the subject (I’ll let you find those!) –

The Crystal Radio DX Group on Facebook – a group founded and run by Steve VE7SL. Intended specifically for discussion of crystal set DX listening events, as well as circuits and techniques specific to DX’ing with crystal sets.

The Crystal Set Radio Group on Facebook – a larger group, for general discussion of crystal sets. If you are a newcomer to the world of crystal sets, this would be a better group for you than the previous one.

The New Radio Board – intended as a new version of the now defunct (and much missed) Radio Board Forum, this board contains discussions of construction of several different types of receivers, including solid state radios, tube radios, and crystal sets. Links to the different topics can be accessed from the lists of hashtags.

A good introduction to the subject of crystal sets can be found in this engaging talk given by Al Klase to the New Jersey Amateur Radio in 2022, titled ,“Understanding and Building Crystal Radio Sets”. The graphics to go along with the talk are here.

With a bit of work, one can successfully feed an array of LF-HF receivers from one broadband antenna.

The post KX4O SDR Receiving Electronics appeared first on Ham Radio . Magnum Experimentum.

Well, it took five months and more work than I had ever anticipated. But the results is a nearly 200-page study of Marconi's Carnarvon transmitter site in north Wales.

 

You might think it too geographically-niche for where you are, but much of the station was replicated across the world, whilst certain elements were unique.

In the words of the Marconi Co. itself:

"The history of the Carnarvon station is, in large measure, the history of the Marconi Company’s work on high-power transmitters..."

You can buy a copy of my work, the first to use fieldwork and archive study to fully examine and understand this vast site in the 83 years since it was dismantled, using the PayPal smart button here - just £9.99 and available worldwide.

You will also receive a free, meticulously-prepared Google Earth-based plot of the features identified during the fieldwork, and how it all fitted together as a multi-antenna VLF site. 

The text and countless images are delivered as a PDF file; you will received a password to access the file after purchase.

Marconi MUU inverted-L transmitter site early in its life (1913, possibly before radiating wires had been installed).

 

 

The Airspy YouLoop is a no tune, broadband, small footprint, affordable LF to HF receive antenna that works indoors. Its modular construction facilitates experiments to understand where the Möbius inspired electrical design provides benefit.

The post Airspy YouLoop LF/MF/HF Möbius Receive Antenna appeared first on Ham Radio . Magnum Experimentum.

Aviation LF/MF beacons provide the opportunity to admire electrically-small antenna design on a macroscopic scale.

The post Anatomy of a low frequency aviation radio beacon appeared first on Ham Radio . Magnum Experimentum.

💾

Direwolf is very capable software TNC, yet it is not yet possible to add twist between the high and low tone e.g if you want to feed 1200bps to the 9600bps flat audio input of …

Source

The ways to start Direwolf at boot, as provided in the manual, are quite archaic and hacky. Let’s see how we can do this in a more modern way using systemd. Why I don’t like …

Source

Wenn im Zusammenhang mit dem Amateurfunk von IP-Vernetzung die Rede ist, werden viele sicherlich zuerst an das HAMNET denken, ein Hochgeschwindigkeitsnetzwerk auf IP-Basis. Doch darum soll es in diesem Artikel gar nicht gehen. Denn obwohl die Möglichkeiten des HAMNET, insbesondere die verfügbaren Datenraten, überzeugend sind, gibt es doch einige praktische Einschränkungen. Die vermutlich größte Hürde in das HAMNET einzusteigen sind die Ausbreitungseigenschaften des hierfür verwendeten 2,4 GHz-Bandes. Ohne direkten Sichtkontakt geht da nicht viel. Das heißt in der Praxis: Eine flächendeckende Versorgung mit HAMNET steht in ländlichen genauso wie städtischen Gebieten noch in den Sternen, obwohl bereits ein erheblicher Aufwand getrieben wurde, um sogenannte Benutzereinstiege bereitzustellen. Auch der neuerdings zusätzlich verfolgte Ansatz mit Breitbanddatenübertragungen auf dem 70cm-Band mittels NPR70 findet seine Grenzen in dem knappen zur Verfügung stehenden Frequenzspektrum, das sich viele Anwendungen teilen müssen.

Deshalb haben Silvio DM9KS, Jan DL9JBE und Björn DL1PZ in den letzten zwei Jahren diverse Versuche zur IP-Vernetzung unternommen und dabei “normale” Funkkanäle verwendet. Es wurden FM-Verbindungen mit 7 bzw. 12,5 kHz Kanalbreite auf dem 10m-, dem 2m- und dem 70cm-Band genutzt. Die dort erreichbaren Datenraten kommen natürlich nicht an die Geschwindigkeiten des HAMNET heran. Dafür sind aber IP-Verbindungen auch unter wesentlich widrigeren Funkbedingungen überhaupt herstellbar. In diesem Artikel sollen die verschiedenen Hard- und Softwarekomponenten bzw. Protokolle vorgestellt werden, die im Rahmen der Versuche erprobt wurden.

Versuchsaufbau

Der grundsätzliche technische Aufbau folgte stets dem gleichen Schema. Eine oder mehrere IP-fähige Anwendungen (z. B. IRC-Chatprogramme, Telnet, Schachprogramme, usw.) erzeugen IP-Datenpakete. Diese werden durch einen Einpacker um ein Rufzeichen und Protokollinformationen ergänzt an einen Terminal Node Controller (TNC) weitergegeben, der die Datenpakete für die Übertragung auf dem Band vorbereitet und dann über eine Audioschnittstelle an einen Transceiver übergibt. Empfangene Übertragungen werden andersherum durch den Transceiver über die Audioschnittstelle an den TNC zur Dekodierung übergeben. Dann werden Rufzeichen und Protokollinformationen durch den Auspacker entfernt und die empfangenen Nutzdaten als IP-Paket (über das Betriebssystem) an die IP-Anwendung weitergegeben.

In dem immer gleichen Schema war – neben der Verwendung von IP – die Konstante bei allen Versuchen das sogenannte KISS-Protokoll, auf das später noch eingegangen wird. Alle anderen Komponenten wurden in den Versuchen durch wechselnde Hard- bzw. Software implementiert.

AX.25

Der älteste Vertreter der Lösungen zur IP-Vernetzung über den Amateurfunk ist das AX.25-Protokoll. Dieses ursprünglich für Packet-Radio geschaffene Protokoll bringt auch die Möglichkeit des Transports von IP-Paketen mit. AX.25 ist ein umfassendes Netzwerkprotokoll, das selber auch ganz ohne IP-Netzwerk in der Lage ist, Computer und angebotene Dienste (wie Mailboxen) zu verbinden. Bis zum Ende des letzten Jahrtausends wurde es bei Funkamateuren rege genutzt und es bestand praktisch flächendeckender Zugang zum Packet-Radio-Netzwerk über Funk.

Das Protokoll enthält eine Vielzahl an Funktionen, z. B. zu Multiplexing, Flusskontrolle oder Routing, die für die IP-Vernetzung jedoch keine Rolle spielen. Diese Aspekte werden bereits von IP (bzw. genau genommen TCP/IP) selber gelöst. Daher beschränkt sich dieser Artikel auf die für den Anwendungsfall relevanten Teile von AX.25.

Im Folgenden wird nur der Sendeweg beschrieben. Der Empfangsweg verhält sich entsprechend genau andersherum. Das heißt die sendeseitig hinzugefügten Informationen werden in umgekehrter Reihenfolge wieder entfernt bzw. die vor der Aussendung vorgenommene Modulation wird entsprechend demoduliert.

AX.25 definiert gleich zwei der im schematischen Aufbau dargestellten Komponenten: Den Ein- und Auspacker für IP-Pakete sowie den TNC (aber nicht das Modem). Im AX.25-Protokoll ist diese Aufgabentrennung zwar überhaupt nicht vorgesehen, doch in der Praxis ist sie weit verbreitet. Auch das KISS-Protokoll ist nicht Teil von AX.25, doch dazu – wie schon versprochen – später mehr.

Bei den ersten Versuchen wurde die in Linux eingebaute AX.25-Unterstützung verwendet, um IP-Pakete ein- bzw. wieder auszupacken. Praktisch passiert dabei folgendes: Zu jedem IP-Paket, das auf die Funkschnittstelle gesendet werden soll, werden zunächst zusätzliche Informationen hinzugefügt, bevor das Paket an den TNC übergeben wird. Hierzu werden zwei der durch AX.25 spezifizierten Funktionalitäten genutzt, nämlich die Adressierung und die Protokollidentifikation.

Rufzeichen und Protokollidentifikation

AX.25 verwendet Amateurfunkrufzeichen, um den Absender und den oder die Empfänger einer Übertragung anzugeben. Zur Unterscheidung mehrerer Stationen des gleichen Rufzeicheninhabers ist es vorgesehen, optional eine Zahl von 1 bis 15 als sogenannten „Secondary Station Identifier“ („SSID”) anzuhängen, z. B. DL1PZ-14. Die Kodierung des Rufzeichens erfolgt als 7-Bit-ASCII-Zeichenkette, wobei das jeweils freibleibende 8. Bit anderweitig genutzt wird. Die Erzeugung und Verarbeitung gestaltet sich daher etwas komplizierter, zudem die sieben ASCII-Bits auch noch um ein Bit zur Seite verschoben werden. AX.25 beschränkt die Länge der Rufzeichen strikt auf 6 Zeichen, was die Verwendung von längeren Rufzeichen (z. B. Sonderrufzeichen) leider vollkommen unmöglich macht. AX.25 sieht als Adressangabe mindestens eine Absender- und eine Zieladresse vor.

In der AX.25-Konfiguration von Linux wurde jeweils das eigene Rufzeichen hinterlegt. Dieses wird dann automatisch zu jedem Paket hinzugefügt. Da AX.25 zwingend auch eine Empfängeradresse vorschreibt, welche jedoch für die IP-Vernetzung nicht nötig ist, wird das entsprechende Feld durch Linux automatisch mit dem Text “QST” belegt. Diese Q-Gruppe steht in CW für eine Sendung an alle Stationen.

Weiterhin setzt AX.25 noch einen sogenannten “Protocol identifier” (“PID”) vor die eigentlichen Nutzdaten. Im behandelten Falle, also der Übertragung von IP-Paketen, wird hier hexadezimal 0xCC für IPv4 vermerkt. Ein PID für IPv6 ist in der letzten Version 2.2 des AX.25-Standards nicht vorgesehen. Dementsprechend kann mit diesem Ansatz auch keine Vernetzung per IPv6 sondern nur per IPv4 vorgenommen werden.

KISS-Protokoll

Nachdem nun diese beiden Informationen hinzugefügt wurden, wird das Datenpaket an den TNC weitergegeben. Dazu wird das schon erwähnte KISS-Protokoll verwendet, meist über eine serielle Schnittstelle. Dieses ist mit dem SLIP-Protokoll verwandt, bei dem bestimmte Steuerzeichen einen seriellen Datenstrom in einzelne Pakete unterteilen. Die Abkürzung KISS bezieht sich hier auf das sogenannte KISS-Prinzip, Dinge einfach zu halten (engl. “Keep it simple, stupid!”, zu Deutsch also “Halte es einfach, Dummerchen!” oder etwas sachlicher formuliert: “Mach’ eine Sache nicht komplizierter als nötig”). Entsprechend ist das Protokoll auch überschaubar definiert. Am Anfang und am Ende der Übertragung wird jeweils ein Byte mit dem hexadezimalen Wert 0xC0 als Begrenzung eines Datenpakets angefügt. Sofern in den Daten selber der Wert 0xC0 vorkommt, wird dieser durch die Bytefolge 0xDB 0xDC ersetzt. Wenn wiederum ein 0xDB vorkommt, wird dieses durch die Folge 0xDB 0xDD ersetzt.

TNC für AX.25

Die Aufgabe des TNC ist es nun, das Datenpaket für die Übertragung auf der Funkschnittstelle vorzubereiten. Ein für AX.25 ausgelegter TNC erledigt dabei zunächst die folgenden Aufgaben:

• Bitstopfen (engl. “bit stuffing”): Das Einfügen von einem oder mehreren Füll-Bits in einen Datenstrom. Im Falle von AX.25 konkret das Einfügen eines zusätzlichen 0-Bits, falls fünf 1-Bits unmittelbar aufeinander folgen.
• Rahmensynchronisation: Dient dem Erkennen von Anfang und Ende eines AX.25-Datenpakets (streng genommen gemäß OSI-Schichtmodell als “Datenframe” zu bezeichnen). Konkret beginnt und endet jedes AX.25-Datenframe mit der Bit-Folge 01111110 (hexadezimal 0x7E). Daher auch das vorgenannte Bitstopfen, das sicherstellt, dass diese Sequenz niemals innerhalb der tatsächlich übertragenen Nutzdaten vorkommt, sondern nur als Rahmensynchronisation.
• Fehlererkennung: Das Erkennen von Übertragungsfehlern (z. B. aufgrund von Störungen auf dem Band) durch den Empfänger. Hierzu fügt der Sender im Falle des AX.25-Protokolls vor dem Ende eines jeden Datenframes (unmittelbar vor der Rahmensynchronisation) eine Prüfsumme ein, die vom Empfänger kontrolliert werden kann.

Als letzten Schritt der Vorbereitung führt das im TNC integrierte Modem nun die Modulation durch. Dieser Schritt ist nicht mehr Teil der AX.25-Spezifikation. Aus der langjährigen Praxis des Betriebs von Packet-Radio haben sich jedoch zwei Varianten der Modulation herauskristallisiert: Einerseits AFSK mit 1200 Baud entsprechend des Half-Duplex-Modus der Bell-202-Modem-Spezifikation und andererseits FSK mit 9600 Baud nach G3RUH. Praktisch alle Hardware-TNCs unterstützen eines dieser beiden Verfahren. Software-Lösungen bieten hingegen neben diesen beiden Verfahren auch noch eine Reihe weiterer Modulationsarten.

Anschluss an das Funkgerät

Für die Verbindung zwischen dem TNC und dem Funkgerät wird eine herkömmliche analoge Audioverbindung genutzt. Fast jedes Funkgerät verfügt über einen Anschluss für Mikrofon und externen Lautsprecher, welche mit dem TNC verbunden werden können. Im Falle von Software-TNCs ist entsprechend die Soundkarte des Computers mit dem Funkgerät zu koppeln.

Manche hochwertigere Funkgeräte verfügen auch über einen sogenannten 9600-Port. Dieser bietet einen Ein- und Ausgang für Audiosignale, bei denen das Signal jedoch an den üblichen NF-Filtern (Bandpass) vorbeigeführt wird und somit ein größeres Frequenzspektrum durchgelassen werden kann. Der Verzicht auf Filter vermeidet außerdem ein nichtlineares Verhalten hinsichtlich des Phasenganges und stellt damit eine einheitliche Verzögerung des gesamten Signals unabhängig von den übertragenen NF-Frequenzen sicher. Mit einem 9600-Port ist es einfacher, hohe Datenübertragungsraten zu erreichen. Dieser Anschluss ist die Voraussetzung für die Verwendung eines 9600-Baud-Modems nach G3RUH.

Audiopegel

Grundsätzlich gilt: Der Audioausgang des TNCs oder – im Falle eines Software-TNCs – des Computers ist mit dem Audioeingang des Funkgeräts und andersherum der Audioausgang des Funkgeräts wiederum mit dem Audioeingang von TNC bzw. Computer zu verbinden.

In der Praxis hat es sich als sehr wichtig herausgestellt, die Audio-Lautstärke in beide Richtungen korrekt einzupegeln. Sendeseitig sollte die in das Funkgerät eingegebene Audiolautstärke so gewählt sein, dass sie so laut wie möglich ist ohne das es zu Verzerrungen des Signals kommt. Bei Geräten mit eingebautem Audio Level Controller (ALC) kann dies leicht erreicht werden, indem die Lautstärke soweit angehoben wird, dass die ALC-Anzeige gerade so nicht ausschlägt. Empfangsseitig sollte die Lautstärke so eingestellt werden, dass die empfangenen Signale keinesfalls übersteuern.

Verbesserungspotential von AX.25-TNCs

Bei den Versuchen wurden unterschiedliche AX.25-TNCs verwendet. Eine Besonderheit war dabei der PicoAPRS, der TNC und Transceiver zu einem winzigen Gerät vereint. Als reine Software-Lösung kam immer wieder Dire Wolf zum Einsatz.

Leider sieht AX.25 für die Fehlererkennung lediglich eine 2 Byte lange CRC-Prüfsumme vor. Diese erlaubt es mit relativ hoher Wahrscheinlichkeit, eine fehlerhafte Übertragung als solche zu erkennen. Die Möglichkeit einer Fehlerkorrektur, weil z. B. der Kanal kurz gestört war, erlaubt dies aber nur sehr eingeschränkt. Der technische Stand dazu hat sich seit der Spezifikation von AX.25 aber deutlich weiterentwickelt.

So unterstützt der Software-TNC Dire Wolf schon seit einiger Zeit eine Fehlerkorrektur mittels Reed-Solomon-Codes. Diese Fehlerkorrektur kommt in einem zu AX.25 rückwärtskompatiblen Kodierungsverfahren mit der Bezeichnung FX.25 zum Einsatz. Dem aktuellen Stand der Technik entspricht dies jedoch auch noch nicht.

Ein heute übliches Verfahren zur Fehlererkennung und auch -korrektur sind sogenannte Low-Density-Parity-Check-Codes (LDPC), die z. B. bei DVB-S2 oder FT8 verwendet werden. Jan DL9JBE hat sich mit diesem Verfahren näher beschäftigt und dabei die experimentelle Software pktfec-tnc entwickelt. Das ist ein Software-TNC, der dieses Verfahren zur Fehlerkorrektur einsetzt. Da pktfec-tnc ebenfalls die KISS-Schnittstelle verwendet, kann es einfach anstelle eines AX.25-TNC verwendet werden. Als Modulation zur Übergabe per Audiokanal an das Funkgerät wird Quadraturamplitudenmodulation (QAM) verwendet, welche hinsichtlich Symbolrate (Baudrate) und Symbolanzahl (Bits je Symbol) relativ frei konfiguriert und somit an die Kanaleigenschaften angepasst werden kann. Die genauen technischen Hintergründe hat Jan im Artikel Schnellere Datenübertragung ohne Data-Port beschrieben. Praktisch gibt es also mehrere Methoden wie sich das AX.25-typische Ein- und Auspacken von IP-Paketen mit einem modernen TNC verbinden lässt.

Einschränkungen von AX.25

Aber auch bei der Verwendung von AX.25 für das Ein- und Auspacken von IP-Paketen stellten sich einige praktische aber auch theoretische Probleme. Wie bereits erwähnt unterstützt AX.25 ausschließlich IPv4 und ist nicht auf IPv6 vorbereitet. Das ist auch nicht verwundernswert, da das letzte Update des AX.25-Standards aus dem Jahre 1998 stammt, dem gleichen Jahr in dem IPv6 erstmals spezifiziert wurde. Leider scheint AX.25 IP-Datenpakete praktisch auch auf eine maximale Länge von 255 Bytes zu beschränken. Dies würde die Ergänzung einer IPv6-Unterstützung erschweren. Denn IPv6 verlangt, dass jeder Übertragungsweg darauf vorbereitet ist, Pakete mit 1280 Byte Länge zu unterstützen. Es wäre also nötig, einen neuen Mechanismus zur Aufteilung größerer Datenpakete in mehrere Teilpakete zu implementieren.

Bei der Adressierung ist AX.25 für den vorgesehenen Anwendungsfall nur eingeschränkt geeignet bzw. ineffizient. Eigentlich wird nur eine Angabe das Rufzeichens der Sendestation benötigt. AX.25 verlangt jedoch zusätzlich auch zwingend die Angabe eines Zielrufzeichens. Neben der erwähnten unpraktischen um ein Bit verschobenen Kodierung kommt erschwerend noch hinzu, dass AX.25 für das Absender- wie Empfängerrufzeichen jeweils eine feste Breite von 6 Zeichen zuzüglich SSID vorsieht und dafür jeweils 7 Byte benötigt. Das führt einerseits dazu, dass auch bei kurzen Rufzeichen stets 14 Byte für die Adressierung verbraucht werden. Anderseits macht es die Nutzung von Sonderrufzeichen unmöglich, die länger als 6 Zeichen sind.

Abschließend sei noch erwähnt, dass keine Umsetzung von AX.25-IP-Vernetzung für andere Betriebssysteme als Linux gefunden werden konnte. Damit war dann z. B. das von DL9JBE benutzte FreeBSD außen vor. Eine Portierung erschien aufgrund der Mängel hinsichtlich IPv6 und der Adressierung sowie der Gesamtkomplexität des Standards nicht vielversprechend.

Alternativen zum Verpacken von IP-Paketen

Eine weitere Möglichkeit zum Ein-  und Auspacken der IP-Pakete ist tncattach, welches auf einfache Art und Weise die beiden Aufgaben der Rufzeichennennung und Protokollidentifikation übernimmt und die Daten per KISS-Protokoll an einen TNC weiterreicht. Um IPv4 bzw. IPv6-Pakete zu kennzeichnen, stellt tncattach die zwei Byte lange Markierung gemäß dem Ethernet-Standard IEEE 802.3 vor jedes Paket, also hexadezimal 0x08 0x00 für ein IPv4- und 0x86 0xDD für ein IPv6-Paket. Es werden vorab noch 2 weitere Bytes hinzugefügt, die Linux-spezifisch definiert sind, deren genauer Zweck sich im Rahmen der Versuche nicht erschlossen hat. Die Rufzeichennennung erfolgt bei tncattach nicht in jedem Paket. Stattdessen werden von Zeit zu Zeit separate Datenpakete erzeugt, die nur das Rufzeichen erhalten. Das bietet den Vorteil, dass bei jeder Übertragung einige Byte eingespart werden können.

Die Software tncattach ist für die reine IP-Vernetzung gegenüber AX.25 als Fortschritt anzusehen. Die Funktionalität beschränkt sich weitgehend auf die IP-Vernetzung (zusätzlich ist auch die Vernetzung auf Ethernet-Ebene möglich) und IPv6 wird unterstützt. Rufzeichen werden ohne Bitverschiebung kodiert, also im Klartext. Es ist nur das Rufzeichen der Sendestation anzugeben und lange Sonderrufzeichen stellen auch kein Problem dar.

Nicht so gut gefallen hat, dass das Rufzeichen nicht in jedes Paket einkodiert wird. Rein formal wird das die Verpflichtung zur Rufzeichennennung im Amateurfunk möglicherweise erfüllen. Zumindest praktisch ist es so aber nicht ohne weiteres möglich, jede Sendung klar zuzuordnen. Es ist nicht erkennbar, welches IP-Datenpaket zu welchem Rufzeichen-Paket gehört. Eine Zuordnung wie im Sprechfunk anhand der Stimme ist ja nicht möglich.

Als größter Nachteil wurde allerdings festgestellt, dass tncattach ausschließlich für Linux entwickelt wird. Nach einer kurzen Betrachtung des Quellcodes ist der Eindruck entstanden, dass eine Portierung auf andere Betriebssysteme bisher leider nicht vorgesehen ist.

hamtunnel

Eine weitere Alternative zum Verpacken von IP-Paketen hat Jan DL9JBE als Ergänzung zu pktfec-tnc implementiert und dabei folgende Design-Kriterien zugrunde gelegt:

• Unterstützung für Linux und FreeBSD
• Kompatibilität zum KISS-Protokoll, um bestehende TNCs nutzen zu können
• Einfaches Protokoll, das leicht für den Menschen lesbar ist
• Rufzeichennennung in jedem Paket im Klartext
• Unterstützung beliebig langer Rufzeichen (auch z. B. Rufzeichen aus dem CB-Funk oder anderen Funkdiensten)

Die Software heißt hamtunnel und ist kann zusammen mit pktfec-tnc heruntergeladen werden. Genauso wie AX.25 und tncattach übernimmt hamtunnel die Anreicherung von IP-Paketen um eine Protokollinformation und das Rufzeichen. Dazu wird vor jedes Datenpaket als erstes das Rufzeichen in beliebiger Länge im ASCII-Klartext vorangestellt und mit einem Null-Byte (also hexadezimal 0x00) abgeschlossen. Es folgt dann die Markierung des IP-Protokolls im Klartext. Konkret wird die Zeichenfolge “IP4” bzw “IP6” verwendet, die sich von selber erklären dürften. Auch diese Sequenz wird mit einem Null-Byte abgeschlossen. Im Anschluss folgt unverändert das eigentliche IP-Paket.

Lesbarkeit von Daten für den Menschen

Die Lesbarkeit von Daten für den Menschen ist dabei ein interessanter Punkt, der hier noch etwas weiter ausgeführt werden soll. Viele Datenformate machen es leider schwer, Rohdaten ohne Spezialsoftware zu betrachten und zu verstehen. Das soll hier an einem Vergleich üblicher Datenpakete von AX.25 und hamtunnel dargestellt werden. Dazu wird jeweils der Anfang eines typischen Datenpaket wiedergegeben, wie es von einem TNC empfangen wurde. Es handelt sich dabei jeweils um ein IPv4-Paket, gesendet von der Station DL1PZ. Dabei werden druckbare ASCII-Zeichen als Text dargestellt und nicht-druckbare Zeichen als Hexadezimalzahl nach dem Muster <00>. In Fettschrift wird das Rufzeichen und die Protokollinformation hervorgehoben.

Beispiel AX.25:

<a2><a6><a8>@@@`<88><98>b<a0><b4>@a<03><cd><00><03><00><cc><07><04>...

Beispiel hamtunnel:

DL1PZ<00>IP4<00><49><50><34><00><45><00><00><54><FB><06>@<00>@<01>...

Im Falle von AX.25 ist praktisch überhaupt nicht zu erkennen, was für Daten vorliegen. Die Sequenz <88><98>b<a0><b4> ist übrigens DL1PZ in ASCII-Kodierung um ein Bit nach links verschoben und das Byte <cc> steht für IPv4. Die Kodierung von hamtunnel hingegen lässt das Rufzeichen leicht erkennen und gibt mit “IP4” einen klaren Hinweis darauf, welche Art von Daten anschließend zu erwarten sind. Zumindest für alle mit Programmiererfahrung ist das Null-Byte <00> leicht als Trennzeichen zu identifizieren. Die anschließend folgenden IPv4-Daten sind (genauso wie IPv6) leider nicht für den Menschen lesbar, da bei IP die Kopfdaten stets binär kodiert werden.

Fazit

Viele Wege führen zum Ziel. Zum Vorbehandeln der IP-Pakete mit Rufzeichen und Protokollinformationen können AX.25, tncattach oder hamtunnel genutzt werden. TNCs gibt es in Hardware, wie der PicoAPRS, und in Software, wie Dire Wolf oder pktfec-tnc, teils mit klassischer AX.25-Kodierung, teils mit moderneren Verfahren. Bei der Modulation ermöglichen die TNCs neben Klassikern wie 1200-Baud-AFSK gemäß Bell-202 oder 9600-Baud nach G3RUH viele weitere Verfahren. Dank KISS-Protokoll lassen sich die Komponenten beliebig kombinieren.

Eines darf dabei aber nicht vergessen werden: Nur wenn alle beteiligten Stationen exakt die selbe Art verwenden um IP-Pakete einzupacken, für die Übertragung vorzubereiten und zu modulieren ist ein erfolgreicher Datenaustausch möglich. Denn die Verfahren sind nicht untereinander kompatibel. Das ist leider ein Dilemma. Denn entweder verwenden wir möglichst etablierte (“gut abgehangene”) Verfahren wie AX.25 mit 1200-Baud-AFSK-Übertragung und bleiben auch mit alten Hardware-TNCs kompatibel – oder wir verzichten auf die Abwärtskompatibilität und setzen auf neuere Verfahren mit eleganteren Protokollen und moderner Fehlerkorrektur.

Jedes Jahr zu Weihnachten, zum Alexanderson-Day und zu besonderen Anlässen wie beispielsweise Veranstaltungen der Vereinten Nationen geht der Längstwellensenders Grimeton mit dem Rufzeichen SAQ wieder auf Sendung. Die Grundvoraussetzung für guten Empfang ist allerdings eine leistungsstarke Antenne. in den vergangene Jahren habe ich einige Antennen dafür gebaut und auch wieder verworfen. Meine Versuche mit Ferritstabantennen waren nicht von Erfolg gekrönt. Auch mit der MiniWhip bin ich nicht warm geworden. Die MiniWhip ist nicht schlecht, aber ich mochte die erforderliche zusätzliche 12V Stromversorgung nicht.

Ich habe in diesem Jahr also eine neue Antenne für den Empfang der Sondersendungen aus Grimeton gebaut.

Alles was man dazu benötigt ist eine 28 Zoll Fahrradfelge, 41 m Kupferlackdraht 0,8 mm², ein kleines Gehäuse, eine PL-Buchse und ein bisschen Kleinmaterial.

Reparaturwerkstätten für Fahrräder haben eigentlich immer Felgen, die zur Entsorgung vorgesehen sind, herumliegen. Für die Werkstatt ist es Schrott, für den Funkamateur allerdings eine Rahmenantenne. Ich habe bisher alle Felgen kostenlos überlassen bekommen. Die Werkstatt freut sich über weniger Entsorgungskosten.

Zuerst müssen die Speichen mit dem Seitenschneider entfernt. Im Anschluss sollte die Felge gründlich gereinigt werden. Nachdem ich die Felge gesäubert hatte, habe ich ein ungefähr 5 cm langes Stück aus der Felge herausgesägt. Das freigewordene Stück habe ich mit einer Gehäuseschale überbrückt, die später die PL Buchse aufnehmen wird. Zum Schutz des Kupferlackdraht habe ich mit Isolierband in das Laufrad eingeklebt. Manchmal befindet sich das alte Felgenband noch auf der Felge. Wenn man es schön sauber bekommt, dann ist es optimal als Schutz für den Wickeldraht geeignet.

 

Zunächst habe ich 50 Windungen Kupferlackdraht aufgewickelt und die beiden Enden des Drahtes mit der PL-Buchse verbunden. Die Felge habe ich nicht mit der Buchse verbunden. Die Felge hat einen Wickeldurchmesser von ca. 62 cm – Daraus ergibt sich eine Windungslänge von ca. 2 m je Windung.

Ich musste ernüchternd feststellen, dass mit 50 Windungen der Empfang fast bei Null lag. Nun habe ich nach und nach immer mehr Windungen entfernt und den Empfang immer wieder überprüft. Mit dem empirisch ermittelten Ergebnis von 20 Windungen, hatte ich den besten Empfang. Ich konnte am Sonntag Vormittag, den 09.12.2018, den Zeitzeichensender MSF aus Nordengland auf 60 kHz hören. Und das trotz Tagesdämpfung.

Etliche Langwellen Radiosender waren mit kräftigen Signalen sehr gut hörbar. Auch der Zeitzeichensender DCF77 aus Mainflingen (bei Frankfurt am Main), auf 77,5 kHz, war mit einem Signal über S9 zu empfangen.

 

Also Deckel drauf und fertig. Nun hängt die Antenne neben meinem ersten Prototypen, der nicht ganz so erfolgreich war. Eventuell lag das am dünneren draht, denn beim Prototypen hatte ich 0,2 mm² Kupferlackdraht genommen. Ich überlege die beiden Antennen 90 Grad zueinander auszurichten und beide anzuschließen.

 

Ich freue mich auf die nächste SAQ Aussendung und bin mal gespannt, ob ich sie damit hören kann.

In der Zwischenzeit kann man aber auch noch andere Dinge im VLF-Bereich hören. Da sind zum Beispiel die Sferics oder die “Schumann Resonanz” bei 7.83, 14.1 und 20.3 kHz und einige Zeitsignalsender, wie schon weiter oben genannt. Der begehrte SAQ ist bei 17.2 kHz aktiv, wenn er sendet. Bei ca. 100 kHz ist das Long Range Navigation System LORAN zu hören. Auf 147 kHz ist fast rund um die Uhr der Deutsche Wetterdienst aus Pinneberg in RTTY hörbar. Eine Liste von Längstwellensendern gibt es übrigens in der Wikipedia. Ab ca. 160 kHz beginnt das Langwellen Radioband. Hier tummeln sich überraschend viele Radiostationen. Das Funkfeuer unseres Flughafens (BRU) kann ich bei 426 kHz in CW hören. Wer Interesse daran hat, der kann einfach mal in langen Winternächten über das “Band” drehen.

Für den Empfang benötigt man natürlich einen geeigneten Empfänger. Wer keinen VLF Empfänger hat, der kann sich mit einem VLF Konverter behelfen. Die sind ultraleicht aus wenig Teilen zusammen zu bauen. Im Netz gibt es sehr viel dazu. Ich habe den VLF-Konverter von DL8UF nachgebaut. Wer ihn aus einer USB Quelle speist, der kann den ganzen oberen Teil im Schaltbild auch weglassen. Er dient nur der Stromversorgung. Man kann auch gleich mit der USB Spannung an VCC gehen! Ich kann die letzte Station mit diesem Konverter bei 655 kHz empfangen. Und nun viel Freude beim nachbauen.

Dieser Artikel erschien zuerst im Dezember 2018 in der gedruckten Ausgabe unseres Magazins. 

Im Jahr 2020 findet zu Weihnachten leider keine Sendung aus Grimeton statt.

 I had a past test on this device but didn't touched it for around two years. Was convinced that it was a software or serial port situation. In the end nothing more than the antenna coil wire broken beneath the enamel (at the coil side) and one other that I had fixed previously at the PCB side. Because I tested continuity from the PCB to the antenna terminals only at that time I didn't realized the second situation until returning to it this last week.

Bellow the device:

And the antenna coil details:

After that sorted it works receiving the DCF 77 transmiter time. It's just a little picky in the direction and placement since I'm currently on the actual range limits. I used "vocap" site for  the actual direction of the signal.

There is a long thread on this device (in German) here. Also has a link for the "RCCD" software if you don't have original DOS software diskette provided with the device, it also runs under "dosemu" in Linux:

A native build for Linux can be found here (thanks to Guntram). I tested under Linux Mint 32 Bit. Bellow the debug output.

In the format HHMMSS and then day of week date year (better visible on the source code).

For 64 Bit Linux Mint you will probably get when running the hopf binary: "No such file or directory" when running "./hopf -d /dev/ttyS0" , you need to install the following lib32 "sudo apt-get install lib32stdc++6"

Inside the box:

 

 

The main chip for the RF reception is marked U2900, I could not find the datasheet for it but did found one that could be similar in terms of connections, as far as I reverse engineering it; the U2775B :

 

 

..still not sure if the same or not. 

Anyhow, I'm happy that the device is confirmed working and will go now to the box of the finished stuff without immediate use...!

Have a nice day!