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: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Meine letzte Frage war: 1K2 Packet Radio über FM-Relais-Funkstelle???[/quote]

Es SOLLTE funktionieren - ja. Wenn der NF-Frequenzgang weitestgehend linear ist im benötigten Frequenzbereich, sollte es funktionieren! Und die Ansprüche daran können nicht groß sein, weil ich zu CB-Zeiten (vor 20+ Jahren) selbst mal eine Zeit lang einen Teilzeit-Digipeater mit zwei völlig unterschiedlichen Geräten betrieben habe. Was halt greifbar war, wrude zusammengestöpselt. Hat gut funktioniert. Nicht nur bei mir.

Bei höheren Datenraten klappt das wohl eher nicht mehr - speziell ab 9k6 wirds haarig.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote].....
Aber nochmal zurück zur Technik:
[b:266frjk1][i:266frjk1]PR 1k2 geht tatsächlich über ein FM-Relais??? [/i:266frjk1][/b:266frjk1] [/quote]Definitiv ja, das habe ich ganz persönlich selber über DB0XF, einem völlig normalen FM-Relais mit meinem Trio 2200 im normalen Relais-Mode TX 145,600 RX 145,000 getestet und auf einem zweiten Gerät mitgeschrieben. Es läuft mit völlig normaler Ablageinstellung. Bitte dran denken: die PR NF-Frequenzen liegen bei 1200 im Durchlaßbereich und der TNC ist ein reines NF-Gerät. Der TNC weiß nicht, daß zwei HF.Frequenzen benutzt werden und DCD geht nur an, wenn auf dem Relais moduliert wird. Einzige Vorraussetzung war, daß ich DB0XF auftasten mußte und daß innerhalb der Abfallzeit gesendet wird. Bei reiner Trägertastung wäre es Null Problemo, mit Subtone wird es vermutlich nicht gehen (nicht getestet), weil vermutlich dann DCD angeht. Es hat im Test auch nichts ausgemacht, wenn jemand geredet hat. Dann geht DCD an und in der nächsten Sprechpause ist DCD weg und es wird gesendet. Der TNC ist sehr höflich, hi, und buttert niemanden unter. Es hat sich lustig angehört, jedenfalls für mich. "blablaba","brrrrrrr","blablabla","brrrr",..... allerdings wurde mir dann auch bedeutet, so langsam mit dem Test auf zu hören. Aber freundlich, es war abgesprochen und geplant, bis auf ein paar unwissende Zwischerufer "Welcher Idiot stört denn da dauernd??" :-) .

Mich hat es damals einfach interessiert, weil es bei offenem Relais keinen Grund gibt, warum es nicht gehen soll. Letzlich geht der TNC-Output auf den Mike-Eingang plus PTT wie beim Quatschen. Solange das Relais nicht abfiel, mußte ich auch nicht auftasten. Meine Mithörer haben immer wieder kurz dazwischen geredet und der TNC hat die Sprechpausen genutzt.
73 Peter

ps ich war heute unterwegs und konnte nicht eher. Sitze zwar oft am PC, aber nicht immer :-) .


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Mich beschleicht bei dieser ganzen Diskussion ein komisches Gefühl. Da will ein OM ein "Notfunkkonzept" auf Basis von 20 Jahre alter Technik für die Zukunft umsetzen. Ich habe jahrelang PR gemacht mit all seinen Vor- und Nachteilen. Das war aber vor mindestens 20 Jahren! Seitdem hat sich diesbezüglich nichts, aber auch wirklich nichts mehr weiterentwickelt. PR ist auf einem Stand von vor 20 Jahren! Ob so eine Technik "zukunftsfähig" ist, wage ich in diesem Kontext zu bezweifeln. DAMA CSMA/CD hin oder her.[/quote]

...eine Idee, wie man mit vielleicht "alter, aber bewährter" Technik Notfunk machen will, ist ja prinzipiell nicht schlecht und da ist es auch völlig egal ob das "zukunftsfähig" ist......wichtig ist ja nur dass es stabil und zuverlässig geht.
Was mich nur etwas gewundert hatte, PR über einen Repeater machen zu wollen - wenns doch mal richtig "scheppern" sollte werden wahrscheinlich keine Repeater mehr in Betrieb sein - zumindest schon bei einem flächendeckendem Stromausfall.

73 Mike


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Prinzipiell finde ich die Idee von Guido ok, was mich persönlich davon abhalten würde ist die Tatsache, dass sich in diesem Bereich die letzten Jahrzehnte nicht viel weiterentwickelt hat. Es gibt leider keine aktuelle Software mehr und aktuelle Hardware nur zu astronomischen Preisen es sei denn, man greift auf alte Hardware mit den bekannten "Mängeln" zurück oder ersetzt die Hardware durch Software. Zum einfachen Austausch von kleineren Nachrichten ist PR auch mit 1,2k sicher geeignet. Würde auch gern wieder mehr PR machen, aber hier ist weit und breit nichts mehr. Der letzte Node (DB0EAM) hat 2016 die Segel gestrichen. Ob der wieder reaktiviert wird, wohl eher nicht.

An aktueller Hardware gibt es diesen TNC hier der auch noch andere Modes beherrscht.
[url:1uurilzc]http://www.wimo.com/packet-radio-tnc_d.html[/url:1uurilzc]
PR über einen normalen Repeater hört sich auch spannend an. Hab ich noch nie ausprobiert. Könnte man ja mal testen. Bin sehr gespannt wie Guido das Vorhaben realisiert.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hallo Mike, ein Teil der Repeater hat sich schon mit Notstrom beschäftigt (bzw- die Verantwortlicher, :-) ).Das sollte in den Betreiber OVs eigentlich drin sein - irgendwer hat sicher ein Notstromaggregat für Fielddays & Co, der das Relais versorgen kann.

Ansonsten: Ich bin damals abgesprungen, als es "kompliziert" wurde. D.h. für meinen Standort kam der Digipeater auf dem Münchner Olympiaturm und auf 2m war für mich alles dicht. Dann kann der aus meiner Sicht untaugliche Versuch mit "DAMA" dazu und überall liefen nur noch Downloads und Mailboxes von irgend einem Knoten, was dann endgültig zu 9600 und Verlagerung auf 70cm führte. Auf 70cm habe ich Alinco und auf 2m Trio, die Mike Stecker für Alinco liegen heute noch rum (ausgenommen ein paar Jahre APRS mobil im PKW), ich hatte keinen Bock mehr auf PR. Man konnte keine QSOs mehr fahren und höchstens mit etwas linken Touren einen "Dauerbrenner" auf dem Digipeater ärgern. Der TNC1 (Original TAPR Bausatz) hatte hervorragende Einstellmöglichkeiten, die unterbrechungsfrei geändert werden konnten und am wirksamsten war ein disconnect, welches der Dauerbrenner wohl versehentlich sendete.. Aber ........ Asche auf mein Haupt, ..... und ein nachhaltiges Vergnügen war es auch nicht. Nur .... manche machten wirklich den Laden komplett über Stunden zu 99% dicht mit downloads.

Mit den alten TNCs und dem ursprünglichen Protokoll läßt sich problemlos in einer übersichtlichen Gruppe auch mit 1200 PR durchführen. Man benötigt dazu keinen separaten Digipeater, sondern muß nur ein paar Parameter einheitlich abstimmen, damit auch jeder oder einzelnen Digipeaten können. Das kann man anhand der Topologie bestimmen, weil im äußeren Bereich nicht digipeated werden muß (ist an- und abschaltbar) und in inneren Feld eine begrenzet Anzahl in guter Lage digipeaten können. Das war ja auch anfangs die Grundidee bei AX25, das sind die einzelen User zu gleichen Bedingungen per Digipeat unterinander vernetzen. Es ist ja erst pervertiert, als einige auf "Relais-artige Digipeater" angesprungen sind, mit großem Kollisionsbereich (Ironie !), dann dort auch noch Mailboxen angelegt haben und anschließend die Mailboxen als Datenbanken mißbraucht haben. Damit war PR kaputt, weil bis auf wenige Info- und Programm-Sammler niemand mehr Lust hatte, sich PR an zu tun --- QSOs gingen nicht mehr, Mail war im aufkommenden Internet einfacher, usw.

Boshafte Nebenbemerkungen -- so in etwa wird es heute mit HAMNET und DV wieder aus dem Keller geholt. Meine persönliche Meinung dazu, möglichweise auch nur ein Vorurteil, sorry.

Zum Thema: mit den alten TNCs vor DAMA, WA8DED Firmware war üblich, oder mit DAMA abschaltbar (damit man eben keinen Master für 12 Stationen braucht), wäre mit vernünftiger DIGIPEAT-Planung und entsprechenden Retry-Einstellungen unkomplizierter Betrieb möglich. Ich hatte im der letzten Version meines PK232, die PK232mbx Version, den µcode vom 19.7.1990 aktiv. Damit war der TNC fast zur eierlegenden Wollmilchsau geworden - PR, RTTY (Baudot & ASCII), Amtor A&B, Navtex-rx, FAX und CW. Für unser Notfunkthema insofern interessant, weil man auch mal FAX schicken kann (habe ich allerdings nie getestet) und auch RTTY/AMTOR ( KW und UKW getestet). Insbesondere ist für PR bei Kollisionen bzw. deren Vermeidung echter P-Persistant CSMA Betrieb implementiert und auch spürbar wirksam. Bei dieser Methode werden für den Retry Zufalls-Wartezeiten bestimmt (zufällige Anzahl von 10msec Slots), die der TNC bis zur Wiederholung wartet. (Details lasse ich weg, es spielent einige Parameter zusammen). Priority-Acknowledge ist auch möglich, lediglich DAMA kann diese Version noch nicht, aber Firmware ist verfügbar. Ich halte DAMA für diesen Gruppen-Betrieb jedoch für Unsinn und zu aufwendíg und unflexibel für diese begrenzte Anzahl von Stationen - vor allem auch im Hinblick von evtl. notwendigen Positionsveränderungen, insbesondere wenn das den Master treffen würde (wegen möglichem Verlust der Reichweite zu einzelnen Slaves, d.h. Topologie Probleme).

Ein FM-Relais wäre in einer solchen Topologie kein Digipeater, sondern erhöht nur ganz einfach die Reichweite der einzelnen Stationen - für Senden und Empfang. Es sollte nur wie bereits geschrieben im Ideal-Fall mit Trägertastung arbeiten (die Verzögerung läßt sich im TNC einstellen, Kombination von AU[x]delay und TXdelay, wird auch bei separator PA mit HF-Vox-Steuerung verwendet), oder große Abfallzeiten haben - und muß dann evtl. von PR-OP kurz manuell aufgetastet werden. Bei meinem Test lief es recht gut.

Mit der alten Kombination TR2200G (Quarzmühle), teilweise mit PA dahinter) und TNC1 oder PK232mbx habe ich noch lange Zeit APRS auf 2m gemacht und kann es jederzeit wieder aktivieren (nur TNC1 derzeit defekt).

Soweit vorerst mein Senf dazu, der Garten, Hund, XYL und Recycling-Hof ruft, Reihenfolge noch offen :-)
73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
In Verschnaufpausen als Nachtrag eine Seite aus dem technischen Manual des PK232, Teil eines Artikels von KA9Q als Scan-Kopie. Dazu ein Vorwort zu PR-Protokollen:

Die CCITT X25 recommendation deckt von der Norm her die untersten 3 OSI-Level ab: Physik, Link-Layer und Netzwerk (Routing, IP). AX25 hat mit (nur) Digipeating im 3. Layer die übrigen Ebene 1 und 2 mit geringen Modifikationen übernommen. In erster Linie ist die Adressierung anders - per Afu-Call - und die Nutzung von "unnumbered UI-Frames". Ansonsten kann man sich an der X25 Welt gut orientieren (Literatur) und vergleichen.

In der Ebene 2 wird HDLC-Protocol verwendet, allerdings in der LAP B Version (link access procedure balanced). Dies ist anders als bei der älteren LAP (ohne B, war/ist bei Mainframe in zentralen Strukturen üblich), in der bei "unbalanced" die "Leitungsenden" (Knoten) in Master/Slave-, Primary/Secondary-, bzw. DCE/DTE-Modus arbeiten (gleicher Sinn, nur unterschiedlichen Namen). Bei LAPB wird zum Verbindungsaufbau (connect) als erstes ein SABM (set asynchron balanced mode) gesendet, egal ob DCE oder DTE. Im weiteren Verlauf der "session" (connected Status) unterhalten sich beide Stationen gleichberechtigt, gesteuert via wechselseitigen Stati-Veränderungen. Diese Gleichberechtigung ist eine eigens für Amateurfunk gewählte Prozedur-Variante. Server/Client ist ein Begriff der oberen OSI-Ebenen (5-7) und hat mit Layer 2 LAP/LAPB nichts zu tun.

Mit DAMA macht man aus meiner Sicht einen Rückschritt in die späten 70er - frühen 80er Mainframe-Jahre zugunsten einer kontrollierten (unfreien) Kommunikation via dominanter Netzknoten mit allem möglichen Pipapo (via Polling nach Listen). Alles nur, um auf UKW Reichweiten zu erzielen, die man auf KW fast schon geschenkt kriegt. Digipeating ist außerdem keine großartige technische Herausforderung, sondern wird via Monster-Digipeater für diese nur zu einem Massengeschäft, welches seit den 70ern technisch beherrscht wird (und uninteressant ist).

Durch die Kollisionen bei CSMA (Ethernet oder Funk) ist ohne Protokoll-Kunstgriffe bei etwa 36% Netto-Datentransfer Feierabend. Der Rest sind Retries durch Kollisionen. Mit P-Persist kommt man immerhin schon an >50% heran. Ich bin noch am Aufräumen meiner alten Unterlagen und Studien aus den 80ern. Eine gute Erklärung dazu lade ich mal hoch - eine Seite aus dem PK232 Tech.Manual. Nach meiner Meinung und bisherigen Erfahrung würde für eine nach DJ1NG beschriebene Gruppe (12± Stationen) mit der P-Persit Implementierung in jedem PR-Knoten ausreichend sein und keine Master/Slave Implementation erfordern.

Wenn ich meine praktischen Beispiele zu dem Thema wiederfinde, trage ich es hier nach. 73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Was mich nur etwas gewundert hatte, PR über einen Repeater machen zu wollen - wenns doch mal richtig "scheppern" sollte werden wahrscheinlich keine Repeater mehr in Betrieb sein - zumindest schon bei einem flächendeckendem Stromausfall.[/quote]

Es kam dieses Thema hier auf und es klingt interessant. Selbstverständlich gehört dazu, das die Repeater auch Notstrom-fähig sind. Zudem werden aber die ganzen FM-Umsetzer wohl doch eher für Sprachbetrieb im Notfall gebraucht werden. Aber alleine die Tatsache, das man problemlos 1k2 PR über einen FM-Umsetzer fahren kann ist etwas, was man unbedingt im Hinterkopf behalten sollte. Wer weiss, wann einem das mal nützlich sein wird ;-)

Ansonsten: Danke werte OMs für eure detaillierten Beschreibungen. Sie sind sehr nützlich für mich und ich habe mir alles gut hinter die Ohren geschrieben.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Ich möchte es nur noch mal betonen: auch im Sprachbetrieb kann PR ohne besondere Eingriffe auf dem FM-Relais mitlaufen, wenn für die PR-Übertragung eine Sprechpause eingelegt wird. Das kann ähnlich wie im BOS laufen, wenn die Leitstelle Funkstille für eine Alarmierung einfordert. An der PR Station braucht nichts besonderes beachtet werden, weil DCD erst weggeht, wenn Ruhe auf dem Relais ist (NF-Ruhe, Relais nicht abgefallen und betriebsbereit). Damit sendet der TNC auch erst ab "kein DCD-Signal" --- und wird mit der entspr. Einstellung nie über Sprache drüber bügeln. (getestet) Das würde sicher auch im Notbetrieb gehen, weil dann wohl kaum Dauerreden geschwungen werden.

Das Problem ist vermutlich nur, daß ausgebildete und erfahrene Funkamateure für das Sprachkommando "Funkstille" trotzdem eine besondere Schulung brauchen (es wird todsicher mit 10 msec QRX verwechselt, wenn ein Contester den OP macht). :-) und *duck*

73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Im Zusammenhang mit "Emergency" zufällig heute Morgen entdeckt.

[url:2509ygtn]http://www.crosscountrywireless.net/digital_messenger.htm[/url:2509ygtn]
Download
[url:2509ygtn]http://www.crosscountrywireless.net/CCW%20Digital%20Messenger%20v1.17.zip[/url:2509ygtn]


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Mercie vielmohls.

Das klingt mehr als nur interessant. Zu testen wäre es, wie das Ganze auf VHF/UHF funktioniert (wenn ich mich recht entsinne war bspw PSK nicht für UKW geeignet) - aber es könnte tatsächlich eine Alternative sein. Ich werde das meinen Mitstreitern einmal unterbreiten!


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]http://www.crosscountrywireless.net/digital_messenger.htm[/quote]

Wir haben uns das ganze mal angesehen. Es ist eine nette Geschichte und kommt vielleicht zum Tragen, wenn das Winlink-Netz nicht mehr verfügbar sein sollte - also als Rückfallebene für die Rückfallebene ;-)

Der Raynet-Messenger ist tatsächlich genau das, was der Name verspricht. Es fehlt aber eine wichtige Komponente: nämlich "Store (& Forward)" - welche bei WINLINK und Packet Radio durchaus vorhanden und dessen Vorteile nicht zu unterschätzen sind ;-) Selbst ein simples Packet Radio TNC (mein Steckenpferd, ihr wisst) kann schon Nachrichten automatisch entgegen nehmen und und diese speichern - und das ganz ohne angeschlossenen Computer. Sollte man es auf die Spitze treiben in Sachen PR richtet man sich ein (zwei drei) Nodes (BPQ) mit Mailboxen (FBB) ein. Das geht phantastisch mit dem Raspberry PI und einem angeschlossenen USB-Stick - womit wir wieder den Anschluss an modernen Technik gefunden haben.

Die Vorteile von WINLINK, welches ein echtes "FORWARD" bietet, liegen natürlich auf der Hand, sollen aber hier nicht diskutiert werden.

Beste Grüße,
Guido


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Ich habe im Keller noch so einen FUTRO Mini PC rumfliegen. Die gibt es ja mittlerweile für um die 20.- € Wenn es dazu noch eine aktuelle Mailbox Software (BBS) gäbe, hätte ich so was schon lange in Betrieb. Leider hab ich bis heute nichts gefunden. Soundmodem drauf, Schnittstelle von RadioArena dran und los geht's.

[url:vojbl6ak]http://www.ebay.de/itm/THINCLIENT-MINI-PC-FSC-FUTRO-A230-TR2350-S26361-K525-V230-GIGABIT-LAN-RS-232-USB-/310807610911[/url:vojbl6ak]


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Unter DOS / XP gibt es genug hier:
http://deltalima.org/doku.php?id=pr_soft


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

danke für den Link. Da sind aber überwiegend "olle Kamellen" dabei also nichts wirklich Aktuelles. DOS scheidet für mich kategorisch aus, unter Windows XP/7, 32 Bit sollte die Software schon ohne Simulation/Emulation fehlerfrei laufen. Meiner Meinung nach gibt es im Moment nichts einigermaßen Aktuelles im Bereich PR oder gar BBS. Leider nur uralter Kram! :(


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Ich habe mir meine alte Lieblingssoftware SP 9.75 installiert - welche übrigens hervorragend in der "DOS-Box" von Windows 7 läuft (also einfach von der Kommandozeile aus gestartet). Damit funktieniert das einwandfrei.
Ebenso sauber läuft SP unter FreeDOS, welches ich auf einem ehemaligen Windows-XP-Mini-PC installiert habe.

Auch wenn es damals einen ziemlichen Krieg um SP gab (aufgrund dessen sich der Autor DL1MEN übrigens das Leben genommen hat) halte ich SP für die beste Packet Radio Software überhaupt. Aber das ist meine persönliche Meinung und ich bitte darum, diese nicht zu "verdiskutieren".

Ich kann SP 9.75 auf jeden Fall empfehlen wenn man z.B. mit TNCs experimentieren möchte (so wie ich). Es läuft unter den geringsten Hadrware-Anforderungen und mit lizenzfreien Betriebssystemen genausogut wie auf modernen Hardware mit proprietären OS. Es untestützt Symek TNC3s (also doppel-Modems). Die Installation ist etwas tricky, aber schnelle erledigt. Schade ist nur, das kein Handbuch dafür mehr aufzufinden ist, denn SP 9.75 hat extrem viele Konfigurationsmöglichkeiten, wenn man sich da rein arbeiten will. Es bietet sogar eine Mailbox-Funktion ;-)

[url:19ny9tbn]http://www.deltalima.org/prdownload/sp/sp975.zip[/url:19ny9tbn] - Das Programm wird übrigens bei Deltalima.org fälschlicherweise als "SuperPacket" bezeichnet :-D

Wenn man ein echtes TNC mit NORD><LINK Firmware hat, reicht aber auch irgendein Feld-/Wald- und Wiesen-Terminalprogramm, welches in der Lage ist, ein ESC- und CR-Zeichen zu schicken. Windows-Hyperterminal ist da durchaus brauchbar und läuft sogar unter Windows 7 (und angeblich auch unter 10).

Ich würde nicht damit rechnen, das es aktuelle Packet Radio Software gibt. In den letzten Jahren hat sich wohl alles auf APRS konzentriert und echte Kommunikation über PR ist in Vergessenheit geraten.


  
 

Sitemap Elektronikforum Elektroshop PostgreSQL Forum