[...]Ich wollte in nächsten Tagen die Übertragung mit RFM70 testen[...]Aber währe schon nicht schlecht, wenn jemand etwas über Protokolle hier schreibt.
Oder wandert dieses Projekt in die Vergessenheit?
Hallo
Nein, in Vergessenheit ist es nicht gewandert, aber es hat etwas gedauert, bis die Leiterplatten gekommen sind. Zum Protokoll der RFM70.
Dreh- und Angelpunkt sollte der Beispiel-Code von Hope sein. Da muß lediglich die Funktion für die SPI-Schnittstelle an den jeweiligen Controller angepasst werden.
Der RFM70 kann bis zu sechs Epfangs-Adressen, die sogenannten Pipes, gleichzeitig auswerten. Als Sender wird immer nur eine Adresse genutzt. Als gundsätzliche Übertragung kann man einmal mit AutoAck oder ohne arbeiten. Das wird in den jeweiligen Registern und/oder im Sendebefehl festgelegt.
Ohne AutoAck:
Der Sender schickt ein Datenpaket an den Empfänger. Sobald alles abgeschickt ist wird ein Int. am Sender ausgelöst. Jetzt muß das Stausregster ausgewertet werden und das entsp. Int-Bit gelöscht werden. Das ganze kann per echter ISR oder per Polling gemacht werden
Der Epfänger löste seinerseits einen Int. aus, wenn die Daten korrekt angekommen sind. Auch hier das geliche Spiel: Int-Bit im Statusregister auswerten und dann löschen
Mit AutoAck:
Der Sender schickt ein Datenpaket an den Empfänger, dier Empfänger schickt automatisch ein ACK-Paket zurück, ohne daß man sich um irgendwas kümmern muß. Mit dem Ack-Paket kann man auch "gleichzeitg" Nutzdaten zurück schicken. Der Sender löst erst einen Int. aus, wenn das Ack-Paket korrekt zurück gekommen ist, oder die Anzahl der maximalen Wiederholugsversuche überschritten wurde. Im ersten Fall stehen die Ack-Daten im RX-Fifo des Senders. Was von beidem passiert ist, muß man im Status-Register auswerten. Hier ist ganz wichtig, das man im Fall der Wiederholungsüberschreitung per FlushTX den TX-Buffer zusätzlich zu den Int- Bits löscht.
Die Daten, die der Empfänger als Ack-Payload zurück schickt, müssen
vor der Übertragung im ACk-Payload-Register des Epfängers stehen.
Bei der AutocAck ist es auch wichtig, daß RX0 und TX die gleiche Adresse im Sender und Empfänger haben.
Der Wechsel von Daten, z.B. Adresse oder Kanal (Frequenz) sind immer sofort nach dem schreiben der entspr. Register gültig, da muß also nichts mehr zusätzlich initialisiert werden.
Da es mit in der Funkauslöser-Appl. darauf ankommt möglichst kurze Verzögerung beim Auslösen zu haben, ist der Sender ständig mit der Adresse der Pipe1 eingestellt. Hier verschicke ich per "ohne Ack" der Auslöse-Befehl. Die Einstellung der Blitzdauer erfolgt über Pipe0 per AutoAck. Hierbei wird immer erst die Adresse des einzustellenden Slave eingestellt und nach der Konfiguration wieder zurück auf Pipe1.
Insgesammt funktionieren die RFM70 erstaunlich gut. Der einzige Nachteil, der mir bis jetzt ausgefallen ist ist, daß der Baustein im Empfans-Mode kein Kostverächter ist. Der saugt sich dann ca. 20mA rein. Leider gibt es keine Möglichkeit, den in einen Dämmerzustand zu bringen, aus dem man den RFM70per Funk aufwecken kann. Beim Sender schaut das besser aus. Die komplette Schaltung mit RFM im TX-Mode, Dog-LCD und ATMEGA 168 brauch zwischen 0,5 und 0,7 mA im Standby.
Gruß Ulf
. Der Sender ist noch auf Lochraster und über ein PC-Kabel mit der Kamera verbunden. Beim Empfänger ist schon die erste Leiterplatte bestückt und im Gehäuse untergebracht. Der nimmt dann über ein SC300 Kabel Kontakt mit dem Blitz auf. Bis zu 1/320 hat es noch prima synchronisiert, ab 1/400 war dann der "Balken im Bild". Am Wochenende werde ich mal noch zwei Empfänger aufbauen und dann mal ausgiebig testen. 
3310 Display kostet nur 4€