suche Paketrohdaten

[Martin Laabs]

Hallo,

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]

Post by 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...

Post by Martin Laabs
Danke

regards - Ralph

[Martin Laabs]

Post by Ralph A. Schmid, DK5RAS

Post by 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.

[Ralph A. Schmid, DK5RAS]

Post by 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?



regards - Ralph

[Martin Laabs]

Post by Ralph A. Schmid, DK5RAS

Post by 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]

Post by Martin Laabs
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 :)



regards - Ralph

[Martin Laabs]

Post by Ralph A. Schmid, DK5RAS
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.

[Ralph A. Schmid, DK5RAS]

Post by Martin Laabs
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.

Post by Martin Laabs
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.

Post by Martin Laabs
Tschüss
Martin L.

regards - Ralph

[Martin Laabs]

Post by Ralph A. Schmid, DK5RAS
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?

Post by Ralph A. Schmid, DK5RAS
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?

Tschüss
Martin L.

Post by Ralph A. Schmid, DK5RAS
regards - Ralph
--
Want to get in touch? http://www.radio-link.net/whereisralph.txt

[Ralph A. Schmid, DK5RAS]

Post by Martin Laabs
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.

Post by Martin Laabs
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ß :)

Post by Martin Laabs
Tschüss
Martin L.

regards - Ralph

[Joachim dc4jwd]

Post by Martin Laabs
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.

Post by Martin Laabs
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.

Post by Martin Laabs
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.

Post by Martin Laabs
Dann die Geschwindigkeit anpassen und evt. ein Link-Level
Protokoll welches, je nach Empfangspegel, verschiedene Modulationen
beherscht.

Ja, das wäre sinnvoll.

Post by Martin Laabs
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.

Post by Martin Laabs
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

[Peter Voelpel]

Post by Martin Laabs
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

Post by Martin Laabs
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

[Martin Laabs]

Post by Peter Voelpel
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.

Post by Peter Voelpel
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.

[Georg Seegerer]

Post by Martin Laabs

Post by Peter Voelpel
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.

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.

Post by Martin Laabs
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

[Martin Laabs]

Post by Georg Seegerer
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]

Post by Georg Seegerer
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]

Hallo,

Post by Martin Laabs

Post by Peter Voelpel
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.

Post by Martin Laabs

Post by Peter Voelpel
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.

Post by Martin Laabs

Post by Peter Voelpel
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]

Martin Laabs wrote:

...

Post by Martin Laabs
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.

Post by Martin Laabs
Tschüss
Martin L.

73, Georg, DF2AU

[Hans Georg Giese]

Moin,

Post by Martin Laabs
Hallo,
ich schreibe gerade die Firmware für mein Paketmodem.

schön. Mal wieder jemand, der nicht nur redet sondern handelt.

Post by Martin Laabs
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?

Post by Martin Laabs
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]

Post by Hans Georg Giese
Moin,

Post by Martin Laabs
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]

Moin,

Martin Laabs wrote:

...

Post by Martin Laabs
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.

Post by Martin Laabs
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 :-)

Post by Martin Laabs
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.

Post by Martin Laabs
Tschüss
Martin L.

73, Georg, DF2AU

[Martin Laabs]

Post by Hans Georg Giese
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.

Post by Hans Georg Giese
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.

[Hermann Boehm]

Post by Martin Laabs
[...]
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