Ich habe mich wieder mal mit dem RFM12 beschäftigt. Herausgekommen ist
eine drahtlose RS232 Übertragung mit einer einfacher FEC (forward error
correction).

Die Software ist sehr einfach gehalten und funktioniert nach folgendem
Prinzip:
Das Modul befindet sich im fast immer Empfangsmodus, die RX LED
leuchtet.
Trifft ein Byte über Funk ein, wird das komplette Paket empfangen und
über den UART weitergeleitet, falls dieses fehlerfrei empfangen wurde.
Außerdem leuchtet dann die OK LED.
Trifft ein Byte über den UART ein, wird es gespeichert und ein 100ms
Timer gestartet. Solange können neue Bytes eintreffen, die dem Paket
hinzugefügt werden. Nach 100ms oder falls eine entsprechende Anzahl an
Daten erreicht ist, wird das Modul auf Senden geschaltet (TX LED an) und
das Paket gesendet. Wenn gleichzeitig das andere Modul sendet, gehen
Daten verloren. Danach wird wieder auf RX umgeschaltet.

Das Paket ist einfach aufgebaut: Anzahl der zu übertragenden Bytes,
Daten und die Summe aller Bytes als Prüfsumme.
Alle Daten werden über einen einfachen Hamming Code übertragen, um eine
gewisse Fehlerkorrektur zu haben.
Sollte die Prüfsumme am Ende falsch sein, wird das Paket einfach
weggelassen (und die OK LED geht aus).

Das ganze ist keine ordentliche Lösung, funktioniert aber recht gut.
Meine Erfahrungen mit dem Modul sind, dass entweder die Daten alle
korrekt, oder komplett falsch ankommen (da andere Sender
dazwischengefunkt haben). Das erkennt dann die Prüfsumme.

Die Reichweite liegt bei >100m, solange keine anderen Sender in der Nähe
sind.

Hast du ggf nen Schaltplan dazu?
(Oder hab ich das jezt im Zip übersehen??)

Einen Schaltplan habe ich (noch) nicht gezeichnet, kann ich aber machen.
Die Belegung der LEDs ist in der leds.h festgelegt, das RFM12 hängt am
SPI Port (PORTB). Mehr braucht man nicht. Ich betreibe den AVR mit dem
10MHz Takt des RFM12.

Hier nochmal das ganze mit leicht optimierten Puffereinstellungen und
Schaltplan. Auch die Funktionen der LEDs haben sich leicht geändert.

Ich habe das ganze jetzt mehrere Stunden quer durchs Haus senden lassen:
Es gab keine Datenfehler außer wenn der 433MHz Sender vom
Funkthermometer gleichzeitig sendet. Die Module sind also relativ robust
was die Datenqualität angeht.

Joar da wird shcon einiges an Fehlerkorrektur drinnestecken :)
Wenn ich mal Zeit hab werd ich das mal versuchen aufzubauen, im Momment
ist leider imemr viel zu tun wegen Studium :(

Ich habe das ganze heute Nachmittag mal etwas getestet:
Ein Modul ist mit dem PC verbunden, beim anderen sind TXD und RXD
verbunden. Das Modul sendet also alle Daten zurück.
Beide Module sind etwa 25m und 2 Stockwerke entfernt.

Nach 4 Stunden hatte ich folgendes Ergebnis:
36412 gesendete Pakete zu je 64Bytes, davon empfangen: 36386
Das ergibt eine Verlusterate von 0,071%. Beschädigt kamen keine Pakete
an. Falls also ein Fehler aufgetreten ist, wurde das Paket garnicht erst
weitergeleitet.

Wenn ich das aufgebaut hab kann ich mich ja mal etwas an der
Weiterintwicklung der Firmeware beteiligen, da ich diese Semester eh
gerade Computernetworks (unter anderem gehts da halt auch um Wireless
Kommunikation) und InformationsTheorie/Kanalkodierung (sozusagen das
drunterliegende)
Man könnte ja noch ne Art ACK System einführen (wird ja eh gepuffert,
dann kann man auf dem "Rückweg" ein ACK huckepack tragen und ggf den
Buffer neu übertragen oder nen Fehler ausgeben)

Was mir gerade so einfällt: das wäre dann nen 1A WireLess ISP
(Bootloader vorausgesezt, bzw eine AVR der das in ISP umsezt)

Ich habe eine Version mit Rückantwort gerade ausprobiert: Es
funktioniert so naja.
Das Problem ist, das bei einer Neuübertragung der Empfangspuffer des
Senders überläuft wenn er weiterhin mit Daten vom PC beschäftigt wird.

Ich habe ein ganz einfaches System eingebaut:
Nach jedem empfangenen Packet sendet der Empfänger ein OK oder
beschädigt Zeichen zurück. Sollte innerhalb von 50ms nichts beim Sender
ankommen wird das Paket vom Sender automatisch nochmal übertragen. Nach
5 Versuchen geht eine Error LED an. Die Pakete werden fortlaufend
nummeriert, für den Fall, dass lediglich die OK Antwort vom Empfänger
nicht ankam.

Ein weiteres Problem ist, wenn beide Seiten gleichzeitig das Senden
anfangen.


Noch ein Nachtrag zur bisherigen Version: In der rf12.c muss bei
BUFF_SIZE der gleiche Wert eingestellt werden wie in der main.c. Das
habe ich in der letzter Version falsch gemacht: In der rf12.c muss
ebenfalls 64 eingestellt werden, sonst kann es zu Datenverlust kommen !

Heute Nacht lief der Sender mit der Empfangsbestätigung:
Von 27200 Paketen (je 127Bytes) kam 1 Paket nicht an, da der UART
Empfangspuffer überlief. Dadurch wurden 507Bytes beschädigt.
Um den Sender zu stören, habe ich einen weiteren Sender laufen lassen,
der alle 10s etwa 1s lang sendet.
Mit der alten Software ohne Korrektur hatte ich dann etwa 8,3% Verlust.

Ich glaube ich ersetzte den Hamming Code durch irgendetwas effizienteres
(oder lasse diesen ganz weg). Gibt es irgendeine Codierung, die etwa 50%
overhead erzeugt, aber trotzdem 1 Fehler pro Byte korrigieren kann ?

Lass den Hamming weg, das wird das Modul eh intern schon machen.
Man aknn nicht einen Fehler, sondern mindestens(!) einen Korrigieren,
mehr ginge nur mit Softdesicion problem ist nur: Wird der Empfang durch
ein anderes Modul gestört, nüzt (meist) die beste Fehlerkorrektur nix!
Man könnte höchstens noch mit der Symbolrate rumspielen aber ob das
alles was bringt? Leztendlich kommt ja schon das fertige DigitalSignal
"raus"

Benedikt hast du ICQ oder sowas und magst mir deine Nummer vieleicht mal
per mail/PN senden?

Hier der Code mit Neuanforderung der Daten:
Er funktioniert an sich problemlos, solange der UART Empfangspuffer
(momentan 512Bytes) nicht überläuft. Sobald die Übertragung allerdings
bidirektional wird, und beide Seiten gleichzeitig senden kann es zu
Problemen kommen. Anonsten sollten die Daten fehlerfrei ankommen. Ich
hatte trotz 10%iger Kanalstörung nur 0,004% Verluste und das auch nur
weil der Puffer übergelaufen ist.

Die 4 LEDs haben nun folgende Bedeutungen:
- RX
- TX
- Fehler oder Neuübertragung
- Power

Die todo Liste ist bei diesem Code lang:
- Wenn beide Module gleichzeitig senden müssen sie sich irgendwie einig
werden wer zuerst senden darf.
- Eine Flusskontrolle muss eingebaut werden (theoretisch gibt es in den
UART Routinen eine CTS Funktion, aber diese habe ich noch nie getestet).
Außerdem ist das dann keine echte transparente RS232 Brücke.
- Der Hamming Code braucht zuviel Übertragungsbandbreite. Irgendein
anderer Code (der z.B. nur etwa 50% overhead erzeugt) wäre besser. Ganz
ohne funktioniert es nicht, da zumindest Füllbits eingefügt werden
müssen, da der Empfänger ausreichend Pegelwechsel benötigt um den Takt
sauber wiederherzustellen (es kann ja sein, dass der Benutzer nur 0x00en
oder 0xFFen sendet). Anstelle sinnloser Füllbits ist eine sinnvolle
Codierung besser: Man verschwendet dadurch keine kostbare Bandbreite.
- Was tun wenn nach n Versuchen die Daten immer noch nicht gesendet sind
?
- Die Latenzzeit der Daten beträgt worst case 500ms selbst wenn keine
Übertragungsprobleme auftreten (mit Übertragungsproblemen können die
Daten um einige Sekunden verzögert werden, falls sie doch noch
ankommen).

http://de.wikipedia.org/wiki/Reed-Solomon-Code

Für das gleichzeitige Senden würde ich folgendes vorschlagen:
- Das Modul chekct ob der Kanal frei ist (Listen befor Talking)
- Wartet eine zufällig Zeit (Random Backoff delay)
- wartezit bis senden auf 50ms reduzieren ggf lieber eine großen
Sende/Empfangsbuffer und dafür weniger Daten/Paket senden.

ggf. XON/XOFF Protokoll? Das kann normal jedes Terminal.
es sind ja noch ein paar Pins frei am AVR, ggf könnte man sogar ne
Hardwareflußkontrolle implementieren, wer das nicht will kann dann
einfach RTS und CTS brücken (so wie mans normal auch macht) und verliert
dan ggf halt etwas das wäre dann aber noch transparent (vieleicht wäre
auch durch DipSchalter Protokoll/Übertragungsrate wählbar machen?)

Sollte nach X - Wiederholungen keine Antwort kommen könnte man einfach
einen Fehler ausgeben auf die UART und alle Daten verwerfen. (ggf. durch
LEDs zu signalisieren)

Benedikt K. wrote:
> ...Eine Flusskontrolle muss eingebaut werden (theoretisch gibt es in den
> UART Routinen eine CTS Funktion, aber diese habe ich noch nie getestet).
> Außerdem ist das dann keine echte transparente RS232 Brücke.

Warum dann nicht das altbekannte Software-Handshake (XON/XOFF) nutzen.
ein XOFF über die serielle Schnittstelle (zum PC) ausgeben, sobal der
Sendebuffer bei 400 Zeichen angekommen ist und ein XON, sobald er wieder
unter 100 Zeichen ist. Damit sollten einem halbwegs kontinuierlichen
Datenfluss nichts mehr im Wege stehen. Siehe
http://de.wikipedia.org/wiki/Datenflusskontrolle#S...

Dies wird meines Wissens defaultmäßig von vielen
Kommunikationsprogrammen unterstützt. Selbst von Hyperterminal.

Oder habe ich hier etwas wesentliches außeracht gelassen?

Gruß,

Klaus

Das Problem ist aber: Ich möchte das ganze nicht mit Terminalprogrammen
verwenden, sondern das ganze soll quasi ein drahtloses RS232 Kabel sein.
Im Idealfall sollte daher garkein Handshaking vorhanden sein, damit sich
das Kabel möglichst transparent verhält.
Ich werde aber mal ein CTS Handshaking implementieren, da das meiner
Meinung nach das am weitesten verbreiteste ist, und das ganze oft
hardwaremäßig von vielen größeren UARTs unterstützt wird.

Ich habe das ganze mal noch weiter entwickelt. Theoretisch sollten jetzt
19200Baud bidirektional möglich sein. Bei jeder Empfangsbestätigung
werden automatisch vorhandene Daten mitgesendet. Dadurch teilt sich die
Bandbreite auf beide Richtungen gleichmäßig auf, und die Bandbreite wird
besser ausgenutzt.
Weiterhin habe ich das ganze Programm etwas aufgeräumt und die Hamming
Kodierung entfernt um die vorhandene Bandbreite besser auszunutzen.
Stattdessen bekommen 0x00 und 0xFF einfach ein 0xAA Füllbyte
hinterhergeschickt, um den Bittakt im Empfänger zu synchronisieren (bei
vielen 0x00 oder 0xFF hintereinander gibt es ansonsten Probleme.) Für
diesen Tip möchte ich mich bei Läubi bedanken.
Die meisten Einstellungen der Paramater für den RF12 werden jetzt anhand
der eingestellten Baudrate (laut Datenblatt) optimal eingestellt. Die
Sende/Empfangsfrequenz ist in 4 gleichmäßig im zulässigen Frequenzband
unterteilten Frequenzen mit je 325kHz Bandbreite unterteil, die sich
(zumindest theoretisch) gegenseitig nicht stören dürften.

In einer Richtung sind die vollen 19200Baud möglich (wenn es keine
Störungen auf dem Funkkanal gibt). Werden Daten in beide Richtungen
übertragen, kommt aus irgendeinem Grund ab und zu zu Problemen und
schlimmstenfalls springt das ganze in einen Modus in dem viele Daten
beschädigt oder garnicht ankommen. Vielleicht findet jemand den Fehler,
ich suche jetzt schon seit Stunden, aber finde keinen.

Ebenso merkwürdig ist der Fehler beim CTS Handshake: Aus irgendeinem
Grund ist der Bytezähler nicht synchron zu den wirklick vorhandenen
Bytes im Puffer. So passiert es, dass durchschnittlich etwa 1Byte pro
1kByte verloren geht. Naja, nicht wirklich verloren, die Daten sind
schon noch im Puffer, nur der Puffer weiß das nicht, da der Zähler auf 0
steht. Sendet man weitere Daten, dann werden die fehlenden Daten
gesendet. Dieses Problem liegt definitiv am UART Empfangspuffer und hat
nichts mit dem eigentlichen Sender zu tun. Daher habe ich CTS und
RX_COUNT (beides ist für CTS notwendig) in der UART.h deaktiviert.

Wenn all diese Probleme gelöst sind, kann man einen Schritt weiter
gehen, und eine automatische Kanalbelegung und Baudratenwahl einbauen,
je nachdem wie die Übertragungsbedingungen sind.
Zusammen mit Läubi haben wir ein paar Ideen überlegt:
Man könnte z.b. 1x pro Sekunde ein "Keep Alive" Paket senden (falls
keine Daten zu senden sind) um zu prüfen ob der Empfänger noch da ist.
Falls keine Antwort nach mehreren Anfragen kommt, wechseln Sender und
Empfänger nach einen festen Schema die Kanäle. Hier muss man sich noch
genau überlegen, wie man es schafft, dass sich beide irgendwie finden,
wenn z.B. einer der beiden neu eingeschaltet wird.

Neue Version: Das CTS Problem ist behoben, die Flusskontrolle ist jetzt
eingebaut und aktiv. Auch die bidirektionalen Transfers sollten jetzt
problemlos funktionieren.
In meinen Tests habe ich in einer Richtung 160kByte mit CTS
Flusskontrolle gesendet, und gleichzeitig in der Gegenrichtung 100Bytes
alle 0,1s ohne Flusskontrolle. Beide Daten kamen immer vollständig und
richtig an (solange keine längeren Störungen durch andere Module
vorhanden waren). Die Datenrate lag dabei bei 1,6kByte bzw. 1kByte/s,
was insgesamt etwa 21kBit/s reine Nutzdatenrate ergibt.
Sollte die Übertragung gestört werden, sinkt die Datenrate, da die
übertragenen Daten neu übertragen werden müssen.

Tach auch!

Ich habe mir für die Funk-Geschichten mal ein Protokoll ausgedacht und
bin gerade dabei eine art netzwerk-stack dafür zu bauen ;)

Protokoll siehe hier:
http://www.das-labor.org/wiki/AirLAB_Protokoll_Version_0

@Sören H.
Wie weit bist du ? Dein Protokoll sieht gut durchdacht aus. Ich hatte
auch überlegt ob ich ein etwas komplizierteres einbaue, aber das macht
bei einer simplen 2 Punkt Verbindung mit mittelmäßiger Datensicherheit
eigentlich keinen Sinn, daher habe ich es gelassen und stattdessen nur 1
Pakettyp eingebaut der 1 Statusbyte und ansonsten 0-128Bytes Nutzdaten
enthält. Das hat den Vorteil, dass ich gleichzeitig die
Empfangsbestätigung und Nutzdaten senden kann, und sich die Bandbreite
so automatisch gleichmäßig auf beide Richtungen aufteilt, da beide
aufgrund der Bestätigung immer abwechselnd senden.


Im Anhang ist eine neue Version, bei der sich die Einstellungen per DIP
Schalter an PortC vornehmen lassen. So kann man leicht die Baudrate und
einen von 4 Funkkanälen einstellen ohne die Software anpassen zu müssen.
Je höher die Baudrate, desto geringer wird die Reichweite.

Hallo an alle,

an dieser Stelle mal - HELP!

Ich hatte vor einiger Zeit angefangen diesen Treat hier mitzulesen und
auch drüber nachzudenken. Dummerweise war es mir jetzt eine Weile nicht
möglich und ich habe völlig den Überblick verloren was Stand der Dinge
ist.

Gibt es eine "Projektseite" auf der man den momentanen Stand sehen kann?
Ich bräuchte nur etwas was sich wie ein serielles Kabel verhält
(allerdings mit Fehlerkorrektur) - Handshaking nicht nötig.
Ist die Entwicklung schon so weit gediegen?

Für den Fall das ich auch was helfen kann: Ich muss demnächst bei PCB
Pool bestellen und habe noch Platz auf der Platine - doppelseitig, DK,
Verzinnt aber kein Stoplack. Wenn hier jemand an einem vernünfitgen
redesign arbeitet bin ich gerne bereit es mit auf die Platine zu setzen,
selbige machen zu lassen, wenn sie da ist die anderen Platinen
auszufräsen und dem mit demjenigen per post zukommen zu lassen.

Sorry das ich jetzt hier nach einer "Zusammenfassung" frage aber in 2
Treats zusammen knapp 400 Einträge lesen ist heftigst zumal hier einige
bestimmt mehr Übersicht haben.

Grüße!

 Tobi

Geht mir grad genauso, deswegen weiß ich nicht genau, wie Benedikt jetzt
das Protokoll integriert hat, aber ich habe da auch eine Idee:

Ein Ping/Pong Protokoll. Sprich: Die beiden Funkmodule spielen sich
gegenseitig die Sendeerlaubnis zu. Es kommt dann ein kleiner Header in
das Protokoll, mit der Länge der Nutzbytes in diesem Paket.

Kommt nun an Transceiver1 ein Datenpaket über das UART, wird es einfach
in den TX-Buffer geschrieben - fertig.

Jetzt wartet Transceiver auf das nächste empfangene Paket. Guckt nach,
ob Bytes im Paket sind. Wenn ja - legt er die Bytes in den RX-Buffer und
startet einen Interrupt-gesteuerten UART-Versand.
Danach kommt nun sein eigener TX-Buffer an die Reihe. Transceiver1
erstellt jetzt ein Paket und lädt die Bytes aus dem TX-Buffer in das
Paket, und sendet das Paket. Das ganze passiert jetzt innerhalb
Transceiver2.

Also: Wenn keine Daten versendet werden, spielen sich die beiden
Transceiver einfach nur leere Pakete zu. Haben sie was zu senden, hängen
sie es an. Kommt was an - wirds über den UART ausgegeben.


Ich hab nur gerade die böse Ahnung, dass Benedikt das bereits so
integriert hat. Aber sicher bin ich mir nicht.

PS: Ein Problem hat man bei der Variante noch: Welcher Transceiver
startet den ersten Sendeprozess um den Ping/Pong Prozess anzustoßen...

Da sich vermutlich an dieser Software demnächst kaum noch viel an den
Features ändern wird, hier mal die zusammenfassung der letzten Version:

Die Software stellt eine transparente RS232 Verbindung dar, verhält sich
also im Prinzip wie ein RS232 Kabel, allerdings mit einer Laufzeit von
worst case wenigen 100ms.
Die Baudrate ist über DIP Schalter an PortC von 1200 bis 115200Baud
einstellbar (siehe dazu auch Software mit den Zusatzbemerkungen.) Hohe
Baudraten werden zwar unterstützt, das Modul wird aber mit maximal
50kBaud betrieben. Man kann die 115200Baud also nicht voll ausnutzen.
Bei so hohen Datenraten sind die Fehlerrate und die Reichweite meiner
Meinung nach zu schlecht, daher diese Einschränkung. 20m 19200Baud voll
ausgenutzt mit Halbduplex über 20m sind aber bei mir zumindest kein
Problem.
Über die DIP Schalter lässt sicher außerdem eine von 4 möglichen
Frequenzen einstellen (alle innerhalb des zulässigen 433MHz Bandes).

Die Daten werden mit einem einfachen Protokoll übertragen:
- Status (momentan nur als Empfangsbestätigung genutzt)
- Anzahl der zu übertragenden Bytes
- Paketnummer (um Mehrfachübertragungen zu erkennen)
- Nutzdaten

Nach jeder Übertragung wird eine Empfangsbestätigung gesendet. Falls
diese ausbleibt, wird automatisch das Paket nochmal gesendet, solange
bis die Bestätigung eintrifft, oder die Anzahl einen eingestellten Wert
überschreitet. Die Empfangsbestätigung wird nur gesendet, wenn die Daten
fehlerfrei empfangen wurden.
Da das ganze im Ping-Pong Verfahren läuft, und in jedem Paket Nutzdaten
enthalten sein können, kommt jeder der beiden Teilnehmer abwechselnd
dran um seine Daten loszuwerden. Dadurch teilt sich die Bandbreite auf
beide Richtungen gleichmäßig auf.

Sollte der 512Byte große Eingangspuffer zu mehr als der Hälfte gefüllt
sein, wird ein Pin aktiv der mit CTS verbunden werden kann, um so ein
einfaches Handshaking zu ermöglich.

Hi Benedikt!

Ersmal danke da Du dir a) die Mühe gemacht hast diesen Riesenhaufen
Arbeit zu machen und b) hier alles zusammengefasst hast.

Noch ein paar fragen -
Geschrieben in AVRGCC vermute ich? Gibt es fertig compilierte HEX files?
- Ich bin halt Codevision Anhänger

Welche Hardware wird benutzt? Die von Manuel?

Gibt es ein Simpel Moduld was kein USB hat oder kann das bestehende ohne
USB genutzt werden?

Nochmal Sorry fürs blöd fragen aber eine Zusammenfassung ist sicherlich
von vielen begrüßt.

Sollte ich das mit dem rework des designs besser in den Threat posten in
dem das "originaldesign" auch ist?

Tobi

Benedikt, wodurch wird denn der "Ping-Pong"-Prozess angestoßen? Durch
den, der als erstes was zu senden hat? Was ist wenn beide genau
gleichzeitig senden? ;)

Man könnte den Ping Pong prozess anstossen indem wirklich beide zufällig
senden jedoch mit unterschiedlichen "Wartezeiten" für die
Initiallisierung.
Wenn es auf der Luftstrecke kracht dann wartet einer z.B. 200 ms und der
andere 500 ms (vielleicht "zufällig"?) bevor er es erneut probiert so
das dann einer irgendwann senden kann und der andere es empfängt und
bestätigt.

Kam mir nur grad so in den Sinn.

Tobias A. wrote:
> Man könnte den Ping Pong prozess anstossen indem wirklich beide zufällig
> senden jedoch mit unterschiedlichen "Wartezeiten" für die
> Initiallisierung.
> Wenn es auf der Luftstrecke kracht dann wartet einer z.B. 200 ms und der
> andere 500 ms (vielleicht "zufällig"?) bevor er es erneut probiert so
> das dann einer irgendwann senden kann und der andere es empfängt und
> bestätigt.
>
> Kam mir nur grad so in den Sinn.

Wenn ich beiden unterschiedliche Wartezeiten einprogrammiere, brauche
ich ja wieder 2 "verschiedene" Programme.

Zufällig: Auch problematisch, da man keine gescheite Zufallsquelle ohne
weiteres in nem Mikrocontroller hat.

Hmmmm...

die AVRs haben doch ne seriennummer, oder? Können die die selbst lesen?
Damit könnte man doch dann was machen, oder?

Ausserdem denke ich das das Problem nur dann wirklich kritisch wird wenn
beide Module 100 gleichzeitig angeschaltet werden bzw. die zyklen
synchron sind.
Alternativ könnte man auch mehrere Wartezeiten nehmen und die
durchtesten. Alternativ hochzählen so im Stil von


For i = 1 to 25
 Begin
delay_ms(20 * i)
 End

Weil die wahrsch das man dann beide Module synchron hat ist dann sehr
gering und notfalls muss man eins mal resetten.
Oder man treibt es noch weiter und bringt es dazu sich selbst zu
resetten indem man den C am RC des Reset pins mit einem Widerstand und
Portpin richtung masse entläd. Die R und C toleranzen sollte dann
spätestens ausreichen damit sich das einpendelt.

Wie gesagt das kam mir nur so in den Sinn.

Benedikt K. wrote:
> Dadurch teilt sich die Bandbreite auf beide Richtungen gleichmäßig auf.

Wenn ich den bisherigen Thread und den Rest Deiner Beschreibung richtig
verstanden habe, stimmt das nicht ganz. Die Bandbreite wird dann
gleichmäßig aufgeteilt, wenn von beiden Seiten ständig Daten gesendet
werden. Sobald eine Seite die Pakete aber nicht bis zur maximalen Größe
auffüllt, steht die restliche Bandbreite der Gegenseite zur Verfügung.

> Sollte der 512Byte große Eingangspuffer zu mehr als der Hälfte gefüllt
> sein, wird ein Pin aktiv der mit CTS verbunden werden kann, um so ein
> einfaches Handshaking zu ermöglich.

Um die Transparenz der Strecke weiter zu erhöhen, könnte man auf beiden
Seiten noch die RTS-Leitung des angeschlossenen Geräts überprüfen und in
die Flußsteuerung einbeziehen.

Moin,

also ich habe schon ein einfaches Ping-Pong gebaut und die Datenpakete
und crc16 implementiert.

Ich schätze am Ende der Woche wird dann alles fertig & nutzbar sein. Ich
werd's dann in ein öffentliches svn stellen und hier verlinken.

Zum Thema Device IDs:
Ich habe mir schon nen Wolf danach gesucht, die Device ID von nem AVR
rauszubekommen, allerdings ohne Erfolg.

Allerdings gibt es noch drei evtl. brauchbare Alternativen:

1. Device lauscht erstmal für ein paar Sekunden und guckt, welche Device
IDs es denn schon so gibt. Dann fängt es an zu senden und fragt, ob
jemand die Adresse bereits hat (via Ping), wenn ja, zählt es die Adresse
solange hoch, bis niemand mehr antwortet und nimmt sich dann die
Adresse. Dann weiss man allerdings nach einiger Zeit garantiert nicht
mehr, welches Gerät welche adresse hat und bräuchte zusätzlich eine
Namensauflösung. Aber auch den Namen muss man dem Ding erstmal geben,
womit wir wieder am Anfang des Problems wären ;)

2. Man speichert im EEPROM einfach die ID.

3. Man compiled für jedes device die Software neu und generiert sich
eine ID aus den Macros _TIME_ und/oder _DATE_ (und brennt diese dann
ins EEPROM)...

Tobias A. wrote:
> Hmmmm...
>
> die AVRs haben doch ne seriennummer, oder? Können die die selbst lesen?
> Damit könnte man doch dann was machen, oder?

Eine Seriennummer nicht. Aber die Idee ist garnicht mal so schlecht: Ich
kann mit meinem AVRISP MKII ein Calibration Byte anzeigen lassen. Das
könnte ich sogar in die letzte Flashzelle schreiben (so wie das idR auch
gemacht wird). Für den einen Prozessor war das für 8MHz zum Beispiel
0xC2 und für den anderen 0xC4.... Hm!

> Ausserdem denke ich das das Problem nur dann wirklich kritisch wird wenn
> beide Module 100 gleichzeitig angeschaltet werden bzw. die zyklen
> synchron sind.

Könnte doch durchaus passieren...

> Alternativ könnte man auch mehrere Wartezeiten nehmen und die
> durchtesten. Alternativ hochzählen so im Stil von
>
>
> For i = 1 to 25
>  Begin
> delay_ms(20 * i)
>  End
>
> Weil die wahrsch das man dann beide Module synchron hat ist dann sehr
> gering und notfalls muss man eins mal resetten.

Nuja, eben. Man muss einfach eine Unterscheidung zwischen den
Mikrocontrollern haben, obwohl das gleiche Programm drin ist.
Sag du mal einem Käufer dieser RS232 Funkbrücke "Ja, resetten sie mal
die eine Seite" ;)

PS: Habe das gerade auch in meine TRW24G 2,4ghz Funkmodule mal
implementiert. Im moment habe ich noch eine Präpro-direktive "INITIATE".
Für einen Controller setze ich die einfach, für den anderen nicht.

Da ich das ganze aber eher als "Modul" in meine Software hängen will,
wäre ne möglichst einfache Lösung schon nicht schlecht.

Sören H. wrote:
> Zum Thema Device IDs:
> Ich habe mir schon nen Wolf danach gesucht, die Device ID von nem AVR
> rauszubekommen, allerdings ohne Erfolg.

Die kann man nur per Programmer auslesen, und selbst wenn: Aller AVRs
eines Typs haben die gleiche ID, also bringt das nichts.

Mehrer IDs machen bei 2 Teilnehmern recht wenig Sinn. Sobald es mehr
werden  braucht man die, das ist klar, aber in den meisten Fällen reicht
eine einzige Punkt zu Punkt Verbindung.

Simon Küppers wrote:
> Benedikt, wodurch wird denn der "Ping-Pong"-Prozess angestoßen? Durch
> den, der als erstes was zu senden hat? Was ist wenn beide genau
> gleichzeitig senden? ;)

Dann gibt es Probleme. Allerdings habe ich den Timer der als Timeout für
eine Nochmal-Übertragung dient absichtlich auf 2ms Auflösung
eingestellt. Dies ergibt eine hohe Warscheinlichkeit, das eines der
Module etwas früher sendet als das andere und dass es danach wieder
klappt.

Tobias A. wrote:
> Noch ein paar fragen -
> Geschrieben in AVRGCC vermute ich? Gibt es fertig compilierte HEX files?
> - Ich bin halt Codevision Anhänger

Ja. main.hex in der Zip.

> Welche Hardware wird benutzt? Die von Manuel?

Meine, siehe Zip Datei.

> Gibt es ein Simpel Moduld was kein USB hat oder kann das bestehende ohne
> USB genutzt werden?

Meines läuft mit RS232, man kann es also mit TTL RS232, mit einem MAX232
oder einem FT232 verwenden.


Reinhard Max wrote:
> Benedikt K. wrote:
>> Dadurch teilt sich die Bandbreite auf beide Richtungen gleichmäßig auf.
>
> Wenn ich den bisherigen Thread und den Rest Deiner Beschreibung richtig
> verstanden habe, stimmt das nicht ganz. Die Bandbreite wird dann
> gleichmäßig aufgeteilt, wenn von beiden Seiten ständig Daten gesendet
> werden. Sobald eine Seite die Pakete aber nicht bis zur maximalen Größe
> auffüllt, steht die restliche Bandbreite der Gegenseite zur Verfügung.

OK, stimmt. Hatte ich etwas dumm beschrieben. Der wo mehr sendet bekommt
mehr Bandbreite, aber der wo weniger sendet wird seine Daten trotzdem
los. Ist etwas schwierig zu beschreiben.

>> Sollte der 512Byte große Eingangspuffer zu mehr als der Hälfte gefüllt
>> sein, wird ein Pin aktiv der mit CTS verbunden werden kann, um so ein
>> einfaches Handshaking zu ermöglich.
>
> Um die Transparenz der Strecke weiter zu erhöhen, könnte man auf beiden
> Seiten noch die RTS-Leitung des angeschlossenen Geräts überprüfen und in
> die Flußsteuerung einbeziehen.

Muss ich mal versuchen. Allerdings wird das ein wenig Arbeit, da ich
dazu die UART Routinen großteils umschreiben muss, und auch das RTS
Signal über Funk an den Sender weiterleiten muss, damit dieser nicht
weiter sendet. Es kann also noch ein weilchen dauern, denn ich habe
ehrlich gesagt keinen Bedarf dafür, da ich keinerei Hardware besitze die
dieses Feature benötigt.

Hi Benedikt

danke


>> Welche Hardware wird benutzt? Die von Manuel?

>Meine, siehe Zip Datei.

Sind die Layout files frei verfügbar?

Tobi

Wenn es ein Layout geben würde, dann würde ich dieses hier reinstellen.
Momentan ist alles auf Lochraster aufgebaut.

Hi Benedikt - ist es ok wenn ich ein Layout gemäß deines Schaltplans
erstelle und hier reinstelle?

Tobi

Kannst du gerne machen. Seh mal PD3 als CTS Eingang vor mit dem andere
Geräte den Empfänger ausbremsen können. Davon abgesehen, denke ich
nicht, dass sich demnächst die Pinbelegung ändert. Um ganz sicher zu
gehen, könntest du noch FFIT an PB0 legen, falls das Modul auch mal
Interruptgesteuert betrieben wird.

Soll ich die Version mit oder ohne Dip Brücke machen?

Nur so generell: was meinst Du zu folgendem?
Keine Dipbrücke dafür ein extra Pin der dem Mega entweder in einen
Konfigmodus versetzt so das die Daten die via rxd reinkommen zum
Konfigurieren verwendet werden können.
Z.B.
Mega Pin auf High - normaler Betrieb - daten werden ans Sendemodul
weitergereicht und emfpangene daten vom Sendemodul an TXD ausgespuckt.

Mega Pin auf Low - konfigurations betrieb - gesendete Zeichen werden zum
setzen von Baudrate etc verwendet und quittiert.

Nur ein Vorschlag, bin natürlich auch gerne gewillt eine der
exisitierenden Versionen umzusetzen.


Tobi

Mir ist es egal, ich kann sowas einbauen.
Bei dem DIP Schalter hatte ich mir nur folgendes gedacht: Man kann
jederzeit ohne spezielle Software die Einstellungen verändern. Denn die
Erfahrung zeigt: Immer genau dann wenn man die Konfigurationssoftware
braucht, hat man sie nicht.

Das kommt auf die Gestaltung des Konfigurationsmodus an. Wenn er
Textbefehle akzeptiert reicht als Konfigurationssoftware ein
Terminalprogramm, was heute bei praktisch allen Betribssystemen zum
Bordwerkzeug gehört.

>Bei dem DIP Schalter hatte ich mir nur folgendes gedacht: Man kann
>jederzeit ohne spezielle Software die Einstellungen verändern.

und es ist eine sichtbare Kontrolle der eingestellten Baudrate da.
ohne irgendwelche Ports zu belegen.

Ich finde die Dipschalter-Variante durchaus Praktisch.
aber das ist wohl sicher Ansichtssache.

Respekt Benedikt!

Wigbert

Wigbert P. wrote:
> und es ist eine sichtbare Kontrolle der eingestellten Baudrate da.
> ohne irgendwelche Ports zu belegen.

Belegen die DIP-Schalter denn keine Portpins? ;)

Ok, richtig.

Ich fand das eben praktischer, als noch LED's einzubauen.
und erst noch Software-Einstellungen durchführen zu müssen.
Ist vielleicht auch Anwenderbedingt.


>aber das ist wohl sicher Ansichtssache!!

egal "Jedem das Seine"


Wigbert

Na ja ich fang dann mal an zu stricken...

@ Reinhard
genau das hatte ich auch im Sinn

Man lässt das Modul bei Startup in einer bestimmten baudrate laufen und
ändert sie dann bei bedarf via textcommando.

@ Benedikt

<Kannst du gerne machen. Seh mal PD3 als CTS Eingang vor mit dem andere
<Geräte den Empfänger ausbremsen können. Davon abgesehen, denke ich
<nicht, dass sich demnächst die Pinbelegung ändert. Um ganz sicher zu
<gehen, könntest du noch FFIT an PB0 legen, falls das Modul auch mal
<Interruptgesteuert betrieben wird.

Warum PD3 und nicht 2 so wie im schaltplan?

Warum FFIT and PB0 wo doch der Prozessorinterrupt auf PD2 und PD3 liegt?
oder meinst Du es umgekehrt - das modul interrupten?

Das passt schon so:
PD0 RXD
PD1 TXD
PD2 CTS
PD3 RTS

PB0 FFIT
Ich nutze den Input Compare Interrupt als Externen Interrupt. So habe
ich alle RFM12 Pins an PortB und nirgendwo anderst.

ok wird gemacht.
Morgen gegen mittag sollte ich fertig sein. Will gleich mal ins Bett.

ok

konnte es doch nicht lassen

hier mal der Schaltplan

und hier das Layout

bei einer 1.6 mm Platine muss ich nochmal gucken wie das mit den 50 Ohm
für die Antenne wird. Aber bei dem Modul wage ich eh zu bezweifeln was
passiert wenn man vom Modul auf die Trägerplatine wechselt.
Ich hab grad die Formel für Microstrip Transmission Line nicht im
Hinterkopf.


Irgendwer generelle Kommentare?

Ich mag das mit der Konfiguration via Terminal Programm anstatt DIP
Schalter. (Wenn Du willst Benedikt mach ich noch ein 2. Layout)
Macht die Sache kleiner und billiger (weniger PCB platz und die DIP
Brücke spart man auch)

Tobias A. wrote:
> Irgendwer generelle Kommentare?

IEH. Benutzt du keine oktagonalen Vias? ;)

Sieht ansonsten nett aus, aber ich würde dir das .png Bildformat statt
.jpg empfehlen bei Schaltplänen/Boards.

Jut nacht!

Wie wird der mega8 programmiert ? Ich sehe nirgends eine Verbindung zu
den ISP Pins.

Hi Benedikt

ja Du hast recht das ist mir gestern entfallen - wollte ich noch machen.
Magst Du mir mal einen Gefallen tun und gucken ob Deine Schaltung noch
mit sagen wir 5 bis 10 k in Serie in den Datenleitungen funktioniert?
Dann schnall ich die zwischen Funkmodul und ATMEGA und den Programming
header direkt dran.
Je nachdem werd ich auch noch die LEDs draufsetzen.

@ Simon

doch auch. Mir war nur grad nach eckig :-) Hast aber natürlich recht -
anders siehts besser aus.

Tobi

Tobias A. wrote:
> Hi Benedikt
>
> ja Du hast recht das ist mir gestern entfallen - wollte ich noch machen.
> Magst Du mir mal einen Gefallen tun und gucken ob Deine Schaltung noch
> mit sagen wir 5 bis 10 k in Serie in den Datenleitungen funktioniert?
> Dann schnall ich die zwischen Funkmodul und ATMEGA und den Programming
> header direkt dran.

Das brauch ich garnicht auszuprobieren, denn es geht ziemlich sicher
nicht. Was sollen die denn bewirken ?

Hallo Benedikt und Tobias

>mach ich noch ein 2. Layout

bevor Du Dich in Unkosten stürzt.
Ich werde Benedikts Vatiante(mit Dip-Schalter) aufbauen.

Benedikt ich hoffe Du bist einverstanden.

Dabei werden Dip-Codier-Drehschalter verwendet.
Es wird ein Max 3232 o.ä. drauf sein(weil ich das so brauche)
Das ganze sollte über ein kleinen Akku(Grösse hängt vom Gehäuse ab)
versorgt werden.
Und Platinenantenne.
Und Gehäuse.

Schön wäre es, wenn eine AKkuspannungsanzeige im Code mit eingearbeitet
würde.Die 4 LED's leuchten bei 100%, 3 bei 75%,2 bei 50%,1 bei 25%
Wenn ein Taster gedrückt ,Sprung in Akkukontrolle.Spannung extern mit
Spannungsteiler einstellbar. 2ADC Pins wären ja noch frei.
Vielleicht hast Du Benedikt an einen Regentag mal Langeweile.

Wigbert

Hi Benedikt

die bewirken folgendes:

Die Ausgänge des AVR gehen direkt zum programming header und von da aus
über einen Widerstand zum Funkmodul.

Wenn man nun programmiert und sagen wir ein "high" auf einer
Programmerleitung liegt das Funkmodul aber ein "low" zieht würde es ohne
die Widerstände "krachen" und es könnte sein, das irgendwas beschädigt
wird.
Mit den Widerständen sind die Ausgänge der Funkmoduls quasi pullup bzw
pulldown je nachdem wie sie grad "stehen".

Wenn die Schaltung oben funzt, werd ich noch ein "Master"Modul
entwickeln was dann via FTDI chip eine USB verbindung herstellt.


@ wigbert

ok dann mach Du das. Arbeitsteilung ist immer gut :-) Ich würde
allerdings (wenn ich Dir widersprechen darf) sagen das es vielleicht
erstmal wichtiger ist die Latenzzeiten etwas zu drücken anstatt das
ganze weiter aufzublasen - es sollte ja einfach sein.
Ich weiss sowieso nicht wie busy der Mega 8 ist. Wenn der ziemlich
ausgelastet ist, ist mit extra programm für andere anwendungen
reinbrennen eh nicht viel und man braucht einen 2. µC. (nur daten ins
nirvana senden macht ja auch keinen Sinn) und mit dem könnte man dann
die Batterieüberwachiung machen.
Das hier sollte ja wenn ich es richtig verstehe ein sehr spartanisch
gehaltenes, schnick-schnack freies (wie Hornbach G) modul werden was
als Funkbrücke fungiert.

Tobi

Tobias A. wrote:
> Wenn man nun programmiert und sagen wir ein "high" auf einer
> Programmerleitung liegt das Funkmodul aber ein "low" zieht würde es ohne
> die Widerstände "krachen" und es könnte sein, das irgendwas beschädigt
> wird.

Häng einfach einen Pullup an nSEL, so wie ich es gemacht habe. Dann ist
das RFM12 abgeschaltet und man kann auf den Pfusch mit den Widerständen
verzichten. Das funktioniert sicher und ist weniger Aufwand.

"man kann auf den Pfusch mit den Widerständen verzichten."

Das ist von einer Atmel appnote aber ok.
Ich werd dann gleich die änderungen vornehmen.

Hi Tobi,
die Entwicklung dieser Funkbrücke ist wohl soweit abgehakt.
Ich möchte wohl so ähnlich wie Benedikt ein "drahtloses RS232 Kabel"
mir herstellen, mehr eben nicht.
Schnickschack kann hilfreich sein, wie Baudrateneinstellung,
na ja und manchmal hätte ich gerne gewusst, schaffst Du den
Download mit den Akku oder nicht.Ich wollte eigentlich nur wissen
ob ich Pins auf den Board vorsehen kann oder nicht.
Aber wenn das nicht geht, auch nicht weiter schlimm.


Wigbert

Hi hier mal der neue Schaltplan