Amateurfunk Forum - Archiv

Fragen und Antworten zum Thema Funk


Impressum

Verantwortlich für dieses Angebot gemäß § 5 TMG / § 55 RStV:
Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.

Datenschutzerklärung

Diese Datenschutzerklärung klärt Sie über die Art, den Umfang und Zweck der Verarbeitung von personenbezogenen Daten (nachfolgend kurz „Daten“) innerhalb unseres Onlineangebotes und der mit ihm verbundenen Webseiten, Funktionen und Inhalte auf (nachfolgend gemeinsam bezeichnet als „Onlineangebot“). Im Hinblick auf die verwendeten Begrifflichkeiten, wie z.B. „Verarbeitung“ oder „Verantwortlicher“ verweisen wir auf die Definitionen im Art. 4 der Datenschutzgrundverordnung (DSGVO).

Verantwortlicher

Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Arten der verarbeiteten Daten:

- Meta-/Kommunikationsdaten (siehe Abschnitt „Erhebung von Zugriffsdaten und Logfiles“)

Kategorien betroffener Personen

Besucher und Nutzer des Onlineangebotes (Nachfolgend bezeichnen wir die betroffenen Personen zusammenfassend auch als „Nutzer“).

Zweck der Verarbeitung

- Zurverfügungstellung des Onlineangebotes, seiner Funktionen und Inhalte
- Sicherheitsmaßnahmen.

Verwendete Begrifflichkeiten

„Personenbezogene Daten“ sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung (z.B. Cookie) oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind.

„Verarbeitung“ ist jeder mit oder ohne Hilfe automatisierter Verfahren ausgeführte Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit personenbezogenen Daten. Der Begriff reicht weit und umfasst praktisch jeden Umgang mit Daten.

„Pseudonymisierung“ die Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen, die gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten oder identifizierbaren natürlichen Person zugewiesen werden.

Als „Verantwortlicher“ wird die natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten entscheidet, bezeichnet.

„Auftragsverarbeiter“ eine natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet.

Maßgebliche Rechtsgrundlagen

Nach Maßgabe des Art. 13 DSGVO teilen wir Ihnen die Rechtsgrundlagen unserer Datenverarbeitungen mit. Sofern die Rechtsgrundlage in der Datenschutzerklärung nicht genannt wird, gilt Folgendes: Die Rechtsgrundlage für die Einholung von Einwilligungen ist Art. 6 Abs. 1 lit. a und Art. 7 DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer Leistungen und Durchführung vertraglicher Maßnahmen sowie Beantwortung von Anfragen ist Art. 6 Abs. 1 lit. b DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer rechtlichen Verpflichtungen ist Art. 6 Abs. 1 lit. c DSGVO, und die Rechtsgrundlage für die Verarbeitung zur Wahrung unserer berechtigten Interessen ist Art. 6 Abs. 1 lit. f DSGVO. Für den Fall, dass lebenswichtige Interessen der betroffenen Person oder einer anderen natürlichen Person eine Verarbeitung personenbezogener Daten erforderlich machen, dient Art. 6 Abs. 1 lit. d DSGVO als Rechtsgrundlage.

Sicherheitsmaßnahmen

Wir treffen nach Maßgabe des Art. 32 DSGVO unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen, geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.

Zu den Maßnahmen gehören insbesondere die Sicherung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten durch Kontrolle des physischen Zugangs zu den Daten, als auch des sie betreffenden Zugriffs, der Eingabe, Weitergabe, der Sicherung der Verfügbarkeit und ihrer Trennung. Des Weiteren haben wir Verfahren eingerichtet, die eine Wahrnehmung von Betroffenenrechten, Löschung von Daten und Reaktion auf Gefährdung der Daten gewährleisten. Ferner berücksichtigen wir den Schutz personenbezogener Daten bereits bei der Entwicklung, bzw. Auswahl von Hardware, Software sowie Verfahren, entsprechend dem Prinzip des Datenschutzes durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO).

Zusammenarbeit mit Auftragsverarbeitern und Dritten

Sofern wir im Rahmen unserer Verarbeitung Daten gegenüber anderen Personen und Unternehmen (Auftragsverarbeitern oder Dritten) offenbaren, sie an diese übermitteln oder ihnen sonst Zugriff auf die Daten gewähren, erfolgt dies nur auf Grundlage einer gesetzlichen Erlaubnis (z.B. wenn eine Übermittlung der Daten an Dritte, wie an Zahlungsdienstleister, gem. Art. 6 Abs. 1 lit. b DSGVO zur Vertragserfüllung erforderlich ist), Sie eingewilligt haben, eine rechtliche Verpflichtung dies vorsieht oder auf Grundlage unserer berechtigten Interessen (z.B. beim Einsatz von Beauftragten, Webhostern, etc.).

Sofern wir Dritte mit der Verarbeitung von Daten auf Grundlage eines sog. „Auftragsverarbeitungsvertrages“ beauftragen, geschieht dies auf Grundlage des Art. 28 DSGVO.

Übermittlungen in Drittländer

Sofern wir Daten in einem Drittland (d.h. außerhalb der Europäischen Union (EU) oder des Europäischen Wirtschaftsraums (EWR)) verarbeiten oder dies im Rahmen der Inanspruchnahme von Diensten Dritter oder Offenlegung, bzw. Übermittlung von Daten an Dritte geschieht, erfolgt dies nur, wenn es zur Erfüllung unserer (vor)vertraglichen Pflichten, auf Grundlage Ihrer Einwilligung, aufgrund einer rechtlichen Verpflichtung oder auf Grundlage unserer berechtigten Interessen geschieht. Vorbehaltlich gesetzlicher oder vertraglicher Erlaubnisse, verarbeiten oder lassen wir die Daten in einem Drittland nur beim Vorliegen der besonderen Voraussetzungen der Art. 44 ff. DSGVO verarbeiten. D.h. die Verarbeitung erfolgt z.B. auf Grundlage besonderer Garantien, wie der offiziell anerkannten Feststellung eines der EU entsprechenden Datenschutzniveaus (z.B. für die USA durch das „Privacy Shield“) oder Beachtung offiziell anerkannter spezieller vertraglicher Verpflichtungen (so genannte „Standardvertragsklauseln“).

Rechte der betroffenen Personen

Sie haben das Recht, eine Bestätigung darüber zu verlangen, ob betreffende Daten verarbeitet werden und auf Auskunft über diese Daten sowie auf weitere Informationen und Kopie der Daten entsprechend Art. 15 DSGVO.

Sie haben entsprechend. Art. 16 DSGVO das Recht, die Vervollständigung der Sie betreffenden Daten oder die Berichtigung der Sie betreffenden unrichtigen Daten zu verlangen.

Sie haben nach Maßgabe des Art. 17 DSGVO das Recht zu verlangen, dass betreffende Daten unverzüglich gelöscht werden, bzw. alternativ nach Maßgabe des Art. 18 DSGVO eine Einschränkung der Verarbeitung der Daten zu verlangen.

Sie haben das Recht zu verlangen, dass die Sie betreffenden Daten, die Sie uns bereitgestellt haben nach Maßgabe des Art. 20 DSGVO zu erhalten und deren Übermittlung an andere Verantwortliche zu fordern.

Sie haben ferner gem. Art. 77 DSGVO das Recht, eine Beschwerde bei der zuständigen Aufsichtsbehörde einzureichen.

Widerrufsrecht

Sie haben das Recht, erteilte Einwilligungen gem. Art. 7 Abs. 3 DSGVO mit Wirkung für die Zukunft zu widerrufen

Widerspruchsrecht

Sie können der künftigen Verarbeitung der Sie betreffenden Daten nach Maßgabe des Art. 21 DSGVO jederzeit widersprechen. Der Widerspruch kann insbesondere gegen die Verarbeitung für Zwecke der Direktwerbung erfolgen.

Löschung von Daten

Die von uns verarbeiteten Daten werden nach Maßgabe der Art. 17 und 18 DSGVO gelöscht oder in ihrer Verarbeitung eingeschränkt. Sofern nicht im Rahmen dieser Datenschutzerklärung ausdrücklich angegeben, werden die bei uns gespeicherten Daten gelöscht, sobald sie für ihre Zweckbestimmung nicht mehr erforderlich sind und der Löschung keine gesetzlichen Aufbewahrungspflichten entgegenstehen. Sofern die Daten nicht gelöscht werden, weil sie für andere und gesetzlich zulässige Zwecke erforderlich sind, wird deren Verarbeitung eingeschränkt. D.h. die Daten werden gesperrt und nicht für andere Zwecke verarbeitet. Das gilt z.B. für Daten, die aus handels- oder steuerrechtlichen Gründen aufbewahrt werden müssen.

Nach gesetzlichen Vorgaben in Deutschland, erfolgt die Aufbewahrung insbesondere für 10 Jahre gemäß §§ 147 Abs. 1 AO, 257 Abs. 1 Nr. 1 und 4, Abs. 4 HGB (Bücher, Aufzeichnungen, Lageberichte, Buchungsbelege, Handelsbücher, für Besteuerung relevanter Unterlagen, etc.) und 6 Jahre gemäß § 257 Abs. 1 Nr. 2 und 3, Abs. 4 HGB (Handelsbriefe).

Hosting und E-Mail-Versand

Die von uns in Anspruch genommenen Hosting-Leistungen dienen der Zurverfügungstellung der folgenden Leistungen: Infrastruktur- und Plattformdienstleistungen, Rechenkapazität, Speicherplatz und Datenbankdienste, E-Mail-Versand, Sicherheitsleistungen sowie technische Wartungsleistungen, die wir zum Zwecke des Betriebs dieses Onlineangebotes einsetzen.

Hierbei verarbeiten wir, bzw. unser Hostinganbieter Meta- und Kommunikationsdaten von Besuchern dieses Onlineangebotes auf Grundlage unserer berechtigten Interessen an einer effizienten und sicheren Zurverfügungstellung dieses Onlineangebotes gem. Art. 6 Abs. 1 lit. f DSGVO i.V.m. Art. 28 DSGVO (Abschluss Auftragsverarbeitungsvertrag).

Erhebung von Zugriffsdaten und Logfiles

Wir, bzw. unser Hostinganbieter, erhebt auf Grundlage unserer berechtigten Interessen im Sinne des Art. 6 Abs. 1 lit. f. DSGVO Daten über jeden Zugriff auf den Server, auf dem sich dieser Dienst befindet (sogenannte Serverlogfiles). Zu den Zugriffsdaten gehören Name der abgerufenen Webseite, Datei, Datum und Uhrzeit des Abrufs, übertragene Datenmenge, Meldung über erfolgreichen Abruf, Browsertyp nebst Version, das Betriebssystem des Nutzers, Referrer URL (die zuvor besuchte Seite), IP-Adresse und der anfragende Provider.

Logfile-Informationen werden aus Sicherheitsgründen (z.B. zur Aufklärung von Missbrauchs- oder Betrugshandlungen) für die Dauer von maximal 7 Tagen gespeichert und danach gelöscht. Daten, deren weitere Aufbewahrung zu Beweiszwecken erforderlich ist, sind bis zur endgültigen Klärung des jeweiligen Vorfalls von der Löschung ausgenommen.

Vom Websiteinhaber angepasst
Erstellt mit Datenschutz-Generator.de von RA Dr. Thomas Schwenke




 [ 78 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5, 6
Autor Nachricht
 Betreff des Beitrags: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hallo zusammen,

in einem anderen Thread kam schon mal das Thema auf, aber ich wollte das gerne abkoppeln. Wer weiss, wer von euch noch etwas dazu zu sagen hat ;-)

Während der Planung für Notfunknetze in Bayern resp. Franken kam das Thema "Packet Radio" auf. Im Vergleich zu PACTOR und zu HAMNET hat Packet Radio mit 1200 Baud AFSK aber einige Vorteile:

[list:3uaa5y91]Bewährte Technik (alt aber nie wirklich schlecht gewesen)[/list:u:3uaa5y91]
[list:3uaa5y91]Preisgünstig zu beschaffen[/list:u:3uaa5y91]
[list:3uaa5y91]Auch auf VHF problemlos einsetzbar[/list:u:3uaa5y91]
[list:3uaa5y91]Flexibel in der Hardware[/list:u:3uaa5y91]
[list:3uaa5y91]Zur Not reicht das einfachste Terminalprogramm[/list:u:3uaa5y91]
[list:3uaa5y91]Stand-Alone-Geräte sind möglich als Digipeater[/list:u:3uaa5y91]

Ein 1K2 Packet Radio Netz würde (egal ob auf VHF oder UHF) eine digitale Datenübertragung mit einfachsten Mitteln ermöglichen. Eine fehlerfreie Datenübertragung, was noch erschwerend hinzukommt - dies ist nämlich eine Anforderung der BOS: Wenn schon Daten übermittelt werden, sollen nicht unterwegs aus 20 Betten für Schwerstbrandverletzte plötzlich 200 werden ;-)

Dafür in Frage kommende Hardware könnte zum Beispiel sein:

[b:3uaa5y91]Funkgeräte: [/b:3uaa5y91]Mehr oder weniger alles was es auf dem Markt gibt oder gab - selbst die China-Böller wie Baofeng etc. sind mit einer PTT-Zusatzbeschaltung brauchbar (mit VOX nicht).

[b:3uaa5y91]Modems:[/b:3uaa5y91] Alles was man bekommen kann und einen Connect zulässt ;-) Dabei sind TNC mit Nord><Link Firmware natürlich allem voraus, weil sie auch ohne angeschlossenen Computer prima als Digipeater und Minimailbox arbeiten können. TNC-PI sind die erste Wahl für Raspberry. Aber auch Software-TNCs wie Soundmodem (für Windows und Raspberry verfügbar) kommen in Frage.

[b:3uaa5y91]Computer:[/b:3uaa5y91] Alles was in der Lage ist, über eine COM-Schnittstelle - alternativ Soundkarte - ist geeignet: Vom uralt 80286er bis hin zum modernsten PC. Natürlich kommen auch Raspberry & Co in Frage solange sie eine USB-Soundkarte oder einen USB/RS232 Adapter unterstützen. Wichtig wäre allerdings, das man den COmputer an 12V betreiben kann - was die Auswahl recht eingrenzt, wenn man nicht mit einem 230/12V Inverter arbeiten will. Raspberry und Notebooks mit dem passenden Netzteil bzw. Step-Down-Konverter sind da natürlich allem voraus.

[b:3uaa5y91]Software:[/b:3uaa5y91] Steinalte Packet Radio Programme laufen immer noch. Ich habe mein altes Lieblingsprogramm SP einwandfrei unter Windows 7 zum laufen bekommen ;-) Für TNCs reichen vollkommen ein simples Terminalprogramm (es muss nicht immer Hostmode sein), welches eine ESCape Sequenz senden kann. Hyperterminal von Windows < 7 ist da durchaus nicht die schlechteste Wahl.

Mit all dem (alten Geraffel) kann man ein wunderbares PR-Netzwerk errichten, welches sogar kostenmässig im Level bleibt:

... EIN TNC als Digipeater
... die Gegenstationen jeweils mit Raspberry, USB-Soundkarte, Soundmodem und einem Billig-Funkgerät
... und das war es!!!

Die Gegenstationen könnte man natürlich auch mit einem kompletten PiGate ausrüsten ([url:3uaa5y91]http://www.pigate.net[/url:3uaa5y91]) - und den TNC-Digipeater zu einem Winlink-RMS Packet ausbauen ([url:3uaa5y91]http://winlink.org/content/rms_packet[/url:3uaa5y91]) ausbauen. Das wären dann schon aber ziemlicher Luxus.

Wenn man das Ganze auf die Spitze treiben will, dann verbindet man das RMS Packet noch mit einem RMS-Trimode mit PACTOR auf HF ([url:3uaa5y91]http://winlink.org/content/rms_trimode[/url:3uaa5y91]) - und fertig ist die Datenkommunikation, welche selbst den höchsten Ansprüchen einer gehobenen BOS-Dienststelle genügen könnte.

Wie seht ihr das? Irgendwelche Verbesserungsvorschläge? Wünsche, Anregungen, etc?

Jetzt bin ich gespannt.
73, Guido


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Nur als Denkanstoß in eine andere Richtung. Ich habe noch nicht gehört, dass das jemand hier mal ausprobiert hat:
Notfunk mit Fldigi: [url=https://youtu.be/bN2QPZZzkn4:133t28th]Klick[/url:133t28th] -> "Use of Fldigi with FM VHF/UHF transceivers for local communications during a disaster or emergency.".
Da wird für die digitale Übertragung MT63-2KL als Digimode (nicht schmalbandig sein, aber fehlerarm) zur Nutzung auf UHF/VHF vorgeschlagen. Texte/Nachrichten und vor allem kleine Dateien können damit mit FM-TRX+Soundkarte (Stelle 1min08) übertragen werden.
FLdigi ist frei und für alle gängigen Betriebssysteme erhältlich. Wenn ich mehr Zeit hätte würde ich das selber mal antesten…


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hi,
zum einrichten PC mit 230 Volt ist ok..aber dann wenn alles konfiguriert ist MUSS es mit 12 Volt auskommen können.
Reset Schalter sollte auch da sein..und dann sollte es die Daten ausm Eprom holen und wieder klar laufen.
Was ist mit 24 Volt im LKW ? Können das die Geäte auch ab ?

Meldungen ausdrucken ? Wie macht ihr das dann wenn was an die BOS Funker weitergegeben werden soll ?
Turnschuh Netzwerk ?

Wie macht ihr das mit Schichtdienst ? Jeder von zu Hause nach Zeitplan ? Gbts ein Plan für die Bevölkerung wo Anlaufstellen sind ? Wie lange soll alles aus Akku / Notstrom laufen können ?

CB Funker auch einbinden ?

So richtig merkt man wohl erst wo es knirscht wenn man mal ne schöen Grossübung veranstaltet...

73 de DL3FOX Uwe


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Die Diskussion PR für Notfunk wurde schon in den 80ern geführt und scheiterte an der Vernetzung, insbesondere zu BOS. Wenn es einfach sein muß, wird immer noch normales RTTY vorgezogen. Außerdem wurden die ersten Netze durch Digipeating zu Tode gefunkt und alles geriet sehr schnell in einen schlechten Ruf. Für eine PR-Vernetzung ist eine gute Abstimmung der Parameter, sinnvoller Digipeatereinsatz und Funkdisziplin erforderlich. Es kommt sonst sehr schnell zu übermäßig vielen Kollisionen und Retries ... und Netto läuft nichts mehr.

73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Irgendwelche Verbesserungsvorschläge?[/quote]
Könnte man PC-ALE ([url:1b1iiszy]http://www.amateurfunkpraxis.de/pcale.html[/url:1b1iiszy]) irgendwie integrieren? Ich habe mich damit mal eine Weile beschäftigt und fand diese "Methode" auch über größere Distanzen sehr brauchbar.

Auch in Richtung "Notfunk" war ich schon mal aktiv, wobei da die Organisationsstruktur in den Bundesländern sehr unterschiedlich ausfällt. In einigen Bundesländern arbeitet man mit den Funkamateuren zusammen, in anderen nicht. Meine "Notfunkausrüstung" halte ich ausschließlich für den eigenen Bedarf vor. (http://www.amateurfunkpraxis.de/notfunk.html) Das ist jetzt auch nichts besonderes, aber es funktioniert. PR ist mit Laptop und Soundmodem auch vorgesehen!


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hi,
man sollte das schon deutschlandweit normen. Wenn mal wieder Elbhochwasser ist oder so und Helfer aus allen Bundesländern anreisen..müssen die ja auch passende Technik haben. Wenn jedes Bundesland wieder ein eigenes Süppchen kocht...

73 de DL3FOX Uwe


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Danke für den Input soweit.

Ich möchte doch zunächst aber bitten, das wir uns hier bei der Diskussion auf die Technik konzentrieren. Was alles gemacht, genormt (und so weiter) werden sollte, da gehen die Meinung massiv ausseinander. Tatsache ist (und das bleibt mein Schlusswort dazu): Notfunk KANN nicht bundesweit genormt werden in DL, weil wir das nicht auf die Reihe bringen. Man hat es lange genug versucht. Gescheitert ist es u.a. auch daran das Katastrophenschutz LÄNDERSACHE ist - und deswegen kann ein Weg, den man in Bayern geht, nicht zwingend für andere Bundesländer übernommen werden - auch wenn das eine Idiotie in sich ist. Zu allem anderen möchte ich mich jetzt nicht äussern, das gehört nicht in diesen Thread. Wenn jemand von euch Fragen zur Organisationsstruktur hat (wer wo mit wem und wie funken soll, kann, darf, will) und sich dafür interessiert, welchen Ansatz wir hier verfolgen, schreibt mir bitte eine PN.

Zur Technik:

* ALE werde ich mir mal anschauen - aber Winmore und damit der Einstieg ins Winlink Netz geht auch mit Soundkarte etc. ALE wäre nur dann interessant, wenn es mit einem Raspberry betrieben werden kann. Windows Rechner sind im Notfall eher unbrauchbar. Zudem scheint ALE ja nur für KW interessant zu sein. Ich brauche aber eine lokale Lösung auf VHF/UHF-Basis.

* FLDIGI auf VHF/UHF werde ich mir auch anschauen, keine Frage. Klingt auf den ersten Blick interessant.

* 24 Volt Betrieb kommt nur über Wandler in Frage. 12V ist wichtig, und daher sind Raspberry PI und Konsorten aufgrund des geringen Stromverbrauches mehr als nur interessant (selbst Step-Down-Wandler von 12 auf 5V verbraten hierbei relativ geringe Leistung).

* Generell geht es darum, eine einfache, schnelle, unkomplizierte Lösung zu finden, womit BOS Daten austauschen können im Falle des Falles (ganz klar aber als "NICE-TO-HAVE" - und nicht als MUSS-Option). Packet Radio erfüllt das alles, wenn es passend vorbereitet ist.

Das Problem wird sein, in den nächsten Jahren noch genügend TNCs etc. aufzutreiben. Ich habe gerade die Erfahrung gemacht, das ich zwei TNCs gebraucht gekauft habe. Das eine geht tadellos, und das andere ist in den Frequenzen verschoben (1300/2300 Hz anstatt 1200/2200 Hz). Bin gespannt, wie ich das werde richten können.

Ich habe hier gerade einen Raspberry PI (1) mit den ax.25-tools, "soundmodem" und zusätzlicher PTT-beschaltung an einem Baofeng Handfunkgerät laufen. Leider erfordert diese Lösung extrem viel Aufwand (bis alles passt), und "stabil" ist leider auch nicht das Wort was mir in diesem Zusammenhang einfällt.

Ich habe mir in den USA ein TNC-PI bestellt ([url:3limtr8s]http://tnc-x.com/TNCPi.htm[/url:3limtr8s]) und warte jetzt heiss und sehnsüchtig auf die Lieferung (hängt wohl im Zoll). Davon erhoffe ich mir, das die Soundmodem-Lösung wegfällt, die ist nämlich gerade in Sachen "Experimente" extrem unhandlich.

Das war mein Zwischensenf dazu. Wie gesagt: Alles was über Technik hinausgeht bitte per PN anfragen. Es gibt tatsächlich Lösungen um im Behördendschungel sich ohne Machete durchzuschlagen zu müssen ;-)

73, Guido


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Das Problem wird sein, in den nächsten Jahren noch genügend TNCs etc. aufzutreiben.[/quote]
Wozu?
[quote]Davon erhoffe ich mir, das die Soundmodem-Lösung wegfällt, die ist nämlich gerade in Sachen "Experimente" extrem unhandlich.[/quote]
Diese Aussage verstehe ich absolut nicht! Es gibt nichts einfacheres, als ein Soundmodem! Entweder das von UZ7HO oder Direwolf. Im Gegensatz zum TNC verbraucht das Soundmodem keine zusätzliche Energie und läuft auch auf dem RASPI. Die TNC´s, die heute überwiegend noch erhältlich sind, sind doch nur noch was für Bastler und Nostalgiker. Das Soundmodem von UZ7HO bringt zudem noch eine absolut brauchbare Terminalsoftware (Easyterm) mit und unterstützt zudem AGWPE.
[url:391w1eid]http://uz7.ho.ua/packetradio.htm[/url:391w1eid]
[url:391w1eid]https://github.com/wb2osz/direwolf[/url:391w1eid]

Oder so etwas, ist aber teuer!
[url:391w1eid]http://www.wimo.com/packet-radio-tnc_d.html[/url:391w1eid]


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]... Notfunk mit Fldigi: [url=https://youtu.be/bN2QPZZzkn4:oowrd6i6]Klick[/url:oowrd6i6] -> "Use of Fldigi with FM VHF/UHF transceivers for local communications during a disaster or emergency." ...[/quote]

Das System sieht auf den ersten Blick gut aus, ist aber komplett für auf USAmerikanische Verhältnisse ausgelegt und bedürfte wahrscheinlich großer Anpassungen um bei uns verwendbar zu sein. Mal ganz abgesehen von der Sprache: Englisch ist leider nicht das, was ich bei BOS als Standard-Kenntnisse vorraussetze. Im K-Fall sind die froh, wenn sie keine Sprachbarrieren durch regionale Dialekte haben ;-)
FLDIGI und Notfunk habe ich jetzte rst mal für spätere Tests zur Seite gelegt.

[quote]Es gibt nichts einfacheres, als ein Soundmodem! Entweder das von UZ7HO oder Direwolf. Im Gegensatz zum TNC verbraucht das Soundmodem keine zusätzliche Energie und läuft auch auf dem RASPI. Die TNC´s, die heute überwiegend noch erhältlich sind, sind doch nur noch was für Bastler und Nostalgiker. Das Soundmodem von UZ7HO bringt zudem noch eine absolut brauchbare Terminalsoftware (Easyterm) mit und unterstützt zudem AGWPE.[/quote]

1. Ein TNC ist noch viel einfacher und erfordert NULL Linux-Kenntnisse.

2. Ein Soundmodem benötigt natürlich zusätzliche Energie, denn auch ein USB Gerät verbraucht Strom. Das ist aber - und da gebe ich Dir recht - in diesem Zusammenhang vernachlässigbar.

3. Oft ist nostagalische Technik die bessere und stabilere. Diese ist nämlich erprobt und eingefahren und es gibt genügend Leute, welche sich damit auskennen - solange man nicht mit IBM Lochkarten arbeiten will.

4. Bei mir läuft gerade ein Soundmodem auf dem RASPI, wie ich vorhin schon schrieb. Es kommen allerdings lange nicht alle Bakentexte an und es gibt auffallend oft Rejects und Wiederholungen auch beim Polling. In umgekehrter Richtung (vom TNC zum Soundmodem) passiert dies aber nicht.

Punkt 1, 3 & 4 sind die Punkte, weswegen ich die nostalgische Technik vorziehe. Ein einmal eingerichtetes TNC benötigt ein Funkgerät und sonst nichts. Ich kann es problemlos per Funk fernsteuern und es ist auch nach einem Stromausfall (oder z.B. in der Umschaltung von Netz- auf Batteriebetrieb) ziemlich schnell wieder am Start.

Ja ich weiss, das kann man auch alles mit der RASPI-Lösung machen.

Ich bitte darum, diesen Thread hier jetzt nicht eine "Glaubensfrage" nach dem besten System abgleiten zu lassen. Ich habe die Anregungen aufgenommen - und wie gesagt experimentiere ich schon längst mit einer RASPI-Lösung.

73, Guido


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Zum separaten TNC gebe ich Dir recht. Ich habe meine PK232 noch in Betrieb und mein TNC1 (der noch für APRS benutzt wurde) ist leider abgeraucht. Nachdem da die Ersatzteile mager sind, kämpfe ich noch mit Reparatur oder Recyclinghof). Ein separater TNC ist einfacher zu handhaben und hält den PC zum größten Teil frei (der kriegt nur noch die Netto-Daten).

RTTY wäre noch einfacher, aber .... ich habe noch einen T100S mit Lochstreifenleser und -stanzer, aber der läuft nur, wenn die XYL länger abwesend ist :-) . Werde ich wohl irgendwann opfern müssen, wenn wir aus Altersgründen in eine Wohnung ziehen. Die robusten legacy RTTY Geräte gibt es kaum noch.

Etwas zum PR - mein Haupteinwand: der Hidden Terminal Effekt wird von den meisten PR-Leuten krass unterschätzt. Ich hatte im Großraum München eine Digipeater vor der Nase, der bei mir DCD fast nicht mehr ausgehen ließ. Ab einer relativ geringen Benutzerzahl stirbt der Verkehr durch Collisionen und Retries. Das kann man protokollarisch etwas hinauszögern, aber das beste Protokoll schafft knappe 60% Nettolast, dann ist alles dicht. Ich habe das im QRL den damaligen Ethernetfans unter meinen IT-Fachleuten vorgeführt, da man bei 1200 noch zuhören kann, und im Protokoll mitlesen kann, wann und wie es scheppert. Das native CDMA-Protokoll schaft ~38% und mit einigen Tricks kommt man etwas über 50%, aber auch nur, wenn alle die gleichen Protokollparameter benutzen. Ich bin in den Hochzeiten des Digipeaters mit zwei entkoppelten Antennen und Fullduplexmode (ignoriert DCD) plus PA noch auf den Digipeater gekommen, aber das waren nur Tests, weil man sonst alles kaputt macht.

PR hat zwar den Vorteil, daß man es mit jeder FM-Handfunke + TNC machen kann, sogar über normale FM-Relais (habe ich hier auf unserem OV-Relais mit Rücksprache getestet). Bei korrekter Einstellung sendet der TNC dann nur in den Sprechpausen und fährt nicht über ein FM-NF-Signal drüber. Allerdings ..... wie vorher ausgeführt, eine PR-QRG ist bei 1200 bereits im unteren zweistelligen Userbereich ( ~12+) dicht. Deshalb bezweifele ich eine sinnvolle Anwendung. Es geht allenfalls als point-to-point Strecke, aber ein sinnvolles Sternnetz läßt sich damit nicht aufbauen. Für point-to-point wäre wiederum RTTY sicherer und einfacher.

Meine unbedarfte Meinung zu dem Thema, als jemand der die "schlimmen" Zeiten von PR noch erlebt hat. Heute ist ja nichts mehr los und zu 2-4 Leuten tut man sich natürlich leicht mit AX25 auf einer QRG. Aber .... Massenverkehr unter Notfallbedingungen ?? Bezweifele ich. Ich habe bei meine Kunden viel Planungsarbeit zu Netzwerken (Mainframe plus Sternnetze) gemacht und kenn noch die IT-Zeiten, wo 9600 eine high-speed Leitung war und 64k das non-plus-ultra. 1200 baud wurde nur bei Einzelplätzen eingesetzt. Bei 9600 sieht es etwas besser aus, aber da ist PR auch nicht auch allen Funkgeräten lauffähig.

73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]3. Oft ist nostagalische Technik die bessere und stabilere. Diese ist nämlich erprobt und eingefahren und es gibt genügend Leute, welche sich damit auskennen - solange man nicht mit IBM Lochkarten arbeiten will.[/quote]
Ja, mit EPROM´s, UV Lampen und DOS Treibern auf 3,5" Diskette, DIN 5 Steckern und RS-232 Schnittstellen, KISS, Jumpern und PAXON! :lol: Viel Erfolg! Den 486SX mit Phoenix BIOS hatte ich vergessen!


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Wieso DOS? Päckchenfunk habe ich damals mit CP/M gemacht ...

73 Werner


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hi,
mechanische Fernschreiber brauchen auch zu viel Strom. Raspberry und Software, dazu minimal Hardware Modem stelle ich mir als optimale Lösung vor. Dann könnte man "Software defined PR" machen..oder auch total andere Protkolle mal fahren.
Nf in/out sollte ausreichen, 9600 Bd können alte Geräte nicht. Wenns auf ner Trio2200 Quarzmühle läuft isses ok ;))
Ideal wäre auch ein Protokoll mit Quittierung das die Nachricht beim Empfänger zu 100% angekommen ist. Kollisionsvermeidung braucht man auch. Interessant wäre auch mal ne Zahl wieviel Meldungen z.b. in 5 Minuten durchgereicht werden müssen/können. Dicke Stationen dürfen schwache auch nicht dauerhafte wegpusten können...
Alte TNC dürfen nur eine Übergangslösung sein. Die werden früher oder später alle sterben.
Ein "Rundfunk" Kanal mit Durchsagen an alle wäre auch gut. Automatisches Routing wie bei TCP/IP Netzen wäre auch gut.
Idealerweise könnte man einen Knoten einfach vom Netz nehmen und alles läuft automatisch weiter ...
Ev. auch ne PGP Signierung von Nachrichten damit man keine "Fake News" im Netz hat.
Von daher seh ich PR 1200 als Startpunkt..der nochen gutes Stück vom Ziel entfernt ist.

73 de DL3FOX Uwe


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hallo Uwe, das Wort "Kollisionsvermeidung" ist die größte Täuschung der AX25 Benutzer überhaupt. Du kannst wegen der "hidden Terminal" Problematik keine Kollisionen vermeiden. Die ganzen Protokollabarten zielen lediglich auf eine Optimierung der Retries. Ein Primary/Secondary und/oder Polling-Konzept ist bei 1200 vom Overhead her tödlich. Bei APRS wird praktisch nur broadcasting gemacht, d.h. ein sessionloses Konzept für KURZE Nachrichten, was heute ja auch schon viele OMs versaubeuteln (Objekte und Baken wie: "mein Parkplatz", "meine Garage". "heute Pizza beim Italiener", "in 3 Wochen OV-Abend" und solange wird die msg wiederholt,.......). Mangels Acknowledge kannst die den UI-Frame Verkehr bei APRS nicht für Notfalldaten-Austausch nehmen, höchsten als Msg mit Ortsangabe, wo noch drei Verletzte liegen, aber ........ ohne Feedback.

Die alten Geräte sind teilweise sehr robust, weil früher viel mit Military-Standard produziert wurde. Die sterben weniger schnell als ein neuer China-Böller. Der ist ja oft nach drei Ladezyklen entweder taub oder abgeraucht --- jetzt etwas boshaft. Abgesehen davon: ich habe einen Collins mal vom Recyclinghof gerettet. Der stand im Freien im Regen, tagelang. Außer etwas "warme Zuwendung zum Trrocknen" hat dem nichts gefehlt. (War ein Todesfall Überbleibsel, die Familie hat alles verschrottet, Knatsch im OV, .....). So ein Ding überlebt einen EMP noch und funktioniert, falls dann noch Strom da ist.

Normales PR läuft Session orientiert, d.h. Du kriegst immer eine Bestätigung. Insofern ist die Idee schon gut. Wie gesagt, Problem ist mehr organisatorisch, weil nicht beliebig viele auf die AX25 QRG passen. Bei mehreren QRGs muß wieder irgendwo zusammen geführt werden. Ich war im BRK Rettungsdienst, ehrenamtlich auf dem NAW an Wochenenden. Eine Leitstelle mit PR kann ich mir nicht so recht vorstellen. Wenn ich heute ab und an noch mitkriege, wie FW, BRK und Pol sich in der Gegend herumschicken ........... Ist ja selten, aber immer wieder mal.

73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Guten Morgen,

bis vor kurzer Zeit war hier in meiner Nähe auch noch ein Node mit BBS ([url:2fexu82q]http://www.db0eam.de[/url:2fexu82q]) und Linkstrecke nach Kassel, den ich hin und wieder genutzt hatte. Leider musste die Antenne vom Turm und nun ist völlige Ruhe in Bezug auf PR. Jetzt hatte ich mir überlegt, mach doch selbst was und nimm eine BBS zumindest erst mal probeweise in Betrieb. Die Suche nach einer einigermaßen aktuellen Software dazu ist schon gescheitert. Den alten TNC2 den ich noch hatte und ein PR "Modem" habe ich auch nach längeren Versuchen nicht mehr zum Leben erwecken können. So sind beide im Müll gelandet.

Die aktuelle Konstellation sieht so aus. Dell Latitude E6500 Notebook, Windows 7, Soundmodem (UZ7OH oder DIREWOLF) und "Minimalinterface" ([url:2fexu82q]https://radioarena.co.uk/yaesu-c567.html[/url:2fexu82q]) an einem YAESU FT7900. Als Software verwende ich Easyterm ([url:2fexu82q]http://uz7.ho.ua/apps/easyterm39.zip[/url:2fexu82q]). Diese Konstellation läuft absolut stabil und fehlerfrei! Easyterm bringt sogar minimale "BBS Funktionalität" mit. Ob diese Konstellation für den hier beschriebenen Anwendungsfall ausreicht kann ich nicht sagen.


  
 

Sitemap Elektronikforum Elektroshop PostgreSQL Forum