Thesen zu einem Notfunknetz

Benutzeravatar
Detlef (DH3DM)
Nicht mehr ganz frisch
Nicht mehr ganz frisch
Beiträge: 29
Registriert: Sa 18. Feb 2023, 17:05
Wohnort: Im Norden
Kontaktdaten:

Thesen zu einem Notfunknetz

Beitrag von Detlef (DH3DM) »

Vorbemerkung

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/Erfahrung finden, die sich der Teilthemen annehmen.


Ziel

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: Weiterleitungen von Nachrichten, bis das Ziel erreicht ist ("Store-and-Forward").
  • Das System muss für die Nutzer auch in "Normalzeiten" interessant/nutzbar sein als "infrastrukturfreier Funk-Messenger zum Spaß". Sonst wird die Akzeptanz für die Investition gering sein.
  • 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: "DINO" (= DIgitaler NOtfunk)


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 ("DINO-Einheit") erforderlich.
  • 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 (= "Notfunkstellen") das Funknetz hat, desto besser. Große Dichte der Knoten bedeutet, dass der Weg für die Bevölkerung zum nächsten Knoten kurz ist. Bei Welfare-Traffic ist dies ein wichtiges Kriterium.
Benötigt wird also ein Konzept, das so "charmant" ist, dass viele Personen einen Knoten in Betrieb nehmen möchten.
Grundsätzliche Ansätze:
  • LoRa, Zigbee: Gesetzlich begrenzter Duty-Cycle. Damit sehr geringer Datendurchsatz.
  • PMR446: Keine Anschlussmöglichkeiten für eine DINO-Einheit - Killkriterium.
  • CB-Funk mit angeschlossener DINO-Einheit: Laut BNetzA OK, auch automatisch (s. u.).
  • Digital-Amateurfunk auf KW mit angeschlossener DINO-Einheit: Reichweite, die für Welfare-Traffic eher zu groß ist. Nur wenige OMs haben Platz für die entsprechenden Antennen.
  • Digital-Amateurfunk auf UKW mit angeschlossener DINO-Einheit: OK, allerdings ist automatischer Betrieb problematisch (s. u.).
  • Die Funkgeräte (Sendeempfänger, TRX) sollen günstig zu bekommen und von möglichst vielen Personen rechtlich sauber betreibbar sein. Argument für CB-Funk.
=> 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://www.bundesnetzagentur.de/Shared ... onFile&v=4 unbeaufsichtigter automatischer Betrieb erlaubt, solange der Verantwortliche erreichbar ist. Der Betreiber muss seinen Knoten also z. B. lediglich ausschalten, bevor er ohne Handy in den Urlaub geht.
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, CB-Funker, etc., alle Interessenten an diesem Funknetzwerk) geringer ist.
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 ("DINO-Einheit") steuerbar sein.

=> CB-Funk: Stromökonomisches Mobilgerät einsetzen. SSB-CB-Geräte sind wesentlich teurer als AM/FM-CB-Geräte, daher auf AM/FM-CB-Geräten basieren lassen.

=> Amateurfunk: Baofeng 2-m-Modul.

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: Technischer Umfang, Prozessortyp, Speicher

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 (Arduino/PIC) sinnvoll und möglich zu sein.
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 im Prozessor verfügbar ist.

=> Arduino ATmega 328P mit externem statischem RAM-Chip.

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/Demodulation):
  • Damit pro Phase 4 Bits übertragbar, also ein Byte in zwei Phasen.
  • Bei einer angenommenen Phasendauer von 0,05 s => 10 Byte/s.
  • Damit für ein Telegramm (von, an, TTL, "Dies ist ein Test.") ca. 4 Sekunden.
=> AMFSK; Toneinspeisung/-auskopplung über Mikrofoneingang/Lautsprecherausgang.

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-/Retransmission-Protokoll.

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 ("fasse dich kurz"). Das muss auch den Anwendern klar gemacht werden. So wird das Netz entlastet.
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 "+" handelt es sich um einen Broadcast für die Location mit dem angegebenen Radius. Beispiel: JO41AA+5 = an alle Stationen im Umkreis von 5 km um Locator JO41AA.

=> Routing-Eigenentwicklung oder etwas Existierendes anpassen?

Teilthese 11: Benutzerschnittstelle, sonstige Realisierung
  • 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.
    Was im LCD zu sehen sein könnte
    Was im LCD zu sehen sein könnte
    lcd_beispielinhalte.png (89.24 KiB) 477 mal betrachtet
  • 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, die bei Selbstbau den korrekten Aufbau prüfen und später etwaige Störungen erkennen.
  • 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/herunterladbar).
=> Box mit LCD, Anschluss für Computertastatur, Lautsprecher-Eingang und Mikrofon-ein- und -ausgang, Lautsprecher.
So könnte die DINO-Einheit aussehen
So könnte die DINO-Einheit aussehen
konzept_aussehen.png (67.95 KiB) 477 mal betrachtet

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/bleiben.
Es erscheint zweckmäßig, dass die DINO-Einheit auch hierfür eine universelle Lösung bereitstellt.
Gut wären zwei Ladekanäle (230-V-Netz, regenerativ (Solar/Wind)). Aus Energiespargründen sollte das netzbetriebene Ladegerät primärseitig ausgeschaltet werden, wenn der regenerative Kanal Leistung liefert. Problem: Sichere VDE-gerechte Realisierung. Notfalls sekundärseitig.

=> Ladeschaltung in DINO-Einheit integrieren.
Benutzeravatar
DJ1NG
Schon etwas dabei
Schon etwas dabei
Beiträge: 66
Registriert: Fr 16. Dez 2022, 11:26
Wohnort: Burkhardsdorf / Erzgebirge
Kontaktdaten:

Re: Thesen zu einem Notfunknetz

Beitrag von DJ1NG »

WOW ... ich bin begeistert!

JA ... das brauchen wir - und vor allem können wir das auch über einen Blackout/eine Katastrophe hinaus gebrauchen.

In Sachen "Funkrufname" - also Stations-ID - habe ich erst gestutzt. Sieht natürlich komisch aus für das Funkerauge ;-) Und die Frage ist auch, wieviele Stationen dann maximal in ein Locator-Feld hineinpassen. In Deinem Beispiel wären es 9, maximal 28 wenn man die Buchstaben noch mitnimmt. Sprich: Der Funkrufname muss erweitert werden (auf drei Zahlen), damit man flexibel bleibt. Dann könnte man z.B. auch festlegen, dass z.B. die ID JN38WC-999 ein Broadcast ist, ohne dass man darauf achten muss ob ein Plus oder Minus-Zeichen dazwischen steht.

Idee am Rande: Vielleicht könnte man für die Entwicklung der Hard- und Software dieses als Projekt-, Bachelor- oder Masterarbeit an einen Studenten vergeben. "Jens P" aus der Telegram-Gruppe arbeitet an einer Technik-Uni. Vielleicht kann er entsprechendes vermitteln.

An Deiner (tollen) Graphik hast Du die USB-Buchse vergessen ;-) Bei der Gelegenheit muss überlegt werden, ob es nicht sinnvoll ist, ein kleines Keyboard fest zu integrieren - vielleicht optional.

Sprich:
Geräte-Variante 1: Tastatur inklusive ==> Benutzerknoten
Geräte-Variante 2: Ohne Keyboard (nur USB-Buchse) ==> Zwischenknoten für unbeaufsichtigten Betrieb

Soooo, das war jetzt erst mal mein gestürmtes Gehirn dazu :D

An der Idee bleiben wir dran. Vor allem daran, das Ganze über CB-Funk zu machen - Reichweite und vor allem bleibt das CB-Band dann so erhalten und wird nicht eines Tages wegen inaktivität eingezogen seitens der BNetzA
DJ1NG / DN1NF / Manager von DL0JRK

Mein ganz persönliches Notfunk-Projekt: https://dj1ng.aknotfunk.de
Mein drahtloses Hobby: http://dj1ng.deutschland-funkt.de

Initiative Deutschland funkt!!! - Bürgernotfunk für JEDERMANN
Benutzeravatar
Funkmax
Nicht mehr ganz frisch
Nicht mehr ganz frisch
Beiträge: 18
Registriert: Mi 21. Dez 2022, 19:38
Wohnort: Coswig/Sachsen
Kontaktdaten:

Re: Thesen zu einem Notfunknetz

Beitrag von Funkmax »

Das Konzept gefällt mir auch sehr gut!!!
Schnittstellen zu Meshtastic könnten das Notfunknetz erweitern,
meist vorhandene Mobiltelefone sollten für die Bedienung per APP mit einbezogen werden.
Für die Kommunikationsstruktur habe ich auch Maidenhead-Locatordaten im Blick...
73 Gerd, DO1FEH
DO1FEH
Benutzeravatar
Detlef (DH3DM)
Nicht mehr ganz frisch
Nicht mehr ganz frisch
Beiträge: 29
Registriert: Sa 18. Feb 2023, 17:05
Wohnort: Im Norden
Kontaktdaten:

Re: Thesen zu einem Notfunknetz

Beitrag von Detlef (DH3DM) »

DJ1NG hat geschrieben: So 19. Feb 2023, 11:55 WOW ... ich bin begeistert!
Danke für Dein freundliches und motivierendes Feedback!
DJ1NG hat geschrieben: So 19. Feb 2023, 11:55 JA ... das brauchen wir - und vor allem können wir das auch über einen Blackout/eine Katastrophe hinaus gebrauchen.
Ja, das war mir wichtig, da man nur so die Leute überhaupt ins Boot bekommt.
DJ1NG hat geschrieben: So 19. Feb 2023, 11:55 In Sachen "Funkrufname" - also Stations-ID - habe ich erst gestutzt. Sieht natürlich komisch aus für das Funkerauge ;-) Und die Frage ist auch, wieviele Stationen dann maximal in ein Locator-Feld hineinpassen. In Deinem Beispiel wären es 9, maximal 28 wenn man die Buchstaben noch mitnimmt. Sprich: Der Funkrufname muss erweitert werden (auf drei Zahlen), damit man flexibel bleibt. Dann könnte man z.B. auch festlegen, dass z.B. die ID JN38WC-999 ein Broadcast ist, ohne dass man darauf achten muss ob ein Plus oder Minus-Zeichen dazwischen steht.
Wenn Du in die Beispiel-LCD-Screens guckst, siehst Du, dass ich keine Beschränkung auf eine Stelle angedacht hatte. Ich bin großer Freund davon, sich nicht per Design gleich Türen zuzuschlagen. Nachteil der variierenden Stellenanzahl ist, dass die Routingtabelle nicht mehr fixe Blöcke hat. Damit kann man bei der Suche nicht mehr mit fester Sprungweite durch die Liste hüpfen, sondern muss nach Delimitern suchen oder mit Pointern arbeiten.

Übrigens: In "unserer Gegend" ist ein sechsstelliger Maidenhead-Locator ca. 3 x 3 km groß. Ich fände es toll, aber glaube nicht wirklich, dort jemals mehr als 9 DINO-Knoten zu haben ... ;)
Damit will ich die Thematik "mehr als 1 Stelle" aber definitiv nicht abwürgen.

Für Broadcast hatte ich mir ja die Notation LOCATOR+km überlegt. Ist kompakt und man kann die geografische Reichweite des Broadcasts einstellen. Plus/Minus verwechseln gibt es nicht, wenn die SW beim Betreten der Maske für das Senden zuerst fragt, ob Einzelnachricht oder Broadcast, die entsprechenden Infos dann einzeln abfragt, und daraus die Zieladresse baut.
DJ1NG hat geschrieben: So 19. Feb 2023, 11:55 Idee am Rande: Vielleicht könnte man für die Entwicklung der Hard- und Software dieses als Projekt-, Bachelor- oder Masterarbeit an einen Studenten vergeben. "Jens P" aus der Telegram-Gruppe arbeitet an einer Technik-Uni. Vielleicht kann er entsprechendes vermitteln.
Alle, die Interesse an dieser Sache haben, werden sich freuen, wenn wir Leute finden, die sich Teilthemen annehmen und realisieren. Es ist leider bei vielen Projekten so, dass Viele viele (teilweise komplexe) Ideen einbringen, aber bei der Realisierung nicht dabei sind. Ich selber bin häufig auch bei den Realisierenden, daher sind meine Ideen eher so, dass ich beim Gedanken an deren Realisierung nicht gleich Bauchschmerzen bekomme ... ;)
DJ1NG hat geschrieben: So 19. Feb 2023, 11:55 An Deiner (tollen) Graphik hast Du die USB-Buchse vergessen ;-) Bei der Gelegenheit muss überlegt werden, ob es nicht sinnvoll ist, ein kleines Keyboard fest zu integrieren - vielleicht optional.
Danke für die Blumen. Nee, die Buchse ist da ... nur getarnt als "Tastaturbuchse". ;)
DJ1NG hat geschrieben: So 19. Feb 2023, 11:55 Geräte-Variante 1: Tastatur inklusive ==> Benutzerknoten
Geräte-Variante 2: Ohne Keyboard (nur USB-Buchse) ==> Zwischenknoten für unbeaufsichtigten Betrieb
Das Ganze sollte Open Source SW und Open Source HW werden. Damit kann jeder mit passendem Know-How für sich Dinge optimieren.
Aber ich stimme zu, Varianten könnten helfen, dass mehr Leute "ihr passendes Ding" finden.
Ich hatte so eine Idee mit einer integrierten Tastatur auch. Schließlich habe ich so was noch herumliegen (vor Urzeiten bei einem Surplus-Händler gekauft):
Eine Folientastatur.
Eine Folientastatur.
tastatur.jpg (115.29 KiB) 434 mal betrachtet
Ich habe diese Variante aber ganz weit zurückgestellt. Grund:
USB-Tastaturen sind billig. Bekommt man überall nachgeworfen, wenn man den Haarschnitt des Verkäufers kritisiert. :D Integrierbare Tastaturen sind vergleichsweise teuer und u. U. auch nicht USB-Typen sondern "nackte Matrix" (siehe Foto). Da muss man dann einen Matrix-Scan in den Code einbauen. Nicht kompliziert, aber verbraucht kostbaren Flash- und EEPROM-Raum. Wenn wirklich Matrix-Tastaturen eingesetzt werden, dann muss man genau eine auswählen, sonst muss man für jeden Typ eine eigene Lookup-Tabelle ins EEPROM schieben. Mag ich nicht drüber nachdenken ...


So weit erst mal ... wurde schon wieder länger als gedacht ...
Benutzeravatar
Detlef (DH3DM)
Nicht mehr ganz frisch
Nicht mehr ganz frisch
Beiträge: 29
Registriert: Sa 18. Feb 2023, 17:05
Wohnort: Im Norden
Kontaktdaten:

Re: Thesen zu einem Notfunknetz

Beitrag von Detlef (DH3DM) »

Funkmax hat geschrieben: So 19. Feb 2023, 16:56 Schnittstellen zu Meshtastic könnten das Notfunknetz erweitern,
Ich finde Meshtastic auch sehr spannend. Vielleicht sollten wir eine RS232-Schnittstelle mit einem einfachen Protokoll zur Kopplung verschiedener Systeme vorsehen.
Das wäre nur Punkt zu Punkt, also zwei Systeme. Besser wäre ein Bus (RS485, I2C, SPI, ...). Da müsste einer ran, der so was kompakt implementieren kann. Kostet Zeit und Flash, aber wenn noch Platz ist ...
Funkmax hat geschrieben: So 19. Feb 2023, 16:56 meist vorhandene Mobiltelefone sollten für die Bedienung per APP mit einbezogen werden.
Es gibt ein Bluetooth-Modul für RS232 und dazu Apps, die eine Bluetooth-Tastatur realisieren. Damit könnte man sich die physikalische Tastatur sparen. Auch eine Idee!

Allerdings habe ich bei der ganzen Sache auch einen Blackout im Blick. Handys sind da nur überteuerte Briefbeschwerer. Die Akkus der Dinger dann nur für den Einsatz als Tastatur zu laden, ist nicht wirklich energieökonomisch. Aber für den Betrieb in "Normalzeiten" ist das cool.
... und wir wollen ja cool sein ...
Da habe ich eben nur ganz kurz reingeschaut ... interessant ... muss ich mir noch mal mit mehr Muße ansehen.
Benutzeravatar
Detlef (DH3DM)
Nicht mehr ganz frisch
Nicht mehr ganz frisch
Beiträge: 29
Registriert: Sa 18. Feb 2023, 17:05
Wohnort: Im Norden
Kontaktdaten:

Re: Thesen zu einem Notfunknetz

Beitrag von Detlef (DH3DM) »

Funkmax hat geschrieben: So 19. Feb 2023, 16:56 Schnittstellen zu Meshtastic könnten das Notfunknetz erweitern,
Ich mache mir gerade etwas Sorgen, dass wir hier eine unsinnige Parallelentwicklung anstoßen. :o
Ich habe mich das letzte Mal vor wenigen Monaten mit Meshtastic und MeshCom beschäftigt. Und da sah das alles so unfertig aus, dass ich das als Kommunikationsnetz-Technologie komplett ausgeschlossen habe.
Aus Deinen Beiträgen entnehme ich, dass die Technik jetzt doch schon stabil nutzbar ist?
Kannst Du vielleicht ein paar Worte dazu verlieren?
windy
Newcomer
Beiträge: 1
Registriert: So 19. Feb 2023, 20:47

Re: Thesen zu einem Notfunknetz

Beitrag von windy »

Möchte jetzt nicht querschiessen.
Aber die Anforderungen der BOS lauten Sprechfunk.
Und es sollte so einfach wie möglich laufen.
Benutzeravatar
Funkmax
Nicht mehr ganz frisch
Nicht mehr ganz frisch
Beiträge: 18
Registriert: Mi 21. Dez 2022, 19:38
Wohnort: Coswig/Sachsen
Kontaktdaten:

Re: Thesen zu einem Notfunknetz

Beitrag von Funkmax »

Eine Parallelentwicklung durch Mechtastic möchte ich nicht anstoßen, es sollten aber alle Technologien betrachtet werden.
Notfunk wird fast ausschließlich im Wechselsprechen abgewickelt, bei der Nachrichtenübermittlung an Dritte, Hilfsorganisationen usw. wird aber immer auf formalisierten Verkehr zurückgegriffen und mit digitalen Textnachrichten können Verzögerungen durch Rückfragen vermieden werden und die Protokollierung erfordert keinen Zusatzaufwand. Meine Meinung - Hauptsache es dient der Sache!
DO1FEH
Benutzeravatar
Detlef (DH3DM)
Nicht mehr ganz frisch
Nicht mehr ganz frisch
Beiträge: 29
Registriert: Sa 18. Feb 2023, 17:05
Wohnort: Im Norden
Kontaktdaten:

Re: Thesen zu einem Notfunknetz

Beitrag von Detlef (DH3DM) »

windy hat geschrieben: So 19. Feb 2023, 20:49 Aber die Anforderungen der BOS lauten Sprechfunk.
Und es sollte so einfach wie möglich laufen.
Hey, danke für Deinen Input.

Es geht bei diesem System um nichts, was die BOS betrifft.
Das System soll Welfare Traffic transportieren - etwas was die BOS weder können noch wollen.

Wir pfuschen also auf keine Weise in deren Betrieb.
Damit können wir also tun lassen, was wir wollen, solange wir die Gesetze beachten. Und das werden wir, sonst bin ich raus.
:D
Jensemann_P
Newcomer
Beiträge: 4
Registriert: Mi 21. Dez 2022, 19:25

Re: Thesen zu einem Notfunknetz

Beitrag von Jensemann_P »

DJ1NG hat geschrieben: So 19. Feb 2023, 11:55 Idee am Rande: Vielleicht könnte man für die Entwicklung der Hard- und Software dieses als Projekt-, Bachelor- oder Masterarbeit an einen Studenten vergeben. "Jens P" aus der Telegram-Gruppe arbeitet an einer Technik-Uni. Vielleicht kann er entsprechendes vermitteln.
Leider nur fast richtig. Ich bin selbst Techniker an einer Uni, aber an einem geisteswissenschaftlichen Fachbereich mit eigenem Campus, also null Zugriff auf Etech Studies.

Aber ja, eigentlich ist sowas ein super Thema für eine Abschlussarbeit, das hätte mir damals auch gefallen. Aber Mikrocontroller ist so lange her und die Zeit eh shcon immer so knapp, also schrei ich mal nicht laut "hier". Aber shcon ein sehr interessantes Projekt.

Auch zu den Überlegungen: Mega Konzept, wirklich sehr gut durchdacht.

Was ich mich noch Frage: Wieso sollte sich bei PMR nichts anshcließen lassen, aber bei CB?
Viele PMR Geräte haben ja auch Buchsen für Speakermics.
Antworten

Zurück zu „Grundlagen“