selbstbau:dino-thesen
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
selbstbau:dino-thesen [2024/11/02 18:08] – dh3dm | selbstbau:dino-thesen [2024/11/02 19:13] (aktuell) – Akronym-Bedeutung vereinheitlicht dh3dm | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== DINO-Thesen ======= | ||
+ | |||
+ | Mit dem folgenden Text möchte ich zum Nachdenken über ein Funkprojekt anregen. Dabei sind letztendlich viele Details zu klären und sinnvolle Lösungen zu finden. Dieser Text soll in einer ersten Phase zu einer Diskussion über den Sinn des Projekts anregen. Sollte sich dabei ergeben, dass eine Umsetzung sinnvoll wäre, dann hoffe ich, dass sich Personen mit passender Ausbildung/ | ||
+ | |||
+ | Errichtung einer Funknetzwerk-Infrastruktur mit folgenden Eigenschaften: | ||
+ | |||
+ | * Optimiert für Welfare-Traffic-Notfunk ("Wie geht es Oma? Ich brauche ein Medikament. Wo gibt es Wasser?). | ||
+ | * Relay-Prinzip: | ||
+ | * Das System muss für die Nutzer auch in " | ||
+ | * Preisgünstige Technik, damit sich das Viele leisten können. | ||
+ | * Stromsparende Technik, damit sie auch mit Notstrom möglichst lange einsatzfähig bleibt. | ||
+ | * Es soll hier KEIN Konzept entstehen, das rechtlich zweifelhaft ist. "Im Notfall ist das ja egal" ist kein akzeptables Argument! | ||
+ | |||
+ | Für mich resultieren die Anforderungen an so ein System in den unten folgenden Teilthesen. Selbstverständlich kann sich bei der Diskussion ergeben, dass ich falschen Ideen aufgesessen bin. Die Schwarmintelligenz möge zu einem optimalen Ergebnis kommen! | ||
+ | |||
+ | Arbeitstitel: | ||
+ | |||
+ | |||
+ | ===== Teilthese 1: Sprache oder digital? ===== | ||
+ | |||
+ | | Sprache | | ||
+ | |||
+ | **Vorteile: | ||
+ | |||
+ | * Kein zusätzliches Equipment nötig. | ||
+ | * Der Mensch kostet keinen Strom. | ||
+ | |||
+ | **Nachteile: | ||
+ | |||
+ | * Erfordert 100 Prozent Aufmerksamkeit beim Betrieb. | ||
+ | * Hohe Übertragungsfehlerrate. | ||
+ | * Kein durchgehender Betrieb möglich (schlafen, essen, pinkeln). | ||
+ | |||
+ | | Digital: | | ||
+ | |||
+ | **Vorteile: | ||
+ | |||
+ | * Keine Hörfehler, Möglichkeit der automatischen Fehlerkorrektur. | ||
+ | * Keine Ermüdung. | ||
+ | |||
+ | **Nachteile: | ||
+ | |||
+ | * Zusätzlicher Digitalteil (" | ||
+ | * Dieser verbraucht Strom zusätzlich zum Funkgerät. Das wird evtl. aber gegenüber Sprechfunk durch kürzere Sendephasen kompensiert (schnellere Übertragung ohne Rückfragen). | ||
+ | |||
+ | => Nur eine digitale Lösung macht Sinn. | ||
+ | |||
+ | ===== Teilthese 2: Möglichst viele Knoten ===== | ||
+ | |||
+ | Je mehr Knoten (= " | ||
+ | Benötigt wird also ein Konzept, das so " | ||
+ | Grundsätzliche Ansätze: | ||
+ | |||
+ | * LoRa, Zigbee: Gesetzlich begrenzter Duty-Cycle. Damit sehr geringer Datendurchsatz. | ||
+ | * PMR446: Es gibt nur Handfunkgeräte mit fest verbauter Antenne. Damit sind Stromversorgung und Reichweite suboptimal. | ||
+ | * CB-Funk mit angeschlossener DINO-Einheit: | ||
+ | * Digital-Amateurfunk auf KW mit angeschlossener DINO-Einheit: | ||
+ | * Digital-Amateurfunk auf UKW mit angeschlossener DINO-Einheit: | ||
+ | * Die Funkgeräte (Sendeempfänger, | ||
+ | |||
+ | => Ein System auf der Basis CB-Funk scheint optimal zu sein. | ||
+ | |||
+ | ===== Teilthese 3: Rechtliches ===== | ||
+ | |||
+ | Store-and-forward-Prinzip (s. o.) bedeutet, dass der Sender auch aktiv wird, wenn man selber keine eigene Mitteilung versenden will. | ||
+ | Es handelt sich also um eine automatische Station. | ||
+ | Im CB-Funk ist laut [[https:// | ||
+ | Im Amateurfunk sind automatische Stationen ebenfalls erlaubt. Beaufsichtigt (Betreiber am Gerät) sind derartige Stationen unproblematisch. Wenn man diese allerdings unbemannt betreiben möchte, ist Anmelde- und Kosten-Aufwand nötig. | ||
+ | |||
+ | => CB-Funk bietet den meisten Spielraum. | ||
+ | |||
+ | ===== Teilthese 4: Abstände zwischen den TRX ===== | ||
+ | |||
+ | Für Welfare-Traffic wäre es vermutlich optimal, weniger als 100 Personen pro TRX versorgen zu müssen. In der Stadt wären das wenige zig Meter pro TRX. | ||
+ | Auf dem Land wären das wenige km pro TRX. | ||
+ | Diese Dichten sind nicht erreichbar, da die Dichte der Funk-Aktiven (Funkamateure, | ||
+ | Wir werden also damit leben müssen, dass jeder Notfunkknoten mehr Personen versorgen muss. | ||
+ | Wenn viele Funk-Aktive bei diesem Funknetz mitmachen, ist die zu überbrückende Strecke zwischen den einzelnen TRX ähnlich der typischen Entfernung der Funk-Aktiven zueinander. | ||
+ | |||
+ | => Geschätzte zu überbrückende Entfernung in der Stadt ca. 3 km und auf dem Land ca. 20 km. | ||
+ | |||
+ | ===== Teilthese 5: Sinnvolle Frequenzen ===== | ||
+ | |||
+ | Die nötigen Reichweiten in der Stadt und auf dem Land sind im 2-m-, 10-m- und 11-m-Band erreichbar. | ||
+ | |||
+ | ===== Teilthese 6: TRX-Typ ===== | ||
+ | |||
+ | Für die zu überbrückende Entfernung ist wenig Sendeleistung erforderlich. | ||
+ | In einer Notfunksituation ist Strom Mangelware. Ein TRX mit geringer Sendeleistung und entsprechend geringem Stromverbrauch ist sinnvoll. | ||
+ | Der TRX muss leicht durch den Digitalteil (" | ||
+ | |||
+ | * CB-Funk: Stromökonomisches Mobilgerät einsetzen. SSB-CB-Geräte sind wesentlich teurer als AM/ | ||
+ | * Amateurfunk: | ||
+ | |||
+ | Hinweis: Wenn zweigleisig (CB-Funk und Amateurfunk) gefahren wird, dann dürfte eine Kopplung zwischen den Netzen rechtswidrig sein. Daher scheint es sinnvoll, das Netz schwerpunktmäßig auf CB-Funk-Basis aufzubauen und Amateurfunk lediglich als Option zu sehen. | ||
+ | |||
+ | ===== Teilthese 7: DINO-Einheit: | ||
+ | |||
+ | Der Knoten muss ohne externen Computer zu betreiben sein, da dieser viel Strom verbrauchen würde. Hiermit scheiden WinLink, VARA, PAM, etc. aus. | ||
+ | Wenn das Handling der Modulation einfach ist oder dieses auf einen dafür optimierten Sub-Prozessor ausgelagert werden kann, dann reicht geringe Rechenleistung für I/O in Richtung TRX und Anwender. Geringer Stromverbrauch ist ist die Designmaxime. Weiterhin sollte das Routing (s. u.) so einfach gestaltet werden, dass dieses durch wenig Programmcode realisierbar ist. | ||
+ | Damit scheint ein einfacher Microcontroller (Raspberry Pico/ | ||
+ | Für einfachen Nachbau wäre es gut, wenn der Prozessor im DIP-Format verfügbar wäre. | ||
+ | Für zwischengespeicherte Mitteilungen und Routing-Informationen ist deutlich mehr RAM nötig, als in kleinen Mikrocontrollern verfügbar ist. Unter den drei Architekturen ist der Raspberry Pico diesbezüglich herausragend. | ||
+ | |||
+ | => Raspberry Pico. | ||
+ | |||
+ | ===== Teilthese 8: Modulation ===== | ||
+ | |||
+ | Bei den erforderlichen Reichweiten sollte das Signal-Rausch-Verhältnis (SNR) unproblematisch sein. Es kann daher eine Modulation für störungsarme Kanäle verwendet werden, die leicht in Hardware zu realisieren ist und guten Datendurchsatz ermöglicht. | ||
+ | MFSK dürfte ein guter Kompromiss sein. Wenn wenige Frequenzen verwendet werden, dann könnten Tonerzeugung und Filter als Hardware (OpAmps) ausgeführt werden. Damit muss sich der Prozessor nicht um die (De-)Modulation kümmern (spart viel Coding und Rechenleistung). | ||
+ | Beispiel (einfacher MFSK-Modulationsansatz): | ||
+ | |||
+ | * Töne auf 4 Frequenzen (also 4 HW-Einheiten für Modulation/ | ||
+ | * Damit pro Phase 4 Bits übertragbar, | ||
+ | * Bei einer angenommenen Phasendauer von 0,05 s > 10 Byte/s. | ||
+ | * Damit für ein Telegramm (von, an, TTL, "Dies ist ein Test." | ||
+ | |||
+ | => AMFSK; Toneinspeisung/ | ||
+ | |||
+ | ===== Teilthese 9: Protokoll ===== | ||
+ | |||
+ | Die Fehlerhäufigkeit dürfte gering sein (s. o.). Damit wäre ein einfaches geschwindigkeitsoptimiertes Protokoll für störungsarme Übertragungskanäle sinnvoll. Dies würde auch Coding sparen. | ||
+ | |||
+ | => Einfaches ACK-/ | ||
+ | |||
+ | ===== Teilthese 10: Routing ===== | ||
+ | |||
+ | Es wird definitiv ein Verfahren ohne zentralen Server - ein echtes self-healing Mesh - benötigt. | ||
+ | Multi-Hop und TTL sind nötig. | ||
+ | Das Routing sollte kurze Nachrichten bevorzugen (" | ||
+ | Die Knoten sind größtenteils stationär, daher könnten die Stations-IDs aus Locator und darin laufender Nummer gebildet werden, z. B. JO42XB-4. Die in der ID enthaltene Position kann beim Routing hilfreich sein. | ||
+ | Für jeden DINO-Knoten eine entsprechende einmalige ID-Vergabe: Zentrale Stelle einrichten (einfach jemand, der eine Tabelle pflegt). | ||
+ | Bei einem Ziel mit " | ||
+ | |||
+ | => Routing-Eigenentwicklung oder etwas Existierendes anpassen? | ||
+ | |||
+ | ===== Teilthese 11: Benutzerschnittstelle, | ||
+ | |||
+ | |||
+ | * Stromsparendes LCD. Ein günstiges 4x20 LCD dürfte eine stromsparende Anzeige sein. Nutzung: | ||
+ | * Für den Text während der Eingabe einer Mitteilung. | ||
+ | * Lesen eingegangener Mitteilungen. | ||
+ | * Während des reinen Routings: Anzeige des Betriebsstatus. {{selbstbau: | ||
+ | * Als Tastatur wäre eine übliche USB-Computertastatur praktisch. | ||
+ | * Anschluss an Mikrofon- und Lautsprecheranschluss des TRX. | ||
+ | * Stromversorgungseingang für ca. 12 V, geschützt gegen Verpolung und Überspannung. | ||
+ | * Selbsttest-Funktionen, | ||
+ | * Gelayoutete günstige PCBway-10x10-Platine für einfachen Nachbau. | ||
+ | * Fertig von Freiwilligen programmierter Prozessor, alternativ kann der Interessent den Prozessor auch selbst mit dem Code versehen (Code ist offen/ | ||
+ | |||
+ | => Box mit LCD, Anschluss für Computertastatur, | ||
+ | |||
+ | {{selbstbau: | ||
+ | |||
+ | ===== Teilthese 12: Stromversorgung ===== | ||
+ | |||
+ | Ein Notfunkknoten ohne Notstrom ist im Ernstfall außer Betrieb. | ||
+ | Einen gasdichten Akku kann man problemlos beim Funkgerät im Wohnraum aufstellen. Dieser muss aber automatisch geladen werden/ | ||
+ | Es erscheint zweckmäßig, | ||
+ | Gut wären zwei Ladekanäle (230-V-Netz, | ||
+ | |||
+ | => Ladeschaltung in DINO-Einheit integrieren. | ||