suche Paketrohdaten
Martin Laabs
ich schreibe gerade die Firmware für mein Paketmodem.
Da ich nicht weis ob ich die Daten richtig empfange oder ob
meine Dekodierroutinen falsch sind (Sync-Erkennung, Scrambler,
Differenzdekoder, Bit-Stuffing etc.)
suche ich Rohdaten, wie sie aus dem Demodulator
herauskommen, um die Software damit zu testen.
Idealerweise sowohl die Rohdaten als auch das was
raus kommen soll.
Hat jemand so etwas oder weis jemand wo man sowas her bekommt?
Danke
Martin L.
Ralph A. Schmid, DK5RAS
>Hat jemand so etwas oder weis jemand wo man sowas her bekommt?
Hast Du keinen digipeater in Hörweite? Das sollte doch der einfaschste
Weg sein...
>Danke
regards - Ralph
--
Want to get in touch? http://www.radio-link.net/whereisralph.txt
Hans Georg Giese
Martin Laabs wrote:
> Hallo,
>
> ich schreibe gerade die Firmware für mein Paketmodem.
schön. Mal wieder jemand, der nicht nur redet sondern handelt.
> Da ich nicht weis ob ich die Daten richtig empfange oder ob
> meine Dekodierroutinen falsch sind (Sync-Erkennung, Scrambler,
> Differenzdekoder, Bit-Stuffing etc.)
> suche ich Rohdaten, wie sie aus dem Demodulator
> herauskommen, um die Software damit zu testen.
nimm einen normalen TNC und verwende dessen Ausgangssignal. Dann hast
du eine Kontrolle darüber, wann was kommt. Welche Baudrate kann
dein Modem denn?
>
> Idealerweise sowohl die Rohdaten als auch das was
> raus kommen soll.
>
> Hat jemand so etwas oder weis jemand wo man sowas her bekommt?
>
> Danke
> Martin L.
73, Georg, DF2AU
Martin Laabs
>>Hat jemand so etwas oder weis jemand wo man sowas her bekommt?
> Hast Du keinen digipeater in Hörweite? Das sollte doch der einfaschste
> Weg sein...
Das Problem ist folgendes. Sowohl Modem als auch Software sind
von mir selber gebaut/geschrieben und damit Fehlerkanidaten.
Von dem Modem bekomme ich eine Bitschlange mit den Rohdaten
die der jeweiligen Frequenzumtastung entsprechen.
Diese müssen relativ aufwändig dekodiert werden bevor man
überhaupt erkennt ob man was sinnvolles Empfangen hat.
Im Moment kommt dabei bei mir keine richtigen Daten an.
Deswegen wäre es das einfachste, wenn jemand irgendwo solche
Rohdaten, wie sie mein Modem liefert, hat, damit ich meine Software
testen kann. Denn es macht ja wenig Sinn den Fehler in der Hardware
bzw. bei den Parametern des Modems zu suchen wenn die Software
fehlerhaft ist.
Tschüss
Martin L.
Martin Laabs
> Moin,
> Martin Laabs wrote:
>> Hallo,
> nimm einen normalen TNC und verwende dessen Ausgangssignal. Dann hast
> du eine Kontrolle darüber, wann was kommt. Welche Baudrate kann
> dein Modem denn?
Das Problem ist das ich kein TNC habe und auch nicht weis wie ich
dem TNC die Rohdaten entlocken kann.
Was ich brauche ist die Frequenzumtastinformation. Also eine 1 für
die eine und die 0 für die andere Frequenz.
Ich weis nicht ob das TNC nicht schon zu viele Verarbeitungschritte
intern macht. (Descrambling, Bitstuffing etc.)
Mein Modem beherscherscht alle gängigen Baudraten zwischen 9k6
und 76k8 Baud. Aber die unterscheiden sich ja nur in der Geschwindigkeit
und nicht im Protokoll.
Tschüss
Martin L.
Hans Georg Giese
Martin Laabs wrote:
...
>
> Das Problem ist das ich kein TNC habe und auch nicht weis wie ich
> dem TNC die Rohdaten entlocken kann.
TNCs kann man für kleines Geld schnell aufbauen oder gebraucht kaufen
oder sogar ausleihen.
> Was ich brauche ist die Frequenzumtastinformation. Also eine 1 für
> die eine und die 0 für die andere Frequenz.
> Ich weis nicht ob das TNC nicht schon zu viele Verarbeitungschritte
> intern macht. (Descrambling, Bitstuffing etc.)
Schaltbild und Firmware des TNC2 sind Public Domain.
Die SIO macht aus 8 Bit Daten die HDLC Daten (Framing, Bitstuffing). Das
normale (DF9IC, G3RUH) Modem macht Scrambling. Je nachdem, wie "roh"
du die Daten gern hättest, mußt du anzapfen. "Ganz roh" gibt es dann
aber nur, wenn man die SIO umprogrammiert.
Noch ein Hinweis: es gibt auch eine Version der Firmware, die
auf einem PC an der seriellen Schnittstelle mit einem KISS-TNC redet.
Die könnte man schnell umbauen, daß sie die Rohdaten z.B. via Druckerport
auf ein 8 Bit Schieberegister gibt. Das wäre dann wieder ein Bitstrom.
Wenn man das unter DOSE und nicht unter WINDOOF laufen läßt, sollte es
passabel gehen. Oder man schreibt die Daten einfach in ein File :-)
>
> Mein Modem beherscherscht alle gängigen Baudraten zwischen 9k6
> und 76k8 Baud. Aber die unterscheiden sich ja nur in der
> Geschwindigkeit und nicht im Protokoll.
Kannst du bitte mal ein paar Details zum Modem geben? Klingt
interessant.
>
> Tschüss
Hermann Boehm
Martin Laabs schrieb:
> [...]
> Das Problem ist das ich kein TNC habe und auch nicht weis wie ich
> dem TNC die Rohdaten entlocken kann.
> Was ich brauche ist die Frequenzumtastinformation. ...
Hallo Martin,
womöglich wäre das ...
http://www.qsl.net/dj4uf/funktechnik/soundmodem/soundmodem.htm
... oder ähnliches geeignet?
73 de Hermann, DK6XH
Martin Laabs
> Moin,
> du die Daten gern hättest, mußt du anzapfen. "Ganz roh" gibt es dann
> aber nur, wenn man die SIO umprogrammiert.
Ich habe es mittlerweile hinbekommen. Was mich irritierte waren
die exorbitant langen Syncronisationssequenzen.
> Kannst du bitte mal ein paar Details zum Modem geben? Klingt
> interessant.
Es ist im Moment nur ein Prototyp. Basiert auf dem Chip CC1020
welcher einen hochwertigen FSK Transceiver beinhaltet. Eigentlich
für das ISM Band gedacht, beherscht er auch dem Amateurbereich.
Ich habe um den Chip noch eine schnelle PIN-Dioden Umschaltung
und einen 7W Verstärker drum rum gebaut.
Das schöne ist, dass sman nicht mehr ein TNC mit Handfunkgerät braucht
(was ne ewige Pfrimelei und zudem noch sehr teuer ist), sondern
nur ein Gerät welches auf Anhieb funktioniert.
Dazu relativ universell (1k2-153k8 FSK, kein AFSK) und evt. sogar eine
FM Demodulation).
Die Bauteilkosten lagen so um die 70Euro für mein Einzelstück.
Tschüss
Martin L.
Ralph A. Schmid, DK5RAS
>
>Das Problem ist folgendes. Sowohl Modem als auch Software sind
>von mir selber gebaut/geschrieben und damit Fehlerkanidaten.
Und was spricht versuchsweise gegen die Verwendung eines bekannt
funktionierenden Modems? Oder sind die Einheiten nicht so einfach
trennbar?
Martin Laabs
>>
>>Das Problem ist folgendes. Sowohl Modem als auch Software sind
>>von mir selber gebaut/geschrieben und damit Fehlerkanidaten.
> Und was spricht versuchsweise gegen die Verwendung eines bekannt
> funktionierenden Modems? Oder sind die Einheiten nicht so einfach
> trennbar?
Untrennbar. Ist alles auf einer Platine. Aber jetzt tut es ja.
Nur etwas zu viele Bitfehler. Ich muss wohl noch etwas mit den
Parametern spielen. Aber nachdem ich mich etwas in die Materie eingearbeitet
habe wird immer ersichtlicher das das Protokoll sehr überholungsbedürftig
ist. Z.B. Fehlt eine gute Fehlerkorrektor die auch mal ein oder zwei
Bit korrigieren kann.
Leider wird man sowas nicht kompatibel halten können. Ich könnte mir aber
gut ein komplett neues Packetnetz auf Basis von IPV6 vorstellen.
Tschüss
Martin L.
Ralph A. Schmid, DK5RAS
>Aber nachdem ich mich etwas in die Materie eingearbeitet
>habe wird immer ersichtlicher das das Protokoll sehr überholungsbedürftig
>ist. Z.B. Fehlt eine gute Fehlerkorrektor die auch mal ein oder zwei
>Bit korrigieren kann.
Man muß immer in den Augen behalten, wie alt der Krempel ist. Ich habe
mit PR 1986 begonnen, und damals schon war das Ganze nicht mehr ganz
brandneu :)
Martin Laabs
> Man muß immer in den Augen behalten, wie alt der Krempel ist. Ich habe
> mit PR 1986 begonnen, und damals schon war das Ganze nicht mehr ganz
> brandneu :)
Um so wichtiger wäre es einen neuen Standard zu finden. Das solch
ein neues Netz auf IP aufbauen sollte ist wohl selbstverständlich.
Da man beim Amateurfunk auch eine begrenzte Nutzergruppe hat
fallen die Routingprobleme mit IPv6 nicht so ins Gewicht und
man hätte eine eigene Adresse für jeden OM.
Dann die Geschwindigkeit anpassen und evt. ein Link-Level
Protokoll welches, je nach Empfangspegel, verschiedene Modulationen
beherscht. Ich denke mit 200kB im 70cm Band wäre schon viel
gewonnen. Bei 23cm könnte man entsprechend höhere Geschwindigkeiten
erreichen.
Dazu gibt es dann richtige Datenreceiver die preiswert und einfach
handhabbar sind.
Gekoppelt wird das gesammte Netz via Internet, wenn keine direkten
Linkstrecken vorhanden sind.
Das Packetnetz so wie es jetzt ist, ist eine Krücke und stirbt über
lang oder kurz aus. Daran ändert auch TCP/IP über AX25 nichts.
Nur wenn die ewig gestrigen immer auf ihrer Kompatibilität sitzen
bleiben wird das nix.
Tschüss
Martin L.
Peter Voelpel
news:3d13b4F...@news.dfncis.de...
> Untrennbar. Ist alles auf einer Platine. Aber jetzt tut es ja.
> Nur etwas zu viele Bitfehler. Ich muss wohl noch etwas mit den
> Parametern spielen. Aber nachdem ich mich etwas in die Materie
eingearbeitet
> habe wird immer ersichtlicher das das Protokoll sehr überholungsbedürftig
> ist. Z.B. Fehlt eine gute Fehlerkorrektor die auch mal ein oder zwei
> Bit korrigieren kann.
X25 verwendet CRC zur Fehlerkorrektur.
Wenn Du keinen HDLC Controller verwendest musst Du den CRC-Check
per Software implementieren.
Fehlerhafte Frames sind abzuweisen und müssen erneut übertragen werden..
http://www.erg.abdn.ac.uk/users/gorry/course/dl-pages/crc.html
es handelt sich ja um ein Point-to-Point Protocol, bei reinem mitlesen
werden immer Bitfehler auftreten
73
Peter
Ralph A. Schmid, DK5RAS
>Um so wichtiger wäre es einen neuen Standard zu finden. Das solch
Das wird schwierig sein. Damals haben eine Hand voll Leute das
Verfahren entwickelt und veröffentlicht. Heute würden zu viele
mitreden wollen, man würde sich wohl kaum einig werden, da zu
verschiedene Erwartungen und Vorstellungen vorhanden sind.
>Nur wenn die ewig gestrigen immer auf ihrer Kompatibilität sitzen
>bleiben wird das nix.
Damit hat das eher nichts zu tun; inzwischen sind einfach zu viele
involviert, als daß solche grundlegenden Änderungen zu erwarten wären.
>Tschüss
> Martin L.
Martin Laabs
> "Martin Laabs" <98ma...@gmx.de> schrieb im Newsbeitrag
> news:3d13b4F...@news.dfncis.de...
> X25 verwendet CRC zur Fehlerkorrektur.
> Wenn Du keinen HDLC Controller verwendest musst Du den CRC-Check
> per Software implementieren.
> Fehlerhafte Frames sind abzuweisen und müssen erneut übertragen werden..
Ja. Und kennst du die durchschnittliche Bitfehlerrate von so einem
PR Modem?
Bei mir liegt sie bei ca. 1/1500. D.h. es ist bei Paketen größer
als 300 Byte mehr als wahrscheinlich das ein Bitfehler auftritt.
Wenn du jetzt noch weist das die Präamble gut zwei mal so lang
wie die eigentlichen Daten sind (ein DX Spot in diesem Fall) damit
es auch noch die langsamsten Modems mit der Syncronisation schaffen
siehst du sicher ein das ein Fehlertoleranter Code sehr viel Bandbreite
spart.
> es handelt sich ja um ein Point-to-Point Protocol, bei reinem mitlesen
> werden immer Bitfehler auftreten
Aber ein DX Cluster ist erst mal ein multicast Dienst der besonders
von einem Fehlertoleranten Code profitieren kann.
Tschüss
Martin L.
Martin Laabs
> Das wird schwierig sein. Damals haben eine Hand voll Leute das
> Verfahren entwickelt und veröffentlicht. Heute würden zu viele
> mitreden wollen, man würde sich wohl kaum einig werden, da zu
> verschiedene Erwartungen und Vorstellungen vorhanden sind.
Welche Vorstellungen gibt es denn die nicht miteinander
vereinbar so man von der Inkompatibilität mal absieht?
> Damit hat das eher nichts zu tun; inzwischen sind einfach zu viele
> involviert, als daß solche grundlegenden Änderungen zu erwarten wären.
Also warten bis auch der letze AX25 Digi verreckt ist und dann alles
mühsam neu aufbauen? Das kann es ja nicht sein.
Was spricht denn dagegen eine Arbeitsgruppe zu bilden die sich einen
neuen Standard ausdenkt?
Ralph A. Schmid, DK5RAS
>Welche Vorstellungen gibt es denn die nicht miteinander
>vereinbar so man von der Inkompatibilität mal absieht?
Ich habe mich damit zu wenig befaßt; aber es reicht mir,
mitzubekommen, was alleine kleine Änderungen am bestehenden Netz für
ein Ringen erfordern, als daß ich an einen erfolgreichen Komplettumbau
glauben mag.
>Also warten bis auch der letze AX25 Digi verreckt ist und dann alles
>mühsam neu aufbauen? Das kann es ja nicht sein.
>Was spricht denn dagegen eine Arbeitsgruppe zu bilden die sich einen
>neuen Standard ausdenkt?
Nix. Aber ob es sinnvoll ist, ob es sich jemals durchzusetzen vermag,
das ist eben offen. Wer beginnt damit? Hast Du Lust darauf? Ich hätte
es nicht, mir wäre das ein paar Nummern zu groß :)
Georg Seegerer
>>Wenn Du keinen HDLC Controller verwendest musst Du den CRC-Check
>>per Software implementieren.
>>Fehlerhafte Frames sind abzuweisen und müssen erneut übertragen werden..
>
> Ja. Und kennst du die durchschnittliche Bitfehlerrate von so einem
> PR Modem?
> Bei mir liegt sie bei ca. 1/1500. D.h. es ist bei Paketen größer
> als 300 Byte mehr als wahrscheinlich das ein Bitfehler auftritt.
Das ist wirklich ein Nachteil. Im TNC2 steckt ein ZX80 Prozessor,
der hätte damals aber eine FEC (forward error correction) von der
Rechenleistung her noch gar nicht gepackt.
Heute ist das was anderes, ein TNC3 sollte genügend Rechenleistung
haben um sowas zumindest bei 9600 Baud zu machen. Und die TNC2
Besitzer können im KISS oder 6Pack Modus einem PC die Arbeit
überlassen.
Man könnte das ganze ähnlich wie DAMA einführen: Der Digi und der
Benutzer-TNC unterhalten sich was der andere kann und nur wenn
beide das neue Protokoll können wird es benutzt. Oder der Digi-
Betreiber installiert die Sache und die Benutzer müssen mitziehen
wenn sie den Digi weiter benutzen wollen. Wenn Packet dadurch
unanfälliger für Störungen wird sollten die Leute das schon
einsehen können.
> Wenn du jetzt noch weist das die Präamble gut zwei mal so lang
> wie die eigentlichen Daten sind (ein DX Spot in diesem Fall) damit
> es auch noch die langsamsten Modems mit der Syncronisation schaffen
Das ist natürlich schon extrem lang. Manchmal denke ich mir auch dass
ein Digi volldublex sein könnte und ständig am senden ist. Die Benutzer
sind nur Simplex, aber der Digi achtet darauf dass wenn er auf einen
Benutzer-TNC antwortet, er genügend zeitlichen Abstand lässt damit
der TNC auf Empfangen umschalten und sich syncronisieren konnte, mit
den Paketen, die für andere Nutzer waren oder mit der Sync-Sequenz
wenn sonst nichts los ist. Das würde natürlich nur mit DAMA gehen wenn
der Digi weiß dass alle Benutzer-TNCs empfangsbereit sind wenn sie
nicht explizit zum senden aufgefordert wurden. Diese Betriebsweise
würde verschwendete Zeit für Präambeln sparen, aber man müsste das
als einheitlichen Standart durchsetzten, was natürlich mit viel Arbeit
verbunden ist, wie DK5RAS schon bemerkt hat. Umsetzen könnte man das
Digi für Digi, da wäre keine hau-ruck Aktion nötig.
Georg
--
Die Reply-To Adresse ist reply-fähig ;-)
Martin Laabs
> Das ist wirklich ein Nachteil. Im TNC2 steckt ein ZX80 Prozessor,
> der hätte damals aber eine FEC (forward error correction) von der
> Rechenleistung her noch gar nicht gepackt.
Damals waren auch die Computer zu langsam um 9600 Baud
via Kiss o.ä. nativ machen zu können.
[FEC und vollduplex]
> verbunden ist, wie DK5RAS schon bemerkt hat. Umsetzen könnte man das
> Digi für Digi, da wäre keine hau-ruck Aktion nötig.
Die Vorschläge klingen gut. Aber ich sehe halt das Problem
das man auf die morschen Balken (AX25) immer mehr und mehr
drauf bauen will und hofft das es nicht einstürzt.
Ich plädiere aber für einen kompletten Neuanfang. Der wird dann
aber nie und nimmer und ganz gar nicht kompatibel sein. Da dies
offensichtlich nicht mit den heutigen Packetnutzern machbar
ist (welche Gründe diese auch immer haben) wird man sowas wohl
paralell zu den bestehenden Digis machen müssen.
Angenommen man hätte sich einen zukunftsweisenden Standard ausgedacht
sehe ich nur die Möglichkeit neue Digis paralell aufzustellen.
Ich weis nicht wie es in den Ballungsgebieten mit freien Freuqenzen
auf 70cm aussieht. Aber zur Not muss man halt auf den höheren Bändern
anfangen.
Ein Zugeständniss könnte man dann machen indem man das AX25 über
IP tunnelt. Dann kann man einen Digi ersetzen ohne das man dann auf
das restliche AX25-Netz verzichten muss.
Ob sich der ganz Aufwand in Bezug auf das Internet überhaupt
lohnt mag jeder für sich selbst entscheiden.
Aber so viel ich weis war, als das Internet noch teuer und
nicht weit verbreitet war, gerade das Packetnetz ein Anreiz
für viele Jugendliche sich mit dem Amateurfunk auseinanderzusetzen.
Nachdem die Connectivitypreise für Internetverkehr dermaß
dramatisch gesunken sind wäre es auch eine Diskusion wert,
ob das koppeln des Internets mit dem Packetnetz einem gewerblich-
wirtschaftliches Interesse gleichkommt, oder ob man ein Zugpferd
des Amateufunkes nicht wieder flott machen kann.
Tschüss
Martin L.
Joachim dc4jwd
>
> Um so wichtiger wäre es einen neuen Standard zu finden. Das solch
> ein neues Netz auf IP aufbauen sollte ist wohl selbstverständlich.
Ja. Aber auch IP baut nicht direkt auf die Hardware auf. Zwischen Hardware
und IP ist noch das Ethernetprotokoll, AX25 oder etwas anderes.
IP ist etwas für die höheren Schichten. Als unterste Ebene würde ein
Protokoll benötigt, welches optimal an die Bedingungen der Funkübertragung
angepasst ist.
Es müsste ein Broadcast-Protokoll sein, denn Mithören darf nicht erschwert
werden und müßte zumindest Fehlerkorrektur und Authentifikation bieten.
> Da man beim Amateurfunk auch eine begrenzte Nutzergruppe hat
> fallen die Routingprobleme mit IPv6 nicht so ins Gewicht
Routingprobleme fallen enorm ins Gewicht. Gerade bei der vorhandenen
(Un-)Zuverlässigkeit vieler Links. Es ist ein Routingprotokoll
erforderlich, welches sehr ressourcenschonend und leistungsfähig ist. Die
getrennte Beurteilung von Fehlerrate, Datenrate und Auslastung eines Links
wäre sinnvoll.
Zeitgemäß wäre natürlich auch ein Protokoll, welches ein Routing bietet, bei
dem z.B. eine Verbindung zu einem Fahrzeug bestehenbleibt, wenn dieses von
Hamburg nach München (oder auch von Warschau nach Madrid) fährt.
> und
> man hätte eine eigene Adresse für jeden OM.
Das ist auch jetzt gegeben. Nur wenn ein OM mehrere Adressen haben will und
vielleicht ein Subnetz hat, welches per Routing erreichbar sein soll, wird
es schwierig.
> Dann die Geschwindigkeit anpassen und evt. ein Link-Level
> Protokoll welches, je nach Empfangspegel, verschiedene Modulationen
> beherscht.
Ja, das wäre sinnvoll.
> Dazu gibt es dann richtige Datenreceiver die preiswert und einfach
> handhabbar sind.
Die gibt es nicht einfach so. Man kann nur mit Eigenbau-Lösungen anfangen.
Die müssen als nachbausicher entwickelt und veröffentlicht werden. Da ist
viel Arbeit zu tun.
> Das Packetnetz so wie es jetzt ist, ist eine Krücke und stirbt über
> lang oder kurz aus. Daran ändert auch TCP/IP über AX25 nichts.
> Nur wenn die ewig gestrigen immer auf ihrer Kompatibilität sitzen
> bleiben wird das nix.
Selbst mit Kompatibilitätsanforderungen könnte man leben. Linkstrecken
könnten einzeln aufgerüstet werden, Einstiege könnten mehrere Modi
anbieten. Boxen könnten Postings signieren, die über Verbindungen zu
authentifizierten Usern reinkamen. Es ist ein sanfter Umstieg möglich.
73
Joachim
Joachim dc4jwd
Martin Laabs wrote:
> Peter Voelpel <peter....@t-online.de> wrote:
>> "Martin Laabs" <98ma...@gmx.de> schrieb im Newsbeitrag
>> news:3d13b4F...@news.dfncis.de...
>
>> X25 verwendet CRC zur Fehlerkorrektur.
>> Wenn Du keinen HDLC Controller verwendest musst Du den CRC-Check
>> per Software implementieren.
Das ist keine Fehlerkorrektur, sondern Fehlererkennung. So wie die
Paritätsprüfung im RAM einen Ein-Bit-Fehler erkennen kann, ECC diesen
Fehler aber korrigiert.
>> Fehlerhafte Frames sind abzuweisen und müssen erneut übertragen werden..
>
> Ja. Und kennst du die durchschnittliche Bitfehlerrate von so einem
> PR Modem?
> ..
> siehst du sicher ein das ein Fehlertoleranter Code sehr viel Bandbreite
> spart.
So ist es. Es gibt aber noch weitere Probleme mit dem jetzigen Protokoll.
Die fehlende Authentifizierung verdirbt einigen ehrlichen Usern den Spass
an der Sache.
Besser wäre es, wenn eine digitale Signatur (keine Verschlüsselung!) jedes
einzelnen Paketes den Störern (Callmißbrauch, u.ä.) den Spass verderben
würde.
>> es handelt sich ja um ein Point-to-Point Protocol, bei reinem mitlesen
>> werden immer Bitfehler auftreten
>
> Aber ein DX Cluster ist erst mal ein multicast Dienst der besonders
> von einem Fehlertoleranten Code profitieren kann.
Genau. Und solche Verfahren sind Stand der Technik.
73
Joachim
Hans Georg Giese
...
> Ja. Und kennst du die durchschnittliche Bitfehlerrate von so einem
> PR Modem?
> Bei mir liegt sie bei ca. 1/1500. D.h. es ist bei Paketen größer
> als 300 Byte mehr als wahrscheinlich das ein Bitfehler auftritt.
Die Steinzeit Modems mit der langen Vorlaufzeit sind da etwas besser.
DF2AU de DB0FC (06:56)>sta dk0mav
Link to DK0MAV 22.04.05 15:41:45 - 25.04.05 06:56:22
Bytes total Frames %Polls %Rejects %NotReady
RX: 28893258 228901 21 0 0
TX: 42400992 261881 18 0 0
DF2AU de DB0FC (06:56)>sta db0cel
Link to DB0CEL 22.04.05 15:41:45 - 25.04.05 06:56:26
Bytes total Frames %Polls %Rejects %NotReady
RX: 45464172 306662 17 0 0
TX: 37742125 278016 6 0 0
DF2AU de DB0FC (06:56)>sta db0wob
Link to DB0WOB 22.04.05 15:41:45 - 25.04.05 06:56:42
Bytes total Frames %Polls %Rejects %NotReady
RX: 14497201 82152 32 0 3
TX: 31603753 128527 40 0 1
Zur Erklärung:
"Polls" sind alle Verwaltungsframes. Fehlerhafte Frames sieht man in
den "Rejects".
Die Links sind alles andere als super, dafür reicht es bei weitem nicht.