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]Dann kannst Du aber mit gleicher Begründung PR ebenfalls vergessen. Wenn Du alte H/W-Lösungen nicht willst, bleibt Dir nur der PC mit einer S/W-Lösung ....... und da liegt der Teufel im Detail. Das mag ja noch preisgünstig sein, aber wenn es eine sichere Verbindung sein soll, ist es nicht mehr einfach. Es wird leider zu oft unterschätzt, welcher Murks bei PR passieren kann.[/quote]

Deswegen frage ich ja nach hier im Forum ;-) Eure fachliche Meinung ist mir ja ein wichtiger Input.

Aber Du musst doch zugeben, das die Wahrscheinlichkeit, das bei RTTY (nur zum Beispiel) einzelne Buchstaben verloren gehen oder verfälscht dargestellt werden ungleich höher ist, als bei einem PR, welches zumindest in Ansätzen eine Fehlerkorrektur durch Prüfsummen besitzt. Ein fehlendes Ebenen-Umschalt-Zeichen und der ganze Text kommt als Zahlen/Zeichen-Salat heraus. Aber eher ergiesst sich eine schlechte PR Verbindung in endloses Rejecten, als das in einem Datenpaket aus "300 Personen" plötzlich "3000 Personen" werden ;-)

[quote]Wie wäre denn PR, wenn man die Linkstrecken im DAMA-CSMA Betrieb aufbaut? Soweit ich mich da erinnern kann, kann man die Datendurchsatzrate damit deutlich erhöhen. [/quote]

Ich erinnere mich dunkel aus meinen früheren PR-Aktiv-Tagen, das es soetwas wie DAMA gab. Ausserdem meldet sich mein TNC3 mit DAMA Kompatibilität. Ein sehr guter Tip. Werde ich sofort in Angriff nehmen. Ich fürchte aber nur, das KISS-TNCs (wie beim PiGate) kein DAMA können werden. Aber so etwas lässt sich ja nachprüfen.

73, Guido


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
@dj1ng: ja, die checksum schützt begrenzt vor Übertragungsfehler, da ist Pactor besser, aber ...... das haben wir im Grunde durch diskutiert.

@DO6WAB: Ich habe meine alten Unterlagen und einige schnell greifbare Abhandlungen quer geblättert. DAMA wurde in den 90ern public, USA und Nordlink &Co. Ich habe mich damit nie anfreunden können und bin um die Zeit auch ausgestiegen. Man hat keine QSOs mehr fahren können, weil Mailboxbetrieb via Digipeater so ziemlich alles platt gemacht hat. Ich habe einige "ARRL Digital Communications Conference" Papiere aus dieser Zeit. 1995 hat WK5M dort Artikel zu DAMA geschrieben. Es gibt einiges über Polling aus der Zeit - das muß ich mir erst wieder zusammensuchen.. Das Hauptmanko ist aus meiner Sicht, das ein Master eine Liste führen muß und dann reihum mit Minimal-Paketen abgefragt wird. Diese Pollinglisten werden auch noch umsortiert (Prioritäten), je nachdem wie lange ein Station nichts zu senden hatte.

Es ist ein Rechenexempel, weil es nur einen Master geben kann, den alle hören müssen. Der Pollingverkehr selbst kostet Zeit, muß auch negativ beantwortet werden. Das führt dazu, daß Kollisionen vermieden werden (im DAMA-Bereich), aber mit wachsender "Slave"-Zahl steigt der Overhead bzw. die Wartezeit auf Erlaubnis und damit sinkt der Durchsatz (mit jedem zusätzlichen "Slave"). Bei 1200 ist es ein reines Rechenexempel, wann jemand in der Pollingliste wieder zum Zuge kommt. Im Mainframebereich hat man das Polling einzelner Stationen zugunsten "Gruppen-Polling" und Interrupt-Techniken relativ schnell aufgegeben (beides nicht auf PR übertragbar). Ich poste mal Tacheles dazu, wenn ich meine Unterlagen aus der Zeit wieder finde. Z.Zt. ist eh' aufräumen angesagt und Papierkram zu entsorgen, wenn als PDF verfügbar.

DAMA ist eine leichte Verbesserung, aber nicht das gelbe vom Ei. Es funktioniert im lokalen Bereich, d.h. "Sichtweite" (UKW) des Digipeaters (=Master), der dazu etwas komplexer im Betrieb ist und in begrenzter Anzahl an Stationen in einem LAN (wurde damals so betitelt).

Eine kleine Korrektur noch: Das Protokoll heißt richtig CSMA/CD (carrier sense multiple access mit collision detect). Ich habe mich vorher mit "CDMA" verschrieben. Eine Kollision wird i.d.R. vom TNC festgestellt, wenn nach dem Senden unmittelbar beim Umschalten auf RX (Simplex) eine (andere) Sendung läuft oder ein Bestätigungstimer abgelaufen ist.

Ich würde eher dazu tendieren, anstelle eines Digipeaters (mit oder ohne DAMA) ein gut positioniertes FM-Relais (mit Notstrom) nehmen - im normalen Relaisbetrieb mit normaler Ablage. Das hört ein weiter Umkreis und Kollisionen kommen allenfalls durch gleichzeitigen Sendebeginn, aber nicht mehr durch Hidden Terminals im allgemeinen. Da kann man auch durch Sprache um Funkstille bitten, wenn Daten laufen sollen. Außerdem .... Landkreis und Region gehen in die Fläche und via Relais muß man dann nicht unnötig Power machen. Vom Frequenzgang läuft 1200 PR auf einem FM Relais total sauber. (Konkurrenz zur D-Star & Co .... :-) ).

Ich blende mich leicht aus und rühre mich noch mal, wenn ich meine alte Rechnerei finde.
73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote][..]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.[/quote] Ergänzung hierzu: Wenn man über APRS Nachrichten als MSG verschickt bekommt man wohl ACKs: http://www.aprs.org/aprs11/replyacks.txt
Ausprobiert hatte ich das letzte Woche, als ich ein neues TNC-Kabel für das Siemens C5 gebastelt habe.
Am PC wurde [url=http://wiki.oevsv.at/index.php?title=DXL_-_APRSmap:1g47rg80]APRSmap[/url:1g47rg80] verwendet, Gegenstelle war ein Kenwood TH-D72 - das TH-D72 schickt automatisch ein ACK beim Eingang der MSG.

73, Sascha


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Nachtrag: Zwei Conference Artikel zu DAMA habe ich kurz per Suche im Netz wieder gefunden:
www.tapr.org/pdf/DCC1995-DAMA-WK5M.pdf
www.tapr.org/pdf/CNC1989-DAMA-DK4EG.pdf
Die Artikel sind etwa ähnlich und beschreiben das DAMA-Konzept. Es hat immer wieder Tests mit Protokollvarianten gegeben, vielleicht kriege ich mal eine Übersicht zusammen. Ein Beispiel ebenfalls aus 1989, m.W. nicht durchgesetzt:
www.tapr.org/pdf/CNC1989-PrioritizedAck ... t-N7CL.pdf
Für deutsche Infos bitte mit +dk4eg +dama in die Suchmaschine gehen (bei Yahoo als Beispiel).

Für DAMA wurden auch mit high-speed-Packet Simulationen zum Durchsatz durchgeführt. DAMA wurde von Nordlink in DL ziemlich verbreitet, aber ich habe mich mit meiner Gerätschaft da nicht mehr eingeklinkt. Es wurde auch nicht in alle Geräte integriert, die in den 90ern im Einsatz waren (ich meine speziell Funkgeräte mit integriertem PR). Für TNC gab/gibt es eine breite Palette von EPROM-Codes.

@Sascha: danke für die Info. Ich muß gelegentlich mal testen, wie das bei mir läuft. Ich bin sehr früh bei APRS eingestiegen (die DOS Verionen von WB4APR), die einige interessante Varianten für Fuchsjagden haben. Für Messaging war APRS eigentlich nicht entwickelt worden. Deine zitierte URL ist von 1999. Ich probiere es mal.

Messages waren für kurze Texte geplant und laufen session-los (kein connect). Für den Notfall-Datenaustausch ist connect mit session sinnvoller.

73 Peter (ich muß die nächsten Tage andere "Baustellen" abarbeiten, lese aber weiter mit).


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
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.


  
 
 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. ......[/quote]

Ich beobachte diese Diskussion auch mit demselben Hintergrund wie Du!

Ich hatte Mitte der 80er Einstiege auf 2 und 70 und auf KW ein Amtor-Gateway, sowie eine WX-Stn am rennen....

Falls von Interesse habe noch 2 TNC 2S , sowie ein MFJ1278 und einen Epson PX8 mit PR-Eprom
im Angebot .....


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]PR ist auf einem Stand von vor 20 Jahren! Ob so eine Technik "zukunftsfähig" ist,[/quote]

ZukunftsWEISEND vielleicht nicht, es ist jedoch erprobt, die Technik funktioniert und man kann inzwischen sehr zielsicher auch ohne spezielle Hardware damit arbeiten. Nebenbei bekommt man die TNC's heute nachgeschmissen und kann sich so ein billiges Netz aufbauen. Wehe, wenn was kaputt geht (Ersatzteilfrage) - ABER es funktioniert. Im Zweifelsfall inzwischen auch mit einem 0815-Notebook mit Soudkarte....


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]ZukunftsWEISEND vielleicht nicht, es ist jedoch erprobt, [/quote]
Ja, dass stimmt wohl, aber mich würden die bekannten Probleme hinsichtlich einer Lösung für den Notfall (wo eh alles drunter und drüber geht) eher abschrecken. Es geht ja nicht nur um den TNC von 1995, sondern ich brauche auch Hard- und Software sowie Treiber aus dieser Epoche. Wenn man PR seit seiner "Blütezeit" weiterentwickelt hätte, ok. Hat man aber nicht!

[quote]ABER es funktioniert. Im Zweifelsfall inzwischen auch mit einem 0815-Notebook mit Soudkarte....[/quote]
... wenn das olle Ding eine echte RS232 Schnittstelle für den TNC hat ja!


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hallo zu den letzten drei Posts: Im Prinzip habt ihr ja recht, aber .......... Ich habe mir aus Nostalgiegründen z.B. APRS QRG Quarze in meinen TR2200G gepackt, und mit einem TNC1 und PK232 wechselweise immer wieder gespielt. Natürlich habe auch Soundkarten-Digital (MULTIPSK, JVCOMM, ....... Mich hat immer schon interessiert, alt und neu zusammen zubringen, inkl. Dampfradio.

Zu den alten Geräten: Bis XP läuft alle S/W (DOS und Win-16bit) einwandfrei, ab Win7 geht DOS und 16bit Win nicht mehr ohne Hilfskrücke. Die serielle Schnittstelle läuft via USB/seriell-Adapter ebenfalls, man muß nur die Nummern 1-4 zuordnen, wenn es das Prigramm so haben will.

Es ist nach den 90ern noch einiges getan worden, Richtung TCP/IP -- aber die Basis ist im wesentlichen geblieben. Per TNC auf FM (AFSK) oder mit dem PK232 auf KW ist bei 1200 auf allen meinen alten Kisten kein Thema. Im Moment blättere ich gerade die Konferenz-Unterlagen durch und werde später noch URLs anhängen. Die Amis haben mit PR Notfunk gemacht, in den 80ern und 90ern. Die meisten Dokumente sind via TAPR.ORG online und eine quer-feld-beet Liste poste ich noch.

Es ist schon einer Überlegung wert, ob man die alte Technik nicht aufwärmt. Es kann ja auch mal so krachen, daß wir wieder Rauchzeichen oder Flaggenschwenken nutzen müssen :-) . Also ... alt, keine Teile, .... sehe ich etwas locker. Mein Zeug ist 30+ Jahre alt und tut noch. Das muß ein digitaler Chinaböller erst mal beweisen ..... (und da reparierst Du im Notfall auch nichts mehr, weil China weit weg ist). :-)

Mein Collins RX ist Baujahr 1951 und für RTTY heute noch ein Gedicht. Da haben die Chinsen keine Chance bei mir.

Etwas seriöser: Ob PR noch beim Crash was bringt, wissen wir alle nicht. Aber einmal Nachdenken, was es nutzen könnte, ist m.M. nach nicht verkehrt. Ich habe nur Bauchweh, weil das Hauptproblem bei AX25 nie die Technik war, sondern die Netztopologie mit der ganzen Organisation drum herum. Da ist viel Unsinn gemacht worden und mit der Behauptung "einfach senden, AX25 regelt das schon.." mehr QRM als QSOs auf den Frequenzen gewesen.

Ich melde mich wieder, habe noch ein paar Hefte zu lesen. 73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Es ist mir vollkommen klar, das ich hier mit "Retro-Technik" spiele und arbeite. Ich verstehe nur die Bedenken der Bedenknträger nicht ;-)

Wie ich bereits mehr als nur einmal festgestellt habe: Die Technik ist alt, aber funktionel gut zu gebrauchen, sie ist eingefahren und erprobt, die Vorteile, Nachteile und Schwächen (letztere dank dieser interessanten Diskussionen hier) bekannt.

In Sachen Notfunk MUSS man konservativ denken und arbeiten - und kann diese Arbeit vorsichtig mit modernen Technik koppeln: Ein TRX, gleich welchem Alter und Bauart & ein TNC (das sind die Oldtimer) kombiniert mit einem RaspberryPi und einem USB/RS232-Adapter (das sind die Youngster) ergeben eine hervorragende Kombination. Ein simples Terminalprogramm reicht vollkommen - und das ist auf jedem Betriebssystem vorhanden.

Man muss ganz sicher nicht immer das Neueste vom Neuen haben - das macht nämlich meistens Ärger ;-)
In meinem Notfunkgeräte-Bestand befinden sich zwei Telefunken FuG7b - Alter 30-40 Jahre - und die funktionieren IMMER NOCH - und die können IMMER NOCH eine Volldupex-Relais-Funkstelle im 4-Meter-BOS-Band stellen - etwas, das mit Amateurfunk-TRXen übrigens niemals funktioniert hat - zumindest nicht in der Bauform und Größe und ohne externen Topfkreis ;-) Das nur mal so am Rande zum Thema "veraltete Technik".

Aber nochmal zurück zur Technik:
[b:re80eb7o][i:re80eb7o]PR 1k2 geht tatsächlich über ein FM-Relais??? [/i:re80eb7o][/b:re80eb7o]

Das könnte eine gute Lösung sein - denn immerhin lassen sich Crossband-Repeater heute mit einer Menge Funkgeräte per Tastendruck realisieren - und würden dann noch nicht einmal ein TNC benötigen. Und ich schlage zwei Fliegen mit einer Klappe, denn FM-Relais benötige ich für den Sprach-Notfunk sowieso.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]
In meinem Notfunkgeräte-Bestand befinden sich zwei Telefunken FuG7b - Alter 30-40 Jahre - und die funktionieren IMMER NOCH - und die können IMMER NOCH eine Volldupex-Relais-Funkstelle im 4-Meter-BOS-Band stellen - etwas, das mit Amateurfunk-TRXen übrigens niemals funktioniert hat - zumindest nicht in der Bauform und Größe und ohne externen Topfkreis ;-)
[/quote]

Das funktioniert mit zwei Amateurfunk Funkgeräten + Weiche genau so bei der kleinen Leistung.
Die nehmen weniger Platz weg und benötigen weniger Strom.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hi,
ausserdem musst du bei 40 Jahre alten Gerät auch mit "Spontanausfällen" rechnen...
Du musst ja auch mal ne Zuverlässigkeitsrechnung machen.

73 de DL3FOX Uwe


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]ausserdem musst du bei 40 Jahre alten Gerät auch mit "Spontanausfällen" rechnen...
Du musst ja auch mal ne Zuverlässigkeitsrechnung machen.[/quote]

Zum einen "muss" ich gar nichts ;-) Ich weiss, das 40 Jahre alte Geräte genauso ausfallen können wie brandneue Geräte.
Zum anderen kennen ich aber die Schwachstellen meiner Geräte (egal wie alt) recht gut, und habe daher natürlich Ersatz "in der Schublade". Tatsächlich verlasse ich mich aber eher auf ein 40 Jahre altes Telefunken FuG 7b als auf ein brandneues Superhightech-Gerät ;-)

Aber darum geht es hier nicht in diesem Thread. Bitte kommt zurück zum Thema.

Meine letzte Frage war: 1K2 Packet Radio über FM-Relais-Funkstelle???


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Tatsächlich verlasse ich mich aber eher auf ein 40 Jahre altes Telefunken FuG 7b als auf ein brandneues Superhightech-Gerät [/quote]
Sorry wenn ich jetzt schreibe, dass das Wissen um das FuG 7b irgendwann mit deiner Generation untergeht. Ich kenne das FuG 7b schon nicht mehr und bin 56 Jahre alt. Ich komme immer mehr zu der Erkenntnis, dass im Bereich Notfunk nicht zu alte Technik zum Einsatz kommen darf. Das Konzept , welches Du erarbeitest, wirkt in die Zukunft und nicht in die Vergangenheit. Vielleicht sollte man doch besser auf "State of the Art" zurückgreifen.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Sorry wenn ich jetzt schreibe, dass das Wissen um das FuG 7b irgendwann mit deiner Generation untergeht.[/quote]Ich möchte Dich ungern enttäuschen werter OM, aber ich bin grob geschätzt 10 Jahr JÜNGER als Du ;-) Die Kentnnis "alter Technik" ist keine Sache des Alters, sondern des Interesses daran - und der Sache der (aktuellen oder ehemaligen) Tätigkeit in einer IuK-Einheit einer BOS - denn dort sind die Geräte mindestens bis zur vollständigen Abschaltung des Analogfunks noch im Einsatz - vorwiegend als Relaisfunkstellen bei besonderen Ereignissen (geplant oder ungeplant). Falls Dich das interessiert: [url:3kjunpvy]http://www.oppermann-telekom.de/sel-fug7b.html[/url:3kjunpvy] - eine schöne Beschreibung des Gerätes.

Aber jetzt endlich bitte wieder zurück zum Thema dieses Threads. Wer sich über BOS-Funktechnik, Althergebrachtes und so weiter gerne austauschen will, der darf sich gerne einer PN an mich befleissigen ;-)

Da das böse "SOTA" aber gefallen ist: Was ist denn bitte "state-of-the-art" für digitale Datenkommunikation via Funk?

Meine Anforderungen habe ich hier bereits deutchlich beschrieben - aber zur Sicherheit hier noch einmal ein Kurzform:

Zwischen verschiedenen BOS-Dienststellen, welche sich NICHT im Ausseneinsatz befinden sollen innerhalb mehrerer Landkreise Daten ausgetauscht werden - und zwar
[list:3kjunpvy]# grundlegend fehler- und betriebssicher[/list:u:3kjunpvy]
[list:3kjunpvy]# mit Amateurmitteln[/list:u:3kjunpvy]
[list:3kjunpvy]# zu halbwegs günstigen Anschaffungspreisen und Betriebskosten[/list:u:3kjunpvy]
[list:3kjunpvy]# Einfach und schnell aufzubauen[/list:u:3kjunpvy]
[list:3kjunpvy]# möglichst weitreichend und auch in bergiger Umgebung einsetzbar[/list:u:3kjunpvy]
[list:3kjunpvy]# soll sich trotz dem letzten Punkt auf 144 und 430 MHz abspielen (da hier nahezu jeder Funkamateur etwas zur Hand hat) [/list:u:3kjunpvy]


  
 

Sitemap Elektronikforum Elektroshop PostgreSQL Forum