FAQFAQ SuchenSuchen MitgliederlisteMitgliederliste BenutzergruppenBenutzergruppen  RegistrierenRegistrieren  ProfilProfil Einloggen, um private Nachrichten zu lesenP.M. LoginLogin
Sichere Funkübertragung, z.B. zu Zündgeräten
Gehe zu Seite Zurück  1, 2, 3  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    EURocketry Foren-Übersicht -> Zubehoer
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  

Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Do 22 Dez 2005, 18:23    Titel: Antworten mit Zitat

Andreas Müller hat folgendes geschrieben:
Die benötigte Rechenleistung für eine DES Implementation in einem AVR ist übrigens recht gering. Mit weniger als 2kB Code bekommt man einen Durchsatz von 32Bytes/s/MHz. D.h. mit einem 8MHz Prozessor hast 256 Bytes pro Sekunde. Da kannst Du schon ganz schön viel verschlüsseln.

Das Problem dabei:
- Standard Serial Rates sind 9600Baud, also etwa 4 mal mehr. Also ist nix mit synchroner Uebertagung, jedes Datagramm muss vorher berechnet werden.
- Der Prozessor wird auch stark damit beschäftigt sein, die für die Funk-Datenübertragung nötige Conversion in Manchester Code kostet auch Aufwand.

Aber das Thema ist auf jeden Fall gewisse Ueberlegungen wert. Das ARGOS Zünd-Equipment ist bewusst mit seriellen Kabeln ausgerüstet und die Belegung ist so gewählt, dass RS232 gefahren werden könnte (z.B. via externes Funkmodul). Wir betreiben die Anlage seit Anfang im elektromechanischen Fall-Back Modus, welcher 3 Rampen pro Zelle erlaubt. Im Vollausbau kann jede Zelle massiv mehr Rampen ansteuern.

Das was ich mit meiner Zündanlage vorhabe soll "am Boden bleiben" was den Aufwand betrifft, mehr als ein Wochenende kann und will ich nicht investieren.

Gruss

Jürg

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Reinhard



Anmeldungsdatum: 18.04.2005
Beiträge: 346

BeitragVerfasst am: Do 22 Dez 2005, 18:34    Titel: Antworten mit Zitat

Hi,

zeitlich kann man das ganze Problem mit der Verschlüsselung in den Bereich zwischen Entsichern und Feuern hineinverlegen. Da hat man ja "alle Zeit der Welt", also ganze Sekunden.

Sender: "Entsichern"
Pad: "Ack", Zufallszahl
Sender und Pad (intern): Fire=DES(Zufallszahl,Key) //dauert ein wenig
Pad: "Ready" //wer will: "Ready",HASH(Fire)
Sender: "Fire"
Pad: "Ack"

Man kann natürlich auch für das Entsichern schon eine Zufallszahl anfordern und sich noch zusätzlich mit Timeouts und Checksummen spielen.

Gruß
Reinhard
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 19:37    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
- Standard Serial Rates sind 9600Baud, also etwa 4 mal mehr. Also ist nix mit synchroner Uebertagung, jedes Datagramm muss vorher berechnet werden.
Warum auch synchron, das macht den Code nur komplizierter.[/quote]

Wegen der benötigten 50/50 duty cycles bei Funkübertragung mit 433MHz Modulen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 20:46    Titel: Antworten mit Zitat

Reinhard hat folgendes geschrieben:
Sender: "Entsichern"
Pad: "Ack", Zufallszahl
Sender und Pad (intern): Fire=DES(Zufallszahl,Key) //dauert ein wenig
Pad: "Ready" //wer will: "Ready",HASH(Fire)
Sender: "Fire"
Pad: "Ack"

Genau genommen ist das falsch. Der Inhalt eines Paketes und die Art der Transportsicherung sind verschiedene Schichten, also sollten sie voneinander unabhängig sein. Und warum auch soll man den Code unnötig verkomplizieren, statt einfach alle Pakete genau gleich zu behandeln. Wie Du sagst, hat man alle Zeit der Welt.

In diesem Protokoll hast Du keinen Schutz des ARM Befehls vor Replay, wir haben also auch noch ein Sicherheitsproblem. Ich finde es nicht lustig, wenn da plötzlich das ARM Relais klackert wenn ich am Pad mit dem Zünder hantiere. Echt spannend wird es, wenn das FIRE Relais verschweisste Kontakte hat...

Die Zufallszahl brauchst Du nur einmal, sagen wir ihr x, es genügt sogar, eine pro Sender/Empfänger zu haben. Wenn Du statt des obigen Protokolls folgendes machst, hast Du sauber getrennte Schichten, und trotzdem die nötige Sicherheit:

Sender: DES("ARM", x, hash("ARM", x))
Pad: DES("CONTINUITY", x+1, hash("CONTINUITY", x+1))
Sender: DES("FIRE", x+2, hash("FIRE", x+2))
Pad: DES("FIRED", x+3, hash("FIRED", x+3))
oder
Sender: DES("DISARM", x+2,hash("DISARM", x+2))
Pad: DES("DISARMED", x+3, hash("DISARMED", x+3))

Im CONTINUITY Paket könntest Du zum Beispiel auch den Zustand aller gemessenen Zünder übermitteln.

Die Überprüfung jedes Paketes ist identisch, nach der Entschlüsselung muss der Hash zum Paketinhalt passen. Damit ist sichergestellt, dass nur einer solche Pakete generieren kann, der den Schlüssel kennt. Und akzeptiert wird es nur, wenn die darin enthaltene Seriennummer grösser ist als die zuletzt verwendete. Da die Seriennummer niemandem bekannt ist, ist das ein sicherer Schutz vor Replay.

Die Zeit für die Verschlüsselung ist unproblematisch, weil man die Pakete immer vorausberechnen kann, und auf Wunsch übermitteln. Ins Gewicht fällt nur die Zeit für das Entschlüsseln, also 1/20 Sekunde.

Als Hash dürfte ein CRC-16 genügen. Der DES Schlüssel ist eine geheime Grösse zwischen Sender/Pad eines Paares, und bleibt bis zu neuer Paarung identisch (zum Beispiel im EEPROM, genau wie die Serial Number auch). Schlüssel und initial Serial werden beim Pairing zwischen Sender und Pad ausgetauscht, da man hierzu noch viel mehr Zeit hat, könnte man sogar Diffie-Hellmann dazu verwenden, zum Beispiel so:

Sender: "DH", g^u mod p, hash(g^u mod p)
Pad: "DH", g^v mod p, hash(g^v mod p)

Falls beide innerhalb einer gewissen Zeit nach dem Einschalten diese Pakete empfangen (vielleicht besser nur wenn man irgend eine Taste beim Anschalten drückt, siehe unten), berechnen beide g^uv mod p und verwenden die letzten 8 Bytes als Schlüssel, und vier weitere Bytes als initial serial. Um den Austausch zu bestätigen verwenden sie folgendes:

Sender: DES("NEWKEY", x, hash("NEWKEY", x))
Pad: DES("NEWKEY", x+1, hash("NEWKEY", x+1))

Damit weiss der Sender, dass das Pad einen neuen Schlüssel hat, der mit dem eigenen übereinstimmt. Das Pad weiss, dass der Sender einen neuen Schlüssel verwendet, den es versteht. Im schlimmsten Fall geht das Paket vom Pad zum Sender verloren, so dass der Sender nicht erfährt, dass das Pad den neuen Schlüssel auch hat, und daher auf dem alten bleibt. Das Pad würde dann den neuen Schlüssel verwenden, der Sender den alten, und die zwei würden sich nicht verstehen.

Natürlich hat das eine Schwäche: Man in the Middle, aber da man Pairing jeweils einmal zu Hause macht, kann man die Wahrscheinlichkeit dafür etwas besser kontrollieren.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Do 22 Dez 2005, 22:18    Titel: Antworten mit Zitat

Andreas Müller hat folgendes geschrieben:
Ich finde es nicht lustig, wenn da plötzlich das ARM Relais klackert wenn ich am Pad mit dem Zünder hantiere. Echt spannend wird es, wenn das FIRE Relais verschweisste Kontakte hat...

Da dies ganz sicher beides nicht lustig ist braucht die Relais Box einen Master-Override Schlüsselschalter.
Ebenso muss die Box erkennen können wenn die Kontakte eines Relais verschweist sind. (Das konnte ja die bestehende schon)

Ne Firewall sollten wir noch einbauen! Very Happy Very Happy

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 22:50    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Ne Firewall sollten wir noch einbauen! Very Happy Very Happy

Ich hätte da eine Idee Wink
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Reinhard



Anmeldungsdatum: 18.04.2005
Beiträge: 346

BeitragVerfasst am: Fr 23 Dez 2005, 4:31    Titel: Antworten mit Zitat

Andreas Müller hat folgendes geschrieben:

Genau genommen ist das falsch...

...Sender: DES("ARM", x, hash("ARM", x))
Pad: DES("CONTINUITY", x+1, hash("CONTINUITY", x+1))
Sender: DES("FIRE", x+2, hash("FIRE", x+2))
Pad: DES("FIRED", x+3, hash("FIRED", x+3))
oder
Sender: DES("DISARM", x+2,hash("DISARM", x+2))
Pad: DES("DISARMED", x+3, hash("DISARMED", x+3))


Danke, wieder was dazugelernt. Idea

Eine kleine Idee zum Thema Performance ist mir noch eingefallen, eigentlich ist es nur die Fortführung meiner Vorherigen. In einer "langen" Pairingphase zwischen den Starts, tauschen Pad und Sender, mit den schon erwähnten Sicherungsmaßnahmen, zufallsgenerierte Onetimepads aus. Diese werden dann verwendet um die Befehle ans Pad und die Statusmeldungen zu verschlüsseln. Vorteil: Sehr schnell. Nachteil: Speichergröße für die Schlüssel (aber leicht ausreichend für ein paar Starts). Weiterer kleiner Vorteil bezüglich der Schnittstellengeschwindigkeit: Man muss keine 8Byte Blocke transportieren, 2-4Byte sollten je nach Sicherheitsbedürfnis vollkommen ausreichen. Wenn jemand wild durch die Gegend funkt, in der Hoffnung eine gültige Startsequenz zu erwischen, wird er selbst bei 2Byte Blöcken schon auffallen bevor er auch nur die Anlage scharfgeschalten hat (u.a. weil die Einträge im OTP schon längst ausgegangen ist). Er muss dann im Schnitt mehr als 2^16 Möglichkeiten ausprobieren. Mehr deshalb, weil ein Angreifer bei einer derartigen Herumprobiererei natürlich Gefahr läuft zwischen ARM- und FIRE-Befehl noch einen DISARM Befehl zu schicken. (Anm. habe die >2^16 nur schnell abgeschätzt, gut mögl. dass ich mich verrechnet habe).

Alternativ kann man das OTP auch in einem seriellem EEPROM speichern. Mit HW-Kosten von ein paar CHF hat man genug Speicher um 100e bis 1000e Starts abzusichern. Der Sender oder das Pad enthalten einfach zusätzlich einen zusätzlichen Sockel für das 2. EEPROM und einen HW-Zufallsgenerator, um das Pairing durchzuführen. Einzige Gefahr: Jemand klaut unbemerkt das EEPROM, kopiert es und bringt es wieder zurück.

Interessant finde ich aber den Unterschied zur klassischen Verwendung des OTP. Therotisch ist es hier möglich mit Brute-Force zum Ziel zu kommen, dafür ist das übliche Hauptproblem der Schlüsselverteilung nicht gegeben. (Die DES geschützte Übertragung des OTP über öffentliche Kanäle fällt in den meisten Anwendungen ja auch in die Kategorie "grober Unfug".)

Juerg hat folgendes geschrieben:
Ne Firewall sollten wir noch einbauen! Very Happy Very Happy

Man verwendet gleich kommerzielle IT. Starten über WLAN inkl. IDS und Angreiferortung Wink

Gruß
Reinhard
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Fr 23 Dez 2005, 8:15    Titel: Antworten mit Zitat

Reinhard hat folgendes geschrieben:
zufallsgenerierte Onetimepads aus. Diese werden dann verwendet um die Befehle ans Pad und die Statusmeldungen zu verschlüsseln. Vorteil: Sehr schnell. Nachteil:

Der noch wichtigere Nachteil scheint mir, dass man Onetime Pads synchronisieren muss, was bei einer Stromorientierten Übertragung hervorragend funktioniert, aber bei unabhängigen Paketen problematisch sein kann. Der EEPROM Platz hingegen ist wohl nicht schwierig aufzutreiben, rechte AVRs haben davon ein paar kB onboard, diese haben auch einen rechten USART on board, was ein anderes aufgeworfenes Problem adressiert.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Fr 23 Dez 2005, 8:35    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Wegen der benötigten 50/50 duty cycles bei Funkübertragung mit 433MHz Modulen.

Man sendet ja nicht dauernd (das wäre eine unötige Energieverschwendung und elektromagnetische Umweltverschmutzung), also verschlüsseln-senden/empfangen-entschlüsseln. Wo liegt das Problem? Ist wohl alles auch noch eine Frage des gewählten 433MHz Moduls.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Fr 23 Dez 2005, 10:03    Titel: Antworten mit Zitat

Alle Module die ich kenne benötigen ein gewisses Verhältnis von logisch 1/0, damit der Puffer-Kondensator nicht voll läuft. Klar gibt es auch Module mit integriertem Prozessor die einem das abnehmen, die kosten dann aber auch entsprechend mehr.
Beim Beginn eines Datenpaketes muss man also eine Präambel senden welche dafür sorgt, dass sich der Sender "einmittet". Erst danach kann man Daten übertragen.

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Fr 23 Dez 2005, 13:01    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Alle Module die ich kenne benötigen ein gewisses Verhältnis von logisch 1/0, damit der Puffer-Kondensator nicht voll läuft. Klar gibt es auch Module mit integriertem Prozessor die einem das abnehmen, die kosten dann aber auch entsprechend mehr.

Es verbietet ja niemand, dass man interruptgesteuert den USART laufend 0x55 senden lässt (50/50), ausser wenn ein Byte für ein Datenpaket zu übermitteln ist. Kommt 0x55 oder 0xaa im Datenpaket vor, sendet man diese als 0xaa,0x55 bzw 0xaa,0xaa. Der Empfänger ignoriert einfach alle nakten 0x55. Result: 50/50 mit ca 50kCycles/sec (geschätzt auf der Basis des Aufwandes dafür in FreeRTOS), d.h. weniger als 1% CPU.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Fr 23 Dez 2005, 18:44    Titel: Antworten mit Zitat

Ignorieren aller 0x55 wäre dann doch eine sehr spezialisierte Lösung. Wennschon entwickle ich ein serielles Protokoll welches alle Daten übertragen kann. Also Manchester Code... (kostet halt 50% der Bandbreite, aber das gilt auch für die 0x55 Lösung)
_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Fr 23 Dez 2005, 23:08    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Ignorieren aller 0x55 wäre dann doch eine sehr spezialisierte Lösung. Wennschon entwickle ich ein serielles Protokoll welches alle Daten übertragen kann. Also Manchester Code... (kostet halt 50% der Bandbreite, aber das gilt auch für die 0x55 Lösung)

Meine Beschreibung war anders: Das Protokoll ersetzt 0x55 durch 0xaa,0x55, und 0xaa durch 0xaa,0xaa. Wenn kein anderes Zeichen zum senden bereit ist, wird 0x55 gesendet, d.h. es wird der Kanal nur dann mit 0x55-Fülldaten gefüllt, wenn man nichts gescheiteres hat. Beim Empfangen werden alle 0x55 ignoriert, denen kein 0xaa vorangegangen ist, ebenso alle 0xaa ohne vorangehendes 0xaa.

1. Diese 0x55-Lösung ist nicht wirklich spezialisiert, die Idee ist auch nicht von mir, ich habe sie ausser beim Telemetriesenders des R-DAS auch schon anderswo gesehen (kann mich nur nicht mehr erinnern, wo das war, ähm Dingsheimer)
2. SLIP (Vorläufer von PPP) verwendet eine ähnliche Encapsulierung, gleiches Prinzip, allerdings mit anderen Zeichen
3. Das f-Protokoll von UUCP (aus den guten alten 70ern) verwendet eine ähnliche Encapsulierung, ebenfalls mit anderen Zeichen
4. Die 0x55 Lösung kostet nur für zwei von 256 Zeichen ein zusätzliches Byte, d.h. 0.8% Bandbreite (die Wahrscheinlichkeit für die zwei speziellen Zeichen im Datenstrom ist wegen der Verschlüsselung 2/256). Da die verschlüsselten Daten 50/50 sind (sonst ist die Verschlüsselung nichts wert), dürfte man nahe am Optimum sein. Der Framing-Overhead ist garantiert gravierender als diese 0.8%, vor allem bei den sehr kleinen Paketgrössen dieser Anwendung.
5. Wenn man synchrone Ãœbertragung macht, muss man auch Synchronisationszeichen senden, mit denen man mindestens so viel Bandbreite verliert.

Statt Manchester könnte man ja auch Eigth-to-Fourteen (EFM) wie bei der CD nehmen, oder EFMPlus wie bei der DVD, beide sind DC-frei, aber effizienter als Manchester. Beides ist aber nicht wirklich nötig, weil die Daten selbst schon DC-frei sind.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Fr 23 Dez 2005, 23:53    Titel: Antworten mit Zitat

Aber mit einem 0x55 pro 256 Zeichen wirst Du den Datenstrom nicht zuverlässig in den vorgegebenen Grenzen halten können. Da müsste schon jedes zweite Byte ein 0x55 sein und dann kannst du genauso gut gleich Manchester codieren.

Gruss

Jürg

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Sa 24 Dez 2005, 4:55    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Aber mit einem 0x55 pro 256 Zeichen wirst Du den Datenstrom nicht zuverlässig in den vorgegebenen Grenzen halten können. Da müsste schon jedes zweite Byte ein 0x55 sein und dann kannst du genauso gut gleich Manchester codieren.

Nein! Das ist nicht, was ich beschrieben habe!
1. Es werden dauernd 0x55 gesendet, ausser wenn andere Bytes zum Senden bereitstehen. D.h. solange niemand auf den Knopf drückt, werden nur 0x55 gesendet. Und das gibt genau 50/50.
2. Da die Daten verschlüsselt sind, sind 0 und 1 bits genau gleich häufig (jede Abweichung von dieser Statistik wäre eine Schwäche), also ebenfalls 50/50.

Die Aussage "ein 0x55 auf 256 Zeichen" bezog sich darauf, dass im verschlüsselten Datenstrom jedes Byte gleich wahrscheinlich ist, d.h. im Schnitt taucht pro 256 "echte" Zeichen genau ein "echtes" 0x55 im Datenstrom auf. Und nur für diese echten 0x55 wird das Escaping durch 0xaa benötigt.

Also: statt wie bei RS232 dauern logisch 1 zu senden, bis ein Zeichen anliegt, sendet man dauern das gleiche Zeichen, welches für DC-Freiheit sorgt und von der Gegenstelle als Füllzeichen erkannt wird. Nur wenn ein 0xaa vorausgeht, wird das 0x55 nicht als Füllzeichen angesehen, und als übermitteltes Datenbyte angesehen.

Ich finde es ausserordentlich interessant, wie hier die Verschlüsselung DC-Freiheit des codierten Signals erreicht, ohne die Bitrate wesentlich zu erhöhen. Die Verschlüsselung garantiert also, dass man selbst ohne irgend einem Modifikation (wie Manchester oder EFM oder EFM+) "den Datenstrom zuverlässig in den vorgegebenen Grenzen halten kann", um Deine Worte zu gebrauchen. Im Vergleich schneiden EFM und EFM+ beide schwach ab, da sie die Bitrate um über 50% erhöhen, und von Manchester wollen wir lieber gar nicht mehr reden.

Würde man übrigens tatsächlich synchrone Übermittlung verwenden, würde man genau das gleiche machen: Synchronisationszeichen senden, solange keine anderen Daten anliegen.

Die einzige Schwierigkeit ist, dass das so codierte Signal nicht RLL ist, wenn man aber das üblich RS232 Framing für die Zeichen verwendet, kann die RL nicht grösser als 9 Bitzeiten werden, was man wahrscheinlich recht gut verkraften kann.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    EURocketry Foren-Übersicht -> Zubehoer Alle Zeiten sind GMT + 2 Stunden
Gehe zu Seite Zurück  1, 2, 3  Weiter
Seite 2 von 3
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Powered by phpBB © 2001, 2002 phpBB Group
mtechnik