Guten Abend! Ich baue über 2 PMR Handfunkgeräte mittels FSK Modem ( Bell 202 ) eine Funkverbindung zwischen 2 µCs auf. Habe derzeit zu Testzwecken eine einfache 300 Baud UART Verbindung aufgebaut, würde aber das ganze gerne, um etwas Fehlersichereres, + Fehlererkennung + Korrektur erweitern. Jetzt wollte ich euch Fragen, welche FEC Codierung würdet ihr mir empfehlen? Einfach halten und einen Hamming Code verwenden? Oder lieber LPDC oder Turbo Code? Das ganze sollte auf AVR µC, 8-Bit laufen. Es geht dabei darum, dass es möglich fehlersicher, stabil und wenn möglich auf größere Distanz gut funktionieren soll. Es werden nur ca. 20 verschiedene Zustände übertragen, daher müsste ich keinen Codierer einbauen, sondern könnte die Zustände direkt in einer Tabelle ablegen und aufrufen. Bei der Decodierung sieht das natürlich nichtmehr so einfach aus leider. Würde mich über eure Meinung dazu freuen. Schöne Grüße aus dem Süden Arnold
Tach Arnold! Grundsätzlich sind Fehlererkennung und Fehlerkorrektur zwei verschiedene Dinge. Viele Wege führen nach Rom. In dem Falle ist Rom eine fehlersichere Übetragung. Hast du einen Rückkanal reicht normalerweise ein simpler Blockcode mit dem sich ein Fehler erkennen lässt und beim Sender eine Wiederholung angefordert wird. Will man mit einem Blockcode auch noch Fehlerkorrektur betreiben steigt der Übertragungsaufwand schnell an. Es lassen sich (h-1)/2 Bitfehler korrigieren, wenn h die Hammingdistanz ist. Du brauchst also schon mal drei bits um ein Datenbit gesichert zu übertragen. Ein Faltungscodierer sieht erstmal komplexer aus ist aber effizienter was Sicherheit vs. Coderate angeht. Allerdings ist das Feststellen eines Fehlers am Ausgang des Dekoders nicht möglich. Wo soll die Reise hin gehen? Thor
Hallo, und einen guten Morgen Thor! Alex S. schrieb: > Tach Arnold! > Grundsätzlich sind Fehlererkennung und Fehlerkorrektur zwei verschiedene > Dinge. Viele Wege führen nach Rom. In dem Falle ist Rom eine > fehlersichere Übetragung. > > Hast du einen Rückkanal reicht normalerweise ein simpler Blockcode mit > dem sich ein Fehler erkennen lässt und beim Sender eine Wiederholung > angefordert wird. Ja ich habe einen Rückkanal, würde aber gerne soviele Fehler als möglich schon vorab also mit FEC abfangen, wenn möglich. > Will man mit einem Blockcode auch noch Fehlerkorrektur > betreiben steigt der Übertragungsaufwand schnell an. Es lassen sich > (h-1)/2 Bitfehler korrigieren, wenn h die Hammingdistanz ist. Du > brauchst also schon mal drei bits um ein Datenbit gesichert zu > übertragen. Also ich sehe kein Problem darin größere Codewörter zu übertragen, wie gesagt habe ich nicht allzuviele verschiedene Zustände die ich übertragen muss, das heißt im Grunde würden mir 5 Bits, bzw. 6 ( um etwas Spielraum für die Zukunft zu haben ) als Nutzdatenbit reichen. Um also pro Nutzbit auch einen Bitfehler korrigieren zu können, müsste ich 13 Bit übertragen, das dürfte kein Problem sein. Ich denke nur, ich sollte zur Übertragung nicht UART verwenden, sondern einen anderen Leitungscode, NRZI zb. ( Wird bei Packet Radio soweit ich weiß verwendet ), oder hast du eine bessere Idee, Thor? > Ein Faltungscodierer sieht erstmal komplexer aus ist aber effizienter > was Sicherheit vs. Coderate angeht. Allerdings ist das Feststellen eines > Fehlers am Ausgang des Dekoders nicht möglich. Das ist richtig, deshalb bezweifle ich auch etwas, die "einfache" Implementierung in einen kleinen AVR, vermutlich werde ich hier tatsächlich mit einer Hamming Codierung besser bedient sein, vorallem weil es mir nicht auf hohe Effizienz ankommt ( Nutzdatenrate / Übertragungsrate ). Ist das so richtig? Schöne Grüße Arnold
Hallo nochmal, Ist es auch möglich Hamming Codes zu verschachteln, das heißt das ganze mehrmals zu codierung um eine noch größere Störsicherheit zu erhalten? Oder würde das ganze, außer unnützer Länge, und Rechenzeit nichts bringen? Habe leider im Bereich Codierung null Erfahrung, deshalb hoffe ich von euch Erfahrungswerte zu bekommen :-). Wünsche ein schönes Wochenende Arnold
Generell empfiehlt sich keine Verschachtelung ohne weitere Bearbeitung. Besser ist es die Nutzdaten in kleinere Blöcke aufzuteilen und einzeln zu kodieren. Thor
Für AFSK-Übertragung* ist Bell202 nicht das optimale Verfahren. Besser ist eine FFSK/CPFSK*. Im Sprachkanal üblicher FM- oder PM-modulierter Funkgeräte lassen sich damit problemlos bis zu 4800 Bit/s übertragen. Ein typisches Modem ist der CMX469A von CML Micro. http://www.cmlmicro.com/products/CMX469A_1200-2400-4800_Baud_FFSK_Modem/ Dabei werden üblicherweise bitsynchrone Verfahren eingesetzt. Bei Übertragung in auch für Sprache genutzten Kanälen werden nur kurze Telegramme eingesetzt (Dauer unter ~ 300ms), bei reinen Datenkanälen liegen die Telegrammlängen im Bereich bis ca. 256 oder 512 Bit. Als Blocksicherung sind CRC üblich, wobei am Anfang kurze CRC mit 8 Bit (z.B. FMS) eingesetzt wurden, meist üblich ist aber immer noch ein 16 Bit-CRC wie der CCITT-CRC (-> HDLC) oder der CRC16. Bei Duplex-Übertragungen wird FEC in aller Regel nicht eingesetzt, sondern es wird mit einer Blockbestätigung und ggf. Wiederholung gearbeitet. Bei reinem Broadcast-Betrieb (Paging) kann eine FEC hingegen sinnvoll sein. Meist wird aber auch hier die Nachricht einfach mehrfach übertragen. Noch ein Wort zu den "Randbedingungen": Die Dauer der Kanalbelegung hängt bei einer AFSK-Übertragung mit unmodifizierten Funkgeräten primär von der benötigten Zeit für die Sendertastung, das Öffnen der Rauschsperre und die Synchronisation des Modems ab. Unter optimalen Bedingungen sollte diese "tote Zeit" so kurz wie möglich sein. Bei gegebenen Funkgeräten kann man das nur in begrenztem Rahmen beeinflussen. Die Zeit für die Sendertastung ist eine gerätetypische Konstante. Da ist nicht viel zu machen. Die Zeit für das Ansprechen der Rauschsperre kann man minimieren, wenn man sie deaktiviert bzw. das Signal davor abgreift. Dann muss aber das Modem in der Lage sein, mit dem Rauschen des leeren Kanals klar zu kommen und nicht fälschlich "Carrier Detect" zu liefern. Der viel verwendete TCM3105 war in der Hinsicht z.B. problematisch, da dann CD permanent aktiv hielt. Die Synchronisationszeit des Modems ist verfahrens- und modemabhängig. Die FFSK/CPFS-Modems sind aber in aller Regel auf gute Synchronisationszeiten optimiert. Grüße Stefan AFSK: Audio Frequency Shift Keying CPFSK: Continuous Phase Frequency Shift Keying FFSK: Fast Frequency Shift Keying
Herzlichsten Dank für die ausführliche Antwort Stefan! Stefan Wagner schrieb: > Für AFSK-Übertragung* ist Bell202 nicht das optimale Verfahren. > Besser > ist eine FFSK/CPFSK*. Im Sprachkanal üblicher FM- oder PM-modulierter > Funkgeräte lassen sich damit problemlos bis zu 4800 Bit/s übertragen. > Ein typisches Modem ist der CMX469A von CML Micro. > http://www.cmlmicro.com/products/CMX469A_1200-2400... > Hatte den TCM3105, deshalb verwendet, da er sehr einfach funktioniert, und zum testen erstmal optimal lief. Hört sich einleuchtend an, wie gesagt großer Datendurchsatz ist bei mir nicht gefordert, eher die Störungsfreie Übertragung. Ich werde mir den CMX469A mal ansehen, bzw. einen Ordern um Tests machen zu können! Danke für den Tipp! > Dabei werden üblicherweise bitsynchrone Verfahren eingesetzt. Bei > Übertragung in auch für Sprache genutzten Kanälen werden nur kurze > Telegramme eingesetzt (Dauer unter ~ 300ms), bei reinen Datenkanälen > liegen die Telegrammlängen im Bereich bis ca. 256 oder 512 Bit. > > Als Blocksicherung sind CRC üblich, wobei am Anfang kurze CRC mit 8 Bit > (z.B. FMS) eingesetzt wurden, meist üblich ist aber immer noch ein 16 > Bit-CRC wie der CCITT-CRC (-> HDLC) oder der CRC16. > > Bei Duplex-Übertragungen wird FEC in aller Regel nicht eingesetzt, > sondern es wird mit einer Blockbestätigung und ggf. Wiederholung > gearbeitet. Würde nur gerne einen geringen Anteil FEC verwenden, damit sich die Übertragungsdauer nicht unnötig lange hinauszögert, das heißt eine Kombination der beiden wäre eventuell Sinnvoll. > Bei reinem Broadcast-Betrieb (Paging) kann eine FEC hingegen sinnvoll > sein. Meist wird aber auch hier die Nachricht einfach mehrfach > übertragen. > > Noch ein Wort zu den "Randbedingungen": > > Die Dauer der Kanalbelegung hängt bei einer AFSK-Übertragung mit > unmodifizierten Funkgeräten primär von der benötigten Zeit für die > Sendertastung, das Öffnen der Rauschsperre und die Synchronisation des > Modems ab. > > Unter optimalen Bedingungen sollte diese "tote Zeit" so kurz wie möglich > sein. Bei gegebenen Funkgeräten kann man das nur in begrenztem Rahmen > beeinflussen. > > Die Zeit für die Sendertastung ist eine gerätetypische Konstante. Da ist > nicht viel zu machen. > > Die Zeit für das Ansprechen der Rauschsperre kann man minimieren, wenn > man sie deaktiviert bzw. das Signal davor abgreift. Dann muss aber das > Modem in der Lage sein, mit dem Rauschen des leeren Kanals klar zu > kommen und nicht fälschlich "Carrier Detect" zu liefern. Der viel > verwendete TCM3105 war in der Hinsicht z.B. problematisch, da dann CD > permanent aktiv hielt. Ich habe Funktgeräte, wo man die Rauschsperre deaktivieren kann. Habe schon gemerkt, dass der TCM3105 damit nicht sehr gut damit zu recht kommt, dachte aber mit geeigneter FEC / CRC bekomme ich das einigermaßen in den Griff. > > Die Synchronisationszeit des Modems ist verfahrens- und modemabhängig. > Die FFSK/CPFS-Modems sind aber in aller Regel auf gute > Synchronisationszeiten optimiert. > > Grüße > > Stefan > > AFSK: Audio Frequency Shift Keying > CPFSK: Continuous Phase Frequency Shift Keying > FFSK: Fast Frequency Shift Keying Ich würde gerne 16 bit Pakete übertragen, meints du mit einer Hamming Fehlerkorrektur + CRC16 Fehlererkennung gute Ergebnisse mit dem von dir genannten Modem erzielen? Schönen Sonntag, Arnold
Hallo nochmals, Stefan, habe noch etwas vergessen, welche Leitungscodes würdest du verwenden? NRZI, oder via Hardware UART rausschicken?
Arnold schrieb: > Hört sich einleuchtend an, wie gesagt großer Datendurchsatz ist bei mir > nicht gefordert, eher die Störungsfreie Übertragung. > Würde nur gerne einen geringen Anteil FEC verwenden, damit sich die > Übertragungsdauer nicht unnötig lange hinauszögert, das heißt eine > Kombination der beiden wäre eventuell Sinnvoll. > Ich würde gerne 16 bit Pakete übertragen, meints du mit einer Hamming > Fehlerkorrektur + CRC16 Fehlererkennung gute Ergebnisse mit dem von dir > genannten Modem erzielen? > welche Leitungscodes würdest du verwenden? NRZI, oder via Hardware UART > rausschicken? Ich habe den Eindruck, du machst dir etwas zu viele Sorgen wegen gestörter Übertragungen. Datenübertragung mit AFSK bzw. FFSK mit FM-modulierten Funkgeräten wurde bzw. wird in großem Umfang im BOS-Funk, Betriebsfunk und Amateurfunk eingesetzt. Solange das HF-Signal nicht im Rauschen verschwindet, hast du so gut wie keine Störungen des Übertragungskanals - mit Ausnahme von Signalkollisionen (dazu unten mehr). In aller Regel (und deine Anwendung scheint keine Ausnahme davon zu sein) reicht also ein Protokoll mit Blockprüfung (CRC) und Bestätigung. Viel wichtiger sind hingegen a) geringer zeitlicher Overhead für Sendertastung und Modemsynchronisation b) ein guter Kanal-Zugriffsalgorithmus. Zu a: Das hängt davon ab, wie schnell deine Strecke aus Sender und Empfänger "eingeschwungen" ist und wie viele Bit die beiden Modems zur Synchronisation benötigen. Die Eigenschaften von Sender und Empfänger kannst du bei PMR-Geräten praktisch nicht beeinflussen (mit Ausnahme des Öffnens der Rauschsperre). Die benötigte Synchronisationszeit ist abhängig vom Verfahren (AFSK bzw. FFSK) und den Eigenschaften des Modems an sich. Modems wie der TCM3105 sind für den Einsatz auf vollduplex-betriebenen Strecken gedacht, bei denen einmalig die Modemsynchronisation erfolgt und danach die Strecke für längere Zeit aktiv bleibt. Im Funk hast du aber Simplex- bzw. Semiduplex-Betrieb, d.h. die Verbindung beider Modems wird jedes Mal neu aufgebaut und wieder getrennt. Die Synchronisationszeit fällt also viel, viel stärker ins Gewicht. Modems wie der CMX469A sind für solche Einsätze gedacht. Zum Vergleich: Der Vorlauf bei Bell202-modulierter Übertragung liegt in der Größenordnung von mehreren 100 ms. (Bei der KISS-TNC-Firmware z.B. 500ms.) Das entspricht bei 1200 Bit/s etwa 600 Bit. Der Vorlauf bei den mir bekannten FFSK-Modems liegt in der Größenordnung von etwa 16 Bit, also etwa 14 ms. Der TCM3105 hat aber noch ein Problem: > Ich habe Funkgeräte, wo man die Rauschsperre deaktivieren kann. Habe > schon gemerkt, dass der TCM3105 damit nicht sehr gut damit zu recht > kommt Das liegt an dessen Verfahren zur Signalerkennung (Carrier Detect), das auch auf Rauschen anspricht. > dachte aber mit geeigneter FEC / CRC bekomme ich das einigermaßen > in den Griff. Damit kannst du zwar Nutzsignale vom Rauschen unterscheiden, es bleibt aber ein weiteres, viel schwerwiegenderes Problem: In einem von mehreren Stationen genutzten Kanal muss man ein Zugriffsverfahren haben, dass sicherstellt, dass nur eine Station zur Zeit sendet. Üblich sind CSMA-Verfahren (Carrier Sense Multiple Access), bei denen jede Station vor dem Senden prüfen muss, ob der Kanal frei ist. Da der TCM3105 aber auf Rauschen anspricht, muss man entweder die Rauschsperre schließen (-> zusätzliche Ansprechzeit) oder eine separate Trägererkennung aufbauen (dafür wurde dann gern ein XR2206 verwendet). So, jetzt ein paar Vorschläge für deine Anwendung: Wenn du zu nichts anderem kompatibel sein musst, verwende ein FFSK-Modem. Damit erreichst du eine schneller ansprechende Strecke und hast auch keine Probleme mit der Signalerkennung. Diese Modems bedingen jedoch eine bitsynchrone Übertragung, d.h. du kannst keinen UART verwenden. Bei 1200 Bit/s ist es jedoch kein wirkliches Problem, das "zu Fuß" zu erledigen. (Rx- bzw. TX-Clock an einen externen Interrupt und im Interrupt jeweils ein Bit rausschieben.) Ach ja: Bei den FFSK-Modems wird üblicherweise NRZ-Codierung verwendet. Bei der Wahl des darauf liegenden Protokolls bist du im Prinzip frei. Du kannst dich an die bestehenden Protokolle aus dem Betriebsfunk anlehnen (-> ZVEI digital), kannst aber auch als "große Lösung" das AX.25-Protokoll verwenden. So, das sollte erst mal reichen. Grüße Stefan
:
Bearbeitet durch User
Stefan Wagner schrieb: > Arnold schrieb: >> Hört sich einleuchtend an, wie gesagt großer Datendurchsatz ist bei mir >> nicht gefordert, eher die Störungsfreie Übertragung. > >> Würde nur gerne einen geringen Anteil FEC verwenden, damit sich die >> Übertragungsdauer nicht unnötig lange hinauszögert, das heißt eine >> Kombination der beiden wäre eventuell Sinnvoll. > >> Ich würde gerne 16 bit Pakete übertragen, meints du mit einer Hamming >> Fehlerkorrektur + CRC16 Fehlererkennung gute Ergebnisse mit dem von dir >> genannten Modem erzielen? > >> welche Leitungscodes würdest du verwenden? NRZI, oder via Hardware UART >> rausschicken? > > Ich habe den Eindruck, du machst dir etwas zu viele Sorgen wegen > gestörter Übertragungen. > Scheinbar ja, aber ich vertraue dir, wenn ich mir das nicht machen sollte :). > Datenübertragung mit AFSK bzw. FFSK mit FM-modulierten Funkgeräten wurde > bzw. wird in großem Umfang im BOS-Funk, Betriebsfunk und Amateurfunk > eingesetzt. Solange das HF-Signal nicht im Rauschen verschwindet, hast > du so gut wie keine Störungen des Übertragungskanals - mit Ausnahme von > Signalkollisionen (dazu unten mehr). > > In aller Regel (und deine Anwendung scheint keine Ausnahme davon zu > sein) reicht also ein Protokoll mit Blockprüfung (CRC) und Bestätigung. Alles klar, dann werde ich das so probieren. > Viel wichtiger sind hingegen > a) geringer zeitlicher Overhead für Sendertastung und > Modemsynchronisation > b) ein guter Kanal-Zugriffsalgorithmus. > > Zu a: > Das hängt davon ab, wie schnell deine Strecke aus Sender und Empfänger > "eingeschwungen" ist und wie viele Bit die beiden Modems zur > Synchronisation benötigen. > > Die Eigenschaften von Sender und Empfänger kannst du bei PMR-Geräten > praktisch nicht beeinflussen (mit Ausnahme des Öffnens der > Rauschsperre). > > Die benötigte Synchronisationszeit ist abhängig vom Verfahren (AFSK bzw. > FFSK) und den Eigenschaften des Modems an sich. > > Modems wie der TCM3105 sind für den Einsatz auf vollduplex-betriebenen > Strecken gedacht, bei denen einmalig die Modemsynchronisation erfolgt > und danach die Strecke für längere Zeit aktiv bleibt. > > Im Funk hast du aber Simplex- bzw. Semiduplex-Betrieb, d.h. die > Verbindung beider Modems wird jedes Mal neu aufgebaut und wieder > getrennt. Die Synchronisationszeit fällt also viel, viel stärker ins > Gewicht. Modems wie der CMX469A sind für solche Einsätze gedacht. > > Zum Vergleich: > Der Vorlauf bei Bell202-modulierter Übertragung liegt in der > Größenordnung von mehreren 100 ms. (Bei der KISS-TNC-Firmware z.B. > 500ms.) Das entspricht bei 1200 Bit/s etwa 600 Bit. > Der Vorlauf bei den mir bekannten FFSK-Modems liegt in der Größenordnung > von etwa 16 Bit, also etwa 14 ms. Ok das hört sich ja sehr gut an. Verstehe ich das richtig, ich muss quasi zu beginn einige Sekunden den Sender einschalten, also mindestens so lange wie es braucht, bis sich Sender / Empfänger aufsynchronisiert haben ( Scheinbar nur durch probieren mit den richtigen Funkgeräten herausfindbar ), und danach kann ich mittels NRZ Codierung mit Takt die Daten auf das Modem schieben. > Wenn du zu nichts anderem kompatibel sein musst, verwende ein > FFSK-Modem. Das muss ich zum Glück nicht. Sehr gut so mache ichs! > Damit erreichst du eine schneller ansprechende Strecke und > hast auch keine Probleme mit der Signalerkennung. > Diese Modems bedingen jedoch eine bitsynchrone Übertragung, d.h. du > kannst keinen UART verwenden. Bei 1200 Bit/s ist es jedoch kein > wirkliches Problem, das "zu Fuß" zu erledigen. (Rx- bzw. TX-Clock an > einen externen Interrupt und im Interrupt jeweils ein Bit rausschieben.) > Ach ja: Bei den FFSK-Modems wird üblicherweise NRZ-Codierung verwendet. > > Bei der Wahl des darauf liegenden Protokolls bist du im Prinzip frei. Du > kannst dich an die bestehenden Protokolle aus dem Betriebsfunk anlehnen > (-> ZVEI digital), kannst aber auch als "große Lösung" das > AX.25-Protokoll verwenden. Die "große Lösung" wird wohl etwas too much sein, im grunde habe ich immer 16 Bit große Pakete, die ich übertragen möchte. Würde nicht im Grunde reichen, wenn ich die 16 Bit + 16CRC Bit direkt mit NRZ Codierung aufs Modem schiebe und übertrage? > So, das sollte erst mal reichen. > Das tut es, danke für die Ausführliche Antwort, das hilft mir wirklich sehr sehr viel weiter. Ich bin gerade auf der Suche nach dem CXM469A, bei Ebay um 50€ zu finden, sonst scheinbar nirgends, du wirst auch keinen Distributor wissen, der den IC führt oder? Habe der Firma mal geschrieben, vl. bekomm ich darüber etwas heraus. Danke, und schönen Sonntag Abend, Arnold
Arnold schrieb: > Ich bin gerade auf der Suche nach dem CXM469A, bei Ebay um 50€ zu > finden, sonst scheinbar nirgends, du wirst auch keinen Distributor > wissen, der den IC führt oder? Habe der Firma mal geschrieben, vl. > bekomm ich darüber etwas heraus. Auf der Website von CML Microelectonics http://www.cmlmicro.com/distributors/ ist unter "Germany" die SE Spezial-Electronic AG aufgeführt. Dort fand Google diese Kontaktangaben: http://www.spezial.com/newsletter/artikel.php?AID=68&TID=647 Grüße Stefan
Arnold schrieb: > Würde nicht im Grunde reichen, wenn ich die 16 Bit + 16CRC Bit > direkt mit NRZ Codierung aufs Modem schiebe und übertrage? Im Grunde, ja. Du wirst folgende Bestandteile brauchen: 1. Eine Modem-Trainingssequenz. Das sind mindestens 16 Bit 0-1-Folge. 2. Ein Flag-Byte. Das ist eine Bitfolge, die eindeutig den Telegrammbeginn kennzeichnet. 3. Bei mehreren Stationen ein bzw. zwei Adressfelder (Empfänger und Sender). 4. Die Nutzdaten. Entweder festes Format oder ein variables Feld mit Längenangabe. 5. Die Checksumme(CRC) Grüße Stefan
> Ist es auch möglich Hamming Codes zu verschachteln, das heißt das ganze > mehrmals zu codierung um eine noch größere Störsicherheit zu erhalten? Gratulation, du hast gerade fast die Turbo-Codes erfunden ;) Die funktionieren ja so, dass du zB. zwei Faltungscodes auf zwei Permutation der Eingangssequenz laufen lässt. Wenn man die Daten zB. im Quadrat anordnet, gibt das einmal zeilenweise Zustandsbits, einmal spaltenweise. Nach der Dekodierung der Zeilenwerte bekommt man die Soft-Bits der Zeile, also Wahrscheinlichkeiten für das tatsächliche Eingangsymbol. Statt da jetzt gleich den grössten Wert auszugeben, kann man diese man bei der Dekodierung der Spaltenwerte als weitere Stützpunkte (intrinsic feedback) nehmen. Abwechselnd werden dann die Fehler über das Feedback der jeweils anderen Richtung zeilen- bzw. spaltenweise "ausgebügelt", d.h. man muss da öfter drüber iterieren, das ist nicht so simpel wie beim Viterbi. Klingt rechenaufwendig, ist es auch ;)
HART läuft mit der gleichen Modulation und die Chips sind billiger und verfügbarer. Als FEC bei 16Bit-Nutzdaten bietet sich die von RDS verwendete an. @Georg: Wie findest du die gegenüber anderen FECs?
Hallo, danke für eure Antworten, habe heute ein Angebot erhalten, die MSK/FFSK Modems sollen ca. 30€ / Stück kosten. Sehr happiger Preis. Leider habe ich aber auch keine anderen MSK/FFSK Modems finden können, die ähnliches können. Hat jemand einen Geheimtipp? Abdul: Bist du sicher, dass die HART Modems auch mit FFSK arbeiten? Habe zb. diesen hier entdeckt: A519HRT HART Modem Die Arbeiten aber im Grunde auch alle mit Bell 202 mit FSK. HART ist doch nur ein Protokoll, soweit ich das sehe. Schönen Feierabend, Arnold
Ich war wohl gestern, als ich nach alternativen gesucht habe, nicht mehr ganz wach ;). Habe folgende Modelle gefunden, die günstig beschaffbar sind: FX529J MB87002PF Ersterer ist ebenso von CML, und es sieht so aus als hätte der eine gewisse Error Correction, sowie ein Start Word schon eingebaut, und überprüft das automatisch beim Senden / Empfangen und gibt es erst frei, wenn es Korrekt ist. Kennt dieses IC jemand von euch, und hat damit eventuell schon Erfahrungen sammeln können? Am Papier sieht es erstmal vielversprechend aus, aber das tut es ja öfter ohne, dass es dann auch so ist. Arnold
Was verstehst du denn unter FFSK genau? Ich vermute, es kommt dir auf continuous phase an, oder? Ich denke mal jeder halbwegs moderne FSK-Chip arbeitet so, da es weniger Störungen verursacht als wenn man die beiden Frequenzen einfach asynchron umschaltet. Die Transportschicht von HART entspricht dem BEL-202 Standard. Viel mehr gibts dazu nicht zu sagen. CML hat eine Unzahl von Modemchips für alle denkbaren Anwendungen im low-speed Bereich. Ne Alternative wäre es noch, einen Mikrocontroller passend zu programmieren. Der wird ja eh meist benötigt und kann das eventuell parallel mitmachen. Für den Cypress PSoC gibts ne AppNote und ich befürchte für viele andere Controller ebenso. Der PSoC kann die analogen Filter mitintegrieren. Das geht bei anderen Controllern nicht. Worauf kommts dir denn nun wirklich an? Klingt so als solle es superbillig werden. Aber du bist doch Amateurfunker und da spielen die paar Euro für einen Modemchip doch keine Rolle. Apropos Amateurfunk: Schau dir APRS an. Läuft auch mit BEL-202. Wenn da irgendwie Geld drin liegt und du Hilfe brauchst, können wir zusammenkommen. Einfach PM senden leapfrogs@arcor.de .
Abdul K. schrieb: > Was verstehst du denn unter FFSK genau? Ich vermute, es kommt dir > auf > continuous phase an, oder? Habe mich dabei an Stefans Vorschlag gehalten, also ich nehme an ja. Wobei ich den Unterschied nicht ganz erkennen kann, bei den FFSK Modems geht es scheinbar immer nur Bitsynchron, bei allen FSK Modems, ist dies nicht der Fall, kann aber ansonsten keinen Unterschied erkennen. Wie Stefan auch sagte, ist die Synchronisationzeit der FFSK Modems wesentlich besser als die von FSK Modems. Oder habe ich ihn diesbezüglich einfach Missverstanden? > Ich denke mal jeder halbwegs moderne FSK-Chip > arbeitet so, da es weniger Störungen verursacht als wenn man die beiden > Frequenzen einfach asynchron umschaltet. > Die Transportschicht von HART entspricht dem BEL-202 Standard. > Viel mehr gibts dazu nicht zu sagen. Richtig, und wie Stefan oben schrieb, ist das nicht ideal bezüglich der Synchronisationszeit zb. > > CML hat eine Unzahl von Modemchips für alle denkbaren Anwendungen im > low-speed Bereich. > > Ne Alternative wäre es noch, einen Mikrocontroller passend zu > programmieren. Der wird ja eh meist benötigt und kann das eventuell > parallel mitmachen. Für den Cypress PSoC gibts ne AppNote und ich > befürchte für viele andere Controller ebenso. Der PSoC kann die analogen > Filter mitintegrieren. Das geht bei anderen Controllern nicht. > Es kommen nur kleine µCs zum Einsatz, und möchte mich eigentlich nicht mit der Programmierung von FFSK herumschlagen müssen. Dann doch lieber 30€ :D. > Worauf kommts dir denn nun wirklich an? Klingt so als solle es > superbillig werden. Nein das nicht, aber 30€ finde ich etwas happig. > Aber du bist doch Amateurfunker und da spielen die > paar Euro für einen Modemchip doch keine Rolle. Apropos Amateurfunk: > Schau dir APRS an. Läuft auch mit BEL-202. APRS ist mir bekannt, wegen BEL-202 siehe oben.
Hallo Stefan, Hallo Abdul, vielleicht kann sich ja Stefan nochmal dazu äußern. So wie ich das verstanden habe, ist der Unterschied, FSK ( TCM3105 ) und FFSK (zb. CMX469A ), ja nur der Umschaltzeitpunkt der Mark und Space Frequenz. Und das dient ja nur der Verringerung der Bandbreite, sodass das Signal besser durch Bandbreitenbegrenzte Kanäle ( Funkgerät ) kommt. Dies allein würde ja keine Synchronisationszeit verlangsamen / verschnellern. Die Frage ist nur, wieso ist bei allen mir bekannten FFSK Modem immer eine Bitsynchrone Ansteuerung nötig, ist dies vl. der Schlüssel zur schnelleren Synchronisation? Schönen Abend noch an alle. Arnold
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.