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




 [ 27 Beiträge ]  Gehe zu Seite 1, 2
Autor Nachricht
 Betreff des Beitrags: AX.25 Frame
Ich bastle grade ein bischen mit Packetradio rum. Leider habe ich nicht die möglichkeit ein "reines" AX.25 mitzulogen.
Kann mir jemand ein komplettes Frame posten(inhalt egal)
von Start(0x7E) bis zum Stop(0x7E) Byte.

In ersterlinie gehts mir um die FCS CRC Checksumme. Ich hab mir ein Programm programmiert und will mal das AX.25 Frame reinstecken und schaun ob die gleiche Checksumme dabei rauskommt oder ob ich einen gedanken/rechen oder prgammierfehler drin habe.

vy 73 de
Markus


  
 
 Betreff des Beitrags:
Der zugrundeliegende Layer von AX.25 ist HDLC.

Eine HDLC-Implementation sollte sich als OpenSource im Netz finden lassen.

73!

Sven


  
 
 Betreff des Beitrags:
abschreiben kann ja jeder :-) ich will das rad eben neu erfinden :-)

wollte nur noch ein frame "reinschieben" und schaun ob das mit der checksumme passt.


  
 
 Betreff des Beitrags:
Dein neues Rad fängt schon bei der Frage an:

die Flagbytes x'7e" sind Blockbegrenzung, die siehst Du nur mit Hardwaretools direkt auf der Leitung bzw. entsprechenden Analyzer für Funk. Die FCS bits (16) werden per Polynom OHNE beide x'7e' erstellt. -- seit "Urzeiten" das gleiche Verfahren Division modulo 2 durch Schieberegister.. Außerdem gehören die Spezifikationen zu AX25 Ebene 2 = HDLC (siehe dj2at). Je nach Meßverfahren ist zu beachten, daß per Bit-Stuffing bits eingeschoben werden, die beim FCS nicht mitzählen. Du brauchst also ein Frame, das vom Modem bereits korrekt ohne Framebegrenzung x'7e und ohne stuffing das abgesendete Frame decodiert hat. Ich bin mir nicht sicher, inwieweit moderne Soundkarten-SW diese Diagnose zuläßt. Bei meinem TNC1 und PK232 gibt es Möglichkeiten, aber da muß ich erst wieder in's Manul gehen, ab wann das Frame getraced wird.

Für Deine Kontrolle kann ein Trace/Dump (in hex) des Frames gemacht werden, die normalen Monitor Logs nutzen Dir nichts. So etwas (hex trace oder bufferdump) habe ich nur sehr selten gemacht, wenn undefinierbare Probleme auftraten. Wenn nicht zufällig jemand so etwas noch gespeichert hat, wirst Du etwas Geduld brauchen. Ich kann gelegentlich APRS mitlaufen lassen und einen Teil einstellen -- (Trace) wo immer der gezogen wurde.

73 Peter


  
 
 Betreff des Beitrags:
genau so ein dump suche ich wo das scrambeln(fals 9k6) und das bitstuffing schon erledigt ist.


  
 
 Betreff des Beitrags:
Bitte etwas Geduld, schaffe ich vermutlich erst am Wochenende -- bin nur 1200 QRV, den Rest habe ich mir nicht mehr angetan und wegen der Müllboxen mache ich es erst recht nicht, 1200 Hex-Trace sollte gehen, aber heute nicht mehr.
73 Peter (X25 von Anfang an im QRL mit gemacht und Packet dann auch)


  
 
 Betreff des Beitrags:
kein stress,

danke schon mal :-)


  
 
 Betreff des Beitrags:
Ich habe einen kurzen Versuch mit dem PK232 gemacht und lade die kleine File hoch. Hat gleich auf Anhieb geklappt und war ein guter Alzheimer Test -- da hat er noch nicht zugeschlagen.Es ist ein klassischer Trace mit dem PK232 als "dumb terminal" -- entspricht dem TNC1 Standard - der kann das gleiche Format.

pk060510.log 28673 bytes. ..url = .. http://www.mydarc.de/db6zh/pk060510.log
(ich lasse die da ein paar Tage stehen und putze dann wieder, schreib mir, wenn Du die downloaded hast. Mit der Extension kann ich die hier nicht appenden und als Text posten muß eigentlich auch nicht sein.)

Ich habe am Anfang mit **** kurzen Kommentar eingeschoben. Du müßtest Dir per "quick und dirty script" die linken HEX bytes (16 pro Zeile) wieder auf 8bit bytes convertieren, dann hast Du die Original-msg zwischen den Flagbytes. Es steht in den Handbüchern nicht explizit drin, aber ich gehe davon aus, daß FCS nicht unterdrückt ist. Die rechten zwei Teile sind "Klartext" in 7bit-bytes, einmal die linken 7 (Header "lesbar"), und dann die rechten 7 (Daten "lesbar"). Gesendet wird wie im Hex Format 8bit-weise.

Es sind etwa 7 Minuten auf der 144.800, war nicht viel los. Etwa von 15.52.30 bis 15.53.46 habe ich "PASSALL" aufgemacht, dann läßt er alles durch -- auch kaputte Packets. Es sind etwa 30 Einträge in der Zeit, vielleicht sind auch fehlerhafte FCS dabei -- habe ich nie nachgeprüft, ob er die bei PASSALL durchläßt. Steht auch nicht explizit im Manual. Wäre mal ein Nebeneffekt von Deiner Tüftelei -- schreib mal, was rausgekommen ist.

Ich habe die ganze Entwicklung DFV im IT Bereich (Hersteller) seit den 70ern mit gemacht und später die erste BTX (Anbieter) Pilot-Installation in DL beim Kunden mit betreut, die hat auf X25 Verbindungen basiert. War mit Post und unsren IT-Laborleuten mit mancher durchgemachten Nacht und Wochenenden verbunden. Außerdem entspricht dieser Trace klassischen Line-Tracen bei allen Verbindungsarten (Start-Stop, BSC, SDLC, HDLC etc.) und ist fast schon bei mir eingebrannt. Für solche Trace Auswertungen habe ich mir teilweise wegen der Menge Auswertungsprogramme selber schreiben müssen, heute gibt es für alles ein "Tool". Vermutlich ähnlich wie Du es jetzt machst, ich habe dann auch die Timestamps und Headerfehler ausgewertet. Daten sind an sich uninteressant, und FCS Fehler haben bereits die ältesten chips gemerkt und das als Line-Error moniert mit entpr. code moniert. (Die habe ich nie nachrechnen müssen, aber z,Bspl entspr. Error-Msgs aus dem Stream fischen müssen). War ganz interessant, außer den ungewöhnlichen Arbeitszeiten, meistens als last Level Support mit den "Laborleuten Bits gezählt".

Wenn Du fertig bist, erzähl mal, was Du Neues erfunden hast -- bin einfach neugierig.

73 Peter


  
 
 Betreff des Beitrags:
Datei habe ich runtergeladen Danke.
Was es wird weiss ich noch nicht genau :-) Und wenn es was wird stell ich es hier auf alle fälle vor.
Primär ist es für meine grauen Zellen.

Und was meinst du mit Convertieren, die HEX werte passen ja, ist ja kein ASCII sondern um ein Bit gedreht.

Die CRC sollten die letzten 16 bit sein invertiert und gedreht aber das soll ja dann mein testprogramm rausfinden. ich werde berichten.

ps wenn mal was on air gehen sollte, schweitenkirchen sollte ich problemlos anfunken können :-)

NACHTRAG:
es ist leider keine checksumme mit dran


  
 
 Betreff des Beitrags:
Ja habe ich befürchtet, es hört alles mit Standardendungen auf. Ich habe heute den alten TNC1 wieder flott gemacht bzw. nach längerer Pause wieder mal benutzt. Er hat ein paar spezifischere Traceangaben. Aber auch dort ist zu oft x'0D am Ende, es sieht genau so aus. Auch in ein paar aufgehobenen älteren TAPR Traces von 1987 (ich habe die Firmware später auf WA8DED hochgezogen) sieht es nach "ohne FCS" aus. Bleiben halt nur noch die Soundkarten-Freaks -- werde es bei den vorhandenen Programmen mal versuchen.

Mit der Bit-Dreherei mußt Du etwas aufpassen: Ich bin als IBMer (retired) etwas "ISO-geschädigt". Es nervt manchmal bei Diskussionen, weil die Darstellung identisch ist, nur ISO zählt nicht von "links nach rechts" bzw. erstem ankommenden Bit sondern nach der Wertigkeit. Diese Trace-Bits sind NICHT "Intel-verdreht", sondern so wie sie (zeitlich) ankommen von links nach rechts -- wie Du sie bezeichnest ist wurscht. Die Wertigkeitsnummerierung ist eigentlich nur bei Intel-Adressierung im Speicher üblich. Man muß etwas aufpassen, welche Chips dahinter stecken und was gemacht wurde. Es ist manchmal bei den Normen ein echter Krampf passiert, weil man etwas "anders" sein wollte und ja nicht vom Hersteller abhängig.

Im TNC ist ein WD1933B HDLC Controller drin, der vom Modem Input kriegt. Ich suche mal nach Unterlagen, evtl. behält der ebenso wie die Flags auch FCS und meldet nur ok Ja|Nein. Wenn ich was finde, poste ich wieder.

73 Peter


  
 
 Betreff des Beitrags:
Hier eine Übersicht über das AX.25 Protokoll vieleicht hilfts dir ja weiter:
[url:6li1buzk]http://db0fhn.efi.fh-nuernberg.de/jann/amateur/hamstuff/ax25d.txt[/url:6li1buzk]

Hier ausführlicher:
[url:6li1buzk]http://www.tapr.org/pdf/AX25.2.2.pdf[/url:6li1buzk]


  
 
 Betreff des Beitrags:
@Rathma: ich habe mein einziges Soundkartenprogramm MULTIPSK (von F6CTE, registrierte Version 4.16) mal für Packet/APRS getestet -- ist eigentlich mehr für KW-Digimodes angeschafft worden. Der kleine Obulus lohnt sich, das kann sehr sehr viel.

Leider ..... ich habe FCS Prüfung abgeschaltet (option) und es hilft Dir auch nicht weiter. F6CTE blendet zwar im "Dump-Modus" die Flags ein als $ (Anfang) und Pfundzeichen (x'A3', Ende), ersetzt aber korrekte FCS mit #[CR][LF] und fehlerhafte mit ! (Ausrufezeichen). Die Version ist allerdings recht informativ, weil man sieht wie die Kollisionen die Packets zerfetzen und mancher PR User ein relativ schlimmer Finger ist. (Bei einem OE.... reicht das retry-delay gerade mal für 3 flagbytes -- und das ist schon sehr rüpelhaft).

Dir hilft das leider auch nicht und damit muß ich mit meinem Equipment passen, keiner schreibt das FCS raus. Den TNC1 habe ich sogar noch mit einem Adaptertool "zu Fuß" getestet, der liefert FCS gar nicht erst bei der COM Schnittstelle ab -- im Hostmode habe ich den noch nicht getestet -- muß ich erst das Programm dazu wiederfinden. Der läuft mit WA8DED Firmware so gut, das ein Terminalprogramm reicht, das Host-Programm liegt irgendwo vergraben rum. Also erst mal Sendepause bei mir. Alte QRL Papier- Lehrbücher (mit evtl. Beispielen) nutzen auch nichts (garnicht erst gesucht), weil das alles in EBCDIC Code war. ASCII ist einfach zulange her und wurde nur bei sehr wenigen Terminals zur Hostverbindung benutzt.

@Bernd: rathma hat sich eine Programmroutine für den Frame-Check Algorithmus geschrieben und möchte die gerne mit praktischen Beispielen (PR-Frames) testen. D.h. er braucht eine Mitschrift von PR/APRS inklusive der beiden FCS bytes. Bei mir wird vom TNC1, PK232 und Multipsk (soundkarte) zwar alles perfekt ausgegeben, aber ausgerechnet das FCS Feld nicht.

73 Peter

(Rathma, das hat sich jetzt für mich als Gerätetest auch gelohnt und ich habe ein paar Trümmer (Unterlagen) wiedergefunden, die ich schon länger vermißt hatte, .. :-) ..)


  
 
 Betreff des Beitrags:
trozdem danke für deine hilfe.

ich werd mir jetzt einen logicanalysator basteln und einfach mal zwischen modem und trx mitloggen, die daten muessen ja nur entscrambet und zurück zu nrz convertiert werden und vielleicht die eine oder andere 0 nach fünf 1 raus fertig :-)


  
 
 Betreff des Beitrags:
Hallo Rathma,

bin mal vor längerer Zeit über [url=http://www.stensat.org/projects/FX-25/FX-25_performance.htm:1podbmu4]Folgendes[/url:1podbmu4] gestolpert, da gibt es auch AX.25 Rohdaten dabei. Leider kann ich nicht beurteilen, ob das an der Stelle abgegriffen wurde, die Dich interessiert.

Mich hat es hauptsächlich wegen der Fehlerkorrektur (Reed-Solomon) interessiert, dachte man könnte die Daten auf dem Weg zum TNC einfach ein- bzw. auswickeln... Habe es aber nicht sehr weit gebracht, andere Dinge waren wichtiger ;(

Viel Erfolg
Hermann-Josef, DC2IP


  
 
 Betreff des Beitrags:
schaut gut aus, werde heute nachmittag berichtgen


  
 

Sitemap Elektronikforum Elektroshop PostgreSQL Forum