Well as you know the bands have been fairly poor so I have no stories to share with you about “Rare DX” and even my Parks on The Air (POTA) activities have been less than usual.

A while back I did post about the “New” Xiegu X6200 and how it looked impressive “on paper” and was waiting to get more info before making any opinions (good or bad) on the unit.

Here is a link to that post.

Above picture from Xiegu website.

Well the X6200 is now available for sale and from some actual dealers rather than the usual Chinese companies…

The information I comment on today is from the Waters & Stanton website who are selling the unit in the UK….

The prices I quote are from their website including their estimation of Duties and Taxes in Canadian $$$.

The price of the radio is 795.00 in Pound Sterling and from there the websites calculates the following…

So if you take in the above sub totals it looks like the converted price of the radio is $1389.70 (CDN) then you add the Duties and taxes of $226.73 (CDN) giving a total of $1616.43 (CDN)

But remember the disclaimer from above:

The estimated duties and taxes are based on CA$1,389.70 of product and may fluctuate due to changes in currencies, shipping costs, clearance fees or how the items are classified by customs. Duties and taxes may be collected upon delivery of the items.

So at this point I am guessing (yes guessing) that the retail North American Price will be fairly close to the above price in the range of $1600 -$1700 (CDN) but remember that is my “Best Guess”.

From what I can see of the details of the 6100 they will be in competition with the ICOM IC705 and the ELECRAFT KX3.

Lets see the reviews that should be available on YouTube very soon and then make your decisions from there.

If it is as good as it seems… It still could be a contender in the upper end of the QRP rigs.

73bob

Disclaimer: This post is me thinking out loud. I am not recommending or endorsing any of the products listed above. I believe that you if you are thinking of purchasing one…. That you should do all your research and draw your own conclusions before you buy one from whatever source you choose.

Its all up to you.

Looking only at the content of this blog you might think there was not much going on here recently.  That is true to a degree.  I was working 160m pretty regularly late last year and recently I've managed to get on the 17m and 30m bands enough to confirm DXCC on both.  That just leaves 12m and 160m to complete 9-Band DXCC.  I still need 9 more all-time-new-ones on any band to make DXCC Honor Roll but that's just a waiting game.  Only the much-cursed Burundi is not at the top of the most-wanted list but still not confirmed in my log.  It will likely be years before the rest of the rarest-of-the-rare are ever on the air at all.  The time has come, however, to make some big changes.

Somewhat by design and some by coincidence, I have always changed things up along with the progress of the 11-year solar cycle.  I built my first high-performance HF station for contesting and DXing back in 2013 at the beginning of Cycle 24.  As the cycle began to wane in 2017 I optimized the station for working the lower HF bands and I cruised through the sunspot minimum over the past few years without skipping a beat, earning the 5-Band DXCC award and DXCC Challenge.  Now that the sun is starting to awaken again it is time to make changes.

I've been dreaming of building a 2m EME station for 25 years now.  I've built huge imaginary antenna arrays in my head and even started building a tube-type VHF kilowatt amplifier once (it was a fail).  Back in 2015 I started to get more serious about the whole idea.  I completed the hardware and software for the azimuth/elevation tracking equipment.  I found W6PQL's web page and started planning for a solid-state LDMOS amplifier.  Most importantly, I started collecting all the little bits and pieces that I would need to put everything together.  I found a 2000W 50V power supply on eBay for $30.  I scavenged coaxial relays, hardline cable and connectors, aluminum tubing and rod for antennas, and a huge assortment of other odds-and-ends that will all have their place in the final product.  I'm even planning to repurpose the 50W UHF amplifier module that I build a few years ago.

For HF I had wanted to put up my DMX tower and the TH6DXX again but concluded that a more sensible option would be a smaller tower with a 10/12m duoband yagi (built from old TH3JRS parts) and a re-worked 6m yagi.  I really hadn't given too much thought to six meters but then I had a good idea for a small linear amplifier to use on that band and with the optimized yagi it should be good for making EME contacts on the horizon (at least with the "big guns") and working the infrequent band openings, possibly even over the north pole.

In the past my plans had always included my venerable Kenwood TS-2000.  It was the only radio I owned with VHF/UHF capabilities but it had long ago succumbed to the endemic TS-2000 filters failure, ostensibly caused by overheating the ceramic filters when production first changed to lead-free solder.  A couple of years ago however, I was considering a new radio to put in my boat and came across the first information about the then-unreleased Icom IC-705.  It was only a 10 watt QRP radio but I thought that maybe with some outboard amplifiers it might be okay for marine use.  The more I thought about that the more I realized that I'd rather have the IC-705 in the shack and just fix the old Kenwood to use in the boat.  I already had an HF amplifier that only required 50mW drive power and a VHF LDMOS amplifier would likewise require only a few watts of drive.  The 705 also boasted an astonishing array of features like a direct-sampling DSP receiver, touch screen, bluetooth, GPS, DStar, and on and on and on.  The only thing it lacked was full-duplex cross-band receive which I required for working satellites.  That was easily fixed by including a dedicated SDR receiver in my plans.  The FunCube Dongle Pro+ that I already had would work perfectly for this.

Over the past few months I got more serious about getting this all done THIS YEAR.  I relentlessly completed all the detailed design drawings for the controls, feedlines, and antennas.  The concept is a simplified design that will make everything happen with the flexibility to work HF and 6m, satellite, and 2m EME, provide high performance and low-loss, while also protecting the expensive amplifier components.  After innumerable iterations and revisions, all the details have now been finalized and I have almost completed obtaining all the remaining parts required to make everything happen.  Only the IC-705 is waiting to join the party.

For about two years, K1IR has been home for a ham radio repeater. It’s part of the NEDECN DMR network. The repeater is on the 2 meter band and is accessible with these settings:

• Callsign: K1IR
• Frequency: 146.47000MHz
• Offset: -1.5MHz
• ColorCode: 0

The Challenge

The coverage area for the repeater has not been the best. That’s because we have been using a two-antenna system. The receive antenna is a Diamond vertical located at about 105 feet on top of the tower. That antenna works quite well. But, we’ve been using a second antenna only about 30 feet above ground level for transmitting. This antenna, another Diamond vertical, simply doesn’t perform very well at this low height. The result has been a very unbalanced coverage area for the repeater. Not very attractive to potential users. We needed to make a change.

Our first effort to improve the coverage was to put up a new vertical at about 70 feet on the tower. But, that project was never completed because getting a second low-loss feedline in place to feed that antenna proved quite difficult.

Adding a Duplexer – A Real Solution

Using a duplexer is another way to solve this problem. What is a duplexer? It’s a three-port device where the feedline to the antenna is connected to one port, a second is connected to the repeater receiver input, and the third is connected to the transmitter. The duplexer creates two low insertion-loss paths that have extremely high isolation from each other.

• Antenna port to receiver port
• Transmitter port to antenna port

The duplexer that has some great advantages. It allows you to use the same coaxial feedline and antenna for both transmitting and receiving, with no compromise in performance.

To achieve these high-Q curves and deep isolation nulls, the long-proven approach is to build filters with resonant cavities. These cavities must be carefully tuned with specialized test equipment.

Duplexers are fairly expensive – and not in the K1IR repeater budget! But, they do become available on occasion as repeaters are upgraded or decommissioned. So, I put the word out to my network to be on the lookout for a surplus duplexer. That was at least a year ago.

About a month ago, long-time friend, Dom Mallozzi N1DM, told me he might just have a lead on a VHF duplexer coming out of service following a repeater upgrade in a public safety application. The frequencies for VHF public safety are close to the 2 meter band, so retuning would work just fine. That duplexer – a Sinclair Q201 – was made available as surplus just this week, so Dom got his hands on it as quickly as possible and we did the installation this morning.

Assembly and Tuning

Tuning is easy when you have the right gear. And, Dom came fully equipped. He pulled out his Rigol DA815-TG Spectrum Analyzer with built-in tracking generator. It didn’t take more than a few minutes to ensure that the tuning was within spec on the new frequencies.

With the cavities pre-tuned, we built up a couple of cables and connected the duplexer in line with the repeater and antenna, and started our final testing.

Initial tests showed low power output from the repeater. With a little micro-adjustment of one cavity on the transmitter side, power came up to exactly what it should be – and we were in business!

Coverage Testing – It’s a Big Win!

Final testing was a coverage area test. Dom packed up his stuff and headed south back towards his home QTH in Natick. I got my HT setup in the car, connected to a trunk lip mounted 5/8 wavelength whip. As we drove in opposite directions, it quickly became clear that coverage was greatly improved.

Again . . . huge thank you to Dom Mallozzi for finding and making the duplexer available and for his skills in getting it running on the Sudbury, MA 146.47 DMR machine.

The post K1IR Repeater Upgrade – Major Coverage Improvement! appeared first on The Driven Element.

Beim Vernetzen von Computern via Funk kann sich die Anzahl und Auswahl der direkt erreichbaren Gegenstellen im Verlaufe der Zeit ändern: Neue Knoten können hinzukommen, bestehende entfallen oder vorübergehend unerreichbar sein. Zeitgemäße Netzwerk-Protokolle, z.B. das Internet-Protokoll (IP), in Verbindung mit geeigneten Routing-Protokollen, z.B. Babel, können die Erreichbarkeit aller Knotenpunkte eines vermaschten Funknetzes (und ggf. weiterer angeschlossener Teilnetze) ermöglichen.

Insbesondere für uns Funkamateure ist ein solcher Ansatz deshalb interessant, weil einige Stationen nicht dauerhaft zur Verfügung stehen (z.B. weil sie nur besetzt betrieben werden), sich die Anzahl von Knotenpunkten jederzeit ändern kann und Überreichweiten oder experimentelle Aufbauten bestimmte Teilnetze verbinden könnten, die ansonsten isoliert voneinander sind.

In diesem Artikel möchte ich einen Lösungsansatz zur IP-Adressvergabe und Vernetzung via IP-Routing vorstellen, der

• keine zentrale Planungsstelle benötigt,
• auf dem existierenden IPv6-Standard aufsetzt bzw. mit dem in Standardisierung befindlichen Babel-Protokoll arbeitet,
• Open-Source-Software verwendet, die derzeit unter den Betriebssystemen Linux und FreeBSD verfügbar ist,
• die Eigenarten des Mediums „Funk“ berücksichtigt und
• einfach einzurichten ist.

Die das Netz aufspannenden Stationen sind hierbei in einem vermaschten Netzwerk (Mesh-Netz) miteinander verbunden. Wie die dazu notwendigen Direktverbindungen aufgebaut werden können, soll nicht Teil dieses Artikels sein, wird jedoch z.B. von DL1PZ in einem anderen Beitrag behandelt. Stattdessen beschäftige ich mich hier mit der Einrichtung des Routings, so dass eine Funkstation A, die Kontakt mit einer Funkstation B hat, auch die Funkstation C erreichen kann, falls die Stationen B und C eine Verbindung haben. Auch eine Weiterleitung über mehr als eine Zwischenstation (genannt: „Hop“) ist so möglich.

Dezentrale IP-Adressvergabe

In einem IP-Netzwerk werden die Teilnehmer mittels sogenannter IP-Adressen angesprochen. Im Falle von IPv4, der älteren Version des Internet-Protokolls, sind dies vier Zahlen von 0 bis 255 getrennt durch Punkte, also z.B. „10.169.145.125“. Bei IPv6 kommen längere Adressen zum Einsatz, die in hexadezimaler Schreibweise notiert werden, z.B. „fdb7:5c3c:1e90:e4c1:0000:0000:00d5:85ed“. Die Punkte bzw. Doppelpunkte dienen nur der Lesbarkeit bei Darstellung in Textform und werden bei einer binären Übertragung nicht mitgesendet. Zur Vereinfachung besteht bei IPv6 die Möglichkeit, mittels eines doppelten Doppelpunktes „::“ die Auslassung mehrerer 0000-Blöcke zu kennzeichnen. Außerdem ist es möglich, führende Nullen innerhalb eines Vier-Zeichen-Blockes wegzulassen, so dass vorstehende Adresse auch verkürzt als „fdb7:5c3c:1e90:e4c1::d5:85ed“ geschrieben werden könnte.

Um eine zentrale Adressvergabe zu vermeiden, aber gleichzeitig jedem Teilnetz (einschließlich vorübergehend isolierter Netze) permanente Adressen zuweisen zu können, die dennoch mit hoher Wahrscheinlichkeit im Rahmen des Einsatzzweckes eindeutig sind, wird IPv6 genutzt. IPv6 ermöglicht es aufgrund der vergleichsweise langen Adressen, einfach einen zufälligen Adressbereich zu wählen, der dann mit großer Wahrscheinlichkeit eindeutig ist. Genau dies ist bei IPv6 im Rahmen der sogenannten „Unique Local Addresses“ (ULA) auch vorgesehen: Jede Person oder Organisation, die einen Adressbereich benötigt, erzeugt einfach eine 40 Bit lange Zufallsfolge. Wird dieser noch die Bitfolge 11111101 (hexadezimal „fd“) vorangestellt, ergeben sich 48 Bit, die den sogenannten „Präfix“ für den Adressbereich bilden. Die Person bzw. Organisation, die sich diesen Adressbereich zufällig ausgesucht hat, kann nun alle damit beginnenden Adressen beliebig verwenden, ohne große Gefahr zu laufen, mit den Adressen zu kollidieren, die andere Personen oder Organisationen verwenden. Ein solcher Präfix wird z.B. als fd4a:eeb2:7cea::/48 notiert, wobei 48 die Präfixlänge in Bits in dezimaler Schreibweise darstellt.

Die Wahrscheinlichkeit einer Kollision, d.h. die Wahrscheinlichkeit, dass in einem Netzwerk der gleiche Präfix zweimal vergeben wird, steigt zwar vergleichsweise schnell mit der Anzahl der vergebenen Präfixe (vgl. Geburtstagsparadoxon), allerdings beträgt z.B. bei 10.000 solcher miteinander vernetzten Präfixe die Kollisionswahrscheinlichkeit aufgrund der vielen Möglichkeiten (2 hoch 40 = 1.099.511.627.776) immer noch weniger als 0,05 Promille, also etwa 1:20.000. Verglichen mit anderen potentiellen Störungsursachen scheint dies vernachlässigbar klein zu sein. Die Berechnungsformeln für die Kollisionswahrscheinlichkeit sind identisch mit denen der sogenannten Geburtstagsangriffe, wobei wir hier vom wohlwollenden Verhalten aller Teilnehmer ausgehen.

Sobald ein 48-Bit langer IPv6-Adress-Präfix per Zufall ermittelt wurde, können, wie zuvor erwähnt, aus dem sich ergebenden Bereich beliebige IP-Adressen gewählt werden, z.B. die Adresse

fd4a:eeb2:7cea:0000:0000:0000:0000:0001

welche in verkürzter Schreibweise als fd4a:eeb2:7cea::1 geschrieben werden kann. Auch ist es möglich ganze Netzbereiche unterzuverteilen.

Unter Linux lässt sich dann beispielsweise diese Adresse einem Funk-Interface (hier im Beispiel tun0) wie folgt zuweisen:

ip -6 addr add fd4a:eeb2:7cea::1/128 dev tun0

Die 128 steht hierbei für eine Präfixlänge von 128 Bit, d.h. wir teilen dem Betriebssystem mit, dass zunächst keine andere Adresse via Funk erreichbar ist. Welche anderen Adressen wir tatsächlich erreichen können, wird dem Betriebssystem vom Routing-Dienst mitgeteilt, der im Folgenden beschrieben werden soll.

Der Routing-Dienst „babeld“

Sofern die Installation von „babeld“ in aktueller Version nicht durch das Paketmanagement des Betriebssystems erfolgen kann, finden sich Hinweise zum Download der Software auf der Homepage des Babel-Projektes.

Die folgenden Beschreibungen beziehen sich auf die zum Zeitpunkt der Veröffentlichung dieses Artikels aktuelle Version 1.9.2 der Software. Es gibt auch andere Routing-Software, z.B. BIRD, die das Babel-Protokoll ebenfalls umsetzen kann. Diese sollte ebenso eingesetzt werden können, ist aber anders zu konfigurieren.

Die Einrichtung von „babeld“ gestaltet sich sehr einfach. Wir legen dazu die Konfigurationsdatei /etc/babeld.conf an. Für den Fall, dass wir unseren Präfix wie im vorhergehenden Abschnitt als fd4a:eeb2:7cea::/48 festgelegt hätten (in der Praxis muss dies natürlich ein eigener, zufälliger Präfix sein), sähe die Datei wie folgt aus:

in ip fd00::/8 allow
in deny
out ip fd00::/8 allow
out deny
redistribute ip fd4a:eeb2:7cea::/48 local
redistribute ip fd4a:eeb2:7cea::/48 metric 256
redistribute local deny
redistribute deny

Den Routing-Dienst können wir dann z.B. mit folgendem Kommando starten:

babeld -c /etc/babeld.conf wl3sp0

Hierbei wäre wl3sp0 das Funk-Interface, mit dem die Vernetzung erfolgt. (Mit „ip link show“ lassen sich alle verfügbaren Interfaces anzeigen.) Wird, wie in diesem Beispiel, ein WLAN-Interface (wl3sp0) verwendet, kann babeld anhand der Hardwarekonfiguration selbst erkennen, dass eine Funkverbindung vorliegt. Wird stattdessen eine Vernetzung mittels einer schmalbandigen Verbindung über ein herkömmliches Funkgerät vorgenommen, kommt oft ein generischer TUN-Gerätetreiber zum Einsatz, bei dem die automatische Erkennung nicht möglich ist. Hier sollten wir nachhelfen, z.B. mit:

babeld -c /etc/babeld.conf -C "interface tun0 type wireless channel interfering hello-interval 60"

So sagen wir dem Routing-Dienst, dass es sich bei der verwendeten Netzwerkschnittstelle um eine Funkverbindung handelt („type wireless“), die sich ggf. mit anderen Funkverbindungen einen Kanal teilt („channel interfering“) und das Kommunikationsintervall für eine schonendere Bandbelegung reduziert wird („hello-interval 60“). Anstelle der Option „-C“ lässt sich der auf diese Option folgende Text („interface tun0 […]“) auch als eigene Zeile in die Konfigurationsdatei schreiben. (Details hierzu in der Anleitung von babeld.)

Falls wir Pakete für andere Funkknoten weiterleiten wollen (was ja Sinn und Zweck eines Mesh-Netzes ist), müssen wir unserem Betriebssystem noch mitteilen, dass Packet-Forwarding (also Routing) aktiviert werden soll. Dies lässt sich z.B. für IPv6 unter Linux bis zum nächsten Neustart mit folgendem Kommando einschalten:

sysctl -w net.ipv6.conf.all.forwarding=1

Soll Packet-Forwarding dauerhaft aktiviert bleiben, so ist die Datei /etc/sysctl.conf entsprechend zu bearbeiten.

Sicherheitsbedenken

Sobald wir Routing auf unserem Computer aktivieren, wird dieser beliebige Pakete weiterleiten. Es wäre dann also auch möglich, via Amateurfunk auf ein ebenfalls angeschlossenes privates Heim- oder Firmennetz (oder das Internet) zuzugreifen, was in der Regel nicht erwünscht sein wird. In einem solchen Fall ist also unbedingt eine Firewall einzurichten, deren Konfiguration hier nicht weiter behandelt werden soll und vom konkreten Szenario abhängt.

Ebenso sollte verhindert werden, dass der Routing-Dienst über Funk Einträge für unser privates Netz akzeptiert. Liegt unser privates Netz außerhalb des ULA-Adressbereiches (beginnt also nicht mit hexadezimal „fd“), dann sorgt die oben vorgestellte Konfiguration bereits automatisch dafür, dass entsprechende Routing-Informationen abgelehnt werden. Verwenden wir bei unserem privaten Heim- oder Firmennetz jedoch ebenfalls ULAs, dann müssen wir dem Routing-Dienst noch mitteilen, dass für diese Adressen keine Informationen aus dem Funknetz angenommen werden sollen. Dies lässt sich, z.B. wenn fdf2:c215:20a4::/48 unser privates Netz sei, mit der Zeile

in ip fdf2:c215:20a4::/48 deny

an oberster Stelle in der /etc/babeld.conf erreichen.

Einen zusätzlichen Filter für die ausgehende Richtung benötigen wir nicht. Wir haben bereits vermerkt, für welche Netzwerke wir Routing-Informationen einspeisen wollen („redistribute ip fd4a:eeb2:7cea::/48 […]“). Für alle anderen Netzwerke haben wir festgelegt, dass diese von babeld nicht eingespeist werden („redistribute local deny“ und „redistribute deny“).

Anbindung von weiteren angeschlossenen Geräten über den selben Funkknoten

Der Zugriff auf bestimmte lokale IP-Adressbereiche kann aber durchaus auch erwünscht sein, denn vielleicht möchten wir nicht nur ein einzelnes Gerät an das Funknetz anbinden, sondern ein ganzes Netzwerk. Die bereits erwähnte Konfigurationszeile „redistribute ip […] metric 256“ (ohne die Option „local“) ermöglicht die Einspeisung von IP-Adressen, die nicht dem eigenen Endgerät, sondern anderen Endgeräten zugehörig sind.

Die Zahl 256 gibt hier die sogenannte Metrik an, die ein Maß für die Güte der Anbindung eines Netzwerks ist. Dieser Wert ist dann von Bedeutung, wenn ein Netzwerk auf verschiedenen Wegen erreichbar ist, z.B. weil es mit mehreren Funkknoten direkt verbunden wird. Dann kann bei jedem dieser Funkknoten ein unterschiedlicher Wert für dieses Netzwerk festgelegt werden, wobei ein niedrigerer Wert für eine höhere Güte der Anbindung steht. In einfachen Fällen, also bei Netzwerken ohne Mehrfachanbindung, können wir einfach 256 festlegen.

Für die lokale Vernetzung können wir nun einen Unterbereich des Adressraumes ausweisen, z.B. fd4a:eeb2:7cea:5555::/64. Unserem eigenen Netzwerk-Interface (also z.B. unserer Netzwerkkarte) weisen wir eine IP aus diesem Unteradressraum zu und geben mit der Präfixlänge /64 an, dass weitere Adressen aus dem gleichen Unteradressraum (beginnend mit den 64 Bits fd4a:eeb2:7cea:5555) direkt zu erreichen sind. Heißt unser Netzwerk-Interface für kabelgebundenes Ethernet z.B. „enp0s25“, so wäre das Kommando hierfür:

ip -6 addr add fd4a:eeb2:7cea:5555::1/64 dev enp0s25

Andere Geräte am gleichen Ethernet-Segment können dann z.B. die Adressen mit der 2, 3, 4 usw. am Ende zugewiesen bekommen, also z.B. die fd4a:eeb2:7cea:5555::4, und sind dann aus dem Funk-Mesh-Netz erreichbar. Diesen Geräten muss jetzt nur noch mitgeteilt werden, dass Pakete an fd00::/8 (also Adressen beginnend mit „fd“) über unseren Funkknoten mit der IP fd4a:eeb2:7cea:5555::1 geroutet werden müssen, sofern für diese keine andere Route existiert. Hierzu ist das Routing der Geräte entsprechend einzustellen oder ggf. eine Default-Route zu setzen. Wie dies funktioniert, hängt vom Betriebssystem des jeweiligen Endgerätes ab. Auch ließe sich ein DHCPv6-Server verwenden, dessen Konfiguration jedoch den Rahmen dieses Artikels sprengen würde.

IPv6 und die Paketgröße (MTU)

Leider sieht IPv6 vor, dass auf jeder Verbindung mindestens Pakete der Größe 1280 Byte übertragen werden können. Dies ist die minimal mögliche Einstellung der sogenannten „Maximum Transmission Unit“ (MTU). Eine Fragmentierung, d.h. Aufteilung in kleinere Pakete, ist durch Router auf dem Transportweg bei IPv6 im Gegensatz zu IPv4 nicht vorgesehen (siehe RFC 8200, Sektion 5). Das kann zu Schwierigkeiten z.B. bei bestimmten Hardware-TNCs führen, die Pakete dieser Größe nicht handhaben können. Umgehen ließe sich dieses Problem mit einer zusätzlichen Fragmentierungsschicht, die aus Sicht von IPv6 unsichtbar sein müsste. Die von DL1PZ vorgestellten Programme ermöglichen keine zusätzliche Fragmentierung, jedoch sind die dort vorgestellten Software-TNCs Dire Wolf und pktfec-tnc ohne Probleme in der Lage, größere Pakete auf’s Band zu senden.

Skalierbarkeit

Da jeder Knoten in regelmäßigen Abständen Informationen zu allen erreichbaren Adressbereichen mit allen direkten Nachbarknoten austauschen muss, skaliert das hier vorgestellte Verfahren nicht beliebig. Mit wachsender Knotenanzahl wird die Menge an zu übertragenden Informationen ebenfalls wachsen. Bei langsamen Packet-Radio-Verbindungen dürften bereits bei einer zweistelligen Anzahl von Netzknoten Probleme auftreten. Weniger problematisch wäre dies bei einer Vernetzung mit schnellerer Technik.

Um dieses Problem zu lösen bzw. zu umgehen, sehe ich verschiedene Alternativen:

• Mesh-Netze bleiben lokal begrenzt und werden mit anderen Mesh-Netzen ausschließlich manuell verbunden. Routing-Informationen zu anderen Mesh-Netzen werden nur für das gesamte jeweils andere Mesh-Netz in das eigene Mesh-Netz eingespeist, so dass jedes andere Mesh-Netz nur mit einem einzigen Präfix in den Routing-Tabellen auftaucht, was die Routing-Tabellen kleiner hält. Damit dies funktioniert, müssten die einzelnen lokalen Mesh-Netze jedoch jeweils einen gemeinsamen Präfix verwenden und sich dann auf eine Vergabemethode von IP-Adressen innerhalb ihres jeweiligen Präfixes einigen.
• Mesh-Netze bleiben lokal begrenzt und werden untereinander über sogenannte Border-Router und ein Backbone verbunden. Routing-Informationen zu anderen Mesh-Netzen werden gar nicht im eigenen Mesh-Netz verbreitet. Stattdessen werden die Border-Router als zuständig für den Bereich fd00::/8 angegeben.
• Das Routing-Protokoll wird erweitert (bei Babel grundsätzlich vorgesehen), oder ein anderes, zukünftiges Routing-Protokoll wird benutzt, das solche Szenarien noch besser abbilden kann.

Fazit und Ausblick

Es macht Spaß, mit Ad-hoc-Vernetzung zu experimentieren. IPv6 ermöglicht es, ohne zentrale Koordinierung feste IP-Adressen zu verwenden. Mit dem Routing-Protokoll Babel bzw. der Software „babeld“ und IP-Packet-Forwarding können wir eine automatische Vernetzung vornehmen lassen. Inwieweit sich diese Verfahren im größeren Maßstab in der Praxis, insbesondere bei langsamen Packet-Radio-Verbindungen, einsetzen lassen, bleibt zu erforschen.

Many thanks to Rusty Epps W6OAT and the senior leadership of the WWDXC for inviting me to present on the important topic of tower safety. I presented to the group via Zoom at it’s on-line August meeting on Tuesday, August 11, 2020.

Following the presentation, I received this note:

Tnx again for a magnificent presentation to WWDXC. Folks stayed on line for almost another hour, discussing and sharing horror stories. YOU WOKE US ALL UP!

Stay vigilant; learn what you need to know to be safe . . . and spread the word. Visit zerofalls.org for more information.

The post Amateur Radio Tower Safety – Western Washington DX Club appeared first on The Driven Element.

Coronavirus is driving change across everything we do. With it’s April 2020 meeting The Northern Illinois DX Association (NIDXA) went to an online meeting format for the first time in its history. I did the keynote presentation from my home QTH in Massachusetts this past Friday evening April 10, 2020.

We used Zoom, the videoconferencing application that’s taken off in a big way as a result of mandatory social distancing and travel restrictions. As we kicked off the presentation, we took advantage of one of the in-built tools that Zoom offers – polling – to learn a little bit about the audience. Of the nearly 50 participants, we found that all but three – almost 95% – have some kind of regular interaction with amateur radio tower work. Clearly, this was an audience that should care about the topic.

The best indication of whether an online presentation has been successful may be the percent of participants who remain at the end of the talk . . . in this case, we had nearly 100% staying on to the end. It was also a pleasure to receive a few private emails after the meeting expressing appreciation for the information provided. We even got one email asking for an immediate purchase of one of the climbing kits.

The post Amateur Radio Tower Safety – Northern Illinois DX Association (NIDXA) appeared first on The Driven Element.

A nationwide 5G cellular network is being built out now. The major network infrastructure owners and operators are taking this seriously. As they build up a force of expert tower installers and maintainers, they are committed to safety. Tower climbing can be risky – or it can be safe. The pros know how to make it safe – proper equipment and training are core requirements. Every ham who wants to work with antennas and towers should be paying attention.

The post CBS Reports: What Can Hams Learn from the Expanding Commercial Tower Industry? appeared first on The Driven Element.

In a previous post, I told you about the fun, no-jargon ham radio interview we did with Bradley Jay on Boston-based clear channel station WBZ. It was a basic amateur radio introduction.

During the short time we had to prepare for the show, we planned extensively in collaboration with the show’s producer. At one point, I asked if we could liven up the hour with some audio clips to allow listeners to really experience the sounds of amateur radio. “Sure!”, she said.

We assembled a set of clips that represent a broad range of amateur radio pursuits. But, just two hours before air time, our producer emailed me to say that Bradley didn’t want to use the clips. Ugh!

We were disheartened because we think we really captured sounds that effectively convey the wide range of on-the-air ham radio experiences.

Let’s not allow these clips go to waste!

WBZ and their listening audience did not get to hear these little gems. But, their loss need not be yours, too! Here are the clips we had all ready to go. They’re all pretty short. Enjoy. Don’t miss the last one – contact with the International Space Station.

The post Listen to the Audio Clips WBZ Rejected! appeared first on The Driven Element.

Ham radio got a nationwide boost from Boston-based clear channel station WBZ. Tom Walsh, K1TW, our Eastern Massachusetts ARRL Section Manager contacted me to see if I could help satisfy a short-term request from Jay Talking a WBZ talk show hosted by veteran radio personality Bradley Jay. How could I refuse?

I partnered with Bruce Tinkler N9JBT to fill the hour with some great content. We wanted to convey a broad view of ham radio that captures both its historic roots and current advanced technology and relevance to modern-day STEM initiatives. Cameo appearance by Marty Sullaway NN1C!

How did we do?

The post Ham Radio on WBZ! appeared first on The Driven Element.