Hallo, nachdem ich mir jetzt schon seit Tagen einen abbreche mit den RFM22B Modulen, will ich es jetzt hier mal versuchen. Ich habe eine Funkstrecke bei 868MHz im FIFO Modus aufgebaut. Erst wollte das ganze überhaupt nicht funktionieren, bis ich dahinter gekommen bin, daß ich die Datenraten nur bis maximal rund 160kbps einstellen darf. Bei 180 kbps geht definitiv nichts mehr. Ich verwende Manchesterkodierung, Preambel = 32 Bit, 2x Sync und 1 Header. Modulation habe ich zwischen 100kHz und 180kHz ausprobiert. Die Einstellungen habe ich mit dem Exelsheet von Hope und auch mal mit der Wireless Development Suite von Silicon Labs konfiguriert. Register 58h steht auf ED ;-). Hat hier vielleicht jemand ne Ahnung, warum ich nicht über 160kbps komme und dann keine Verbindung mehr zustande kommt? Gruß, Dirk
Weil du bei Manchester-Codierung die doppelte Bandbreite benötigst und der RFM22B zwar Manchester-Codierung verarbeiten kann, aber dann nur bis 128kbps spezifiziert ist?
Hm, ... ich hatte eigentlich angenommen, daß als "data rate" die Bruttodatenrate im Kanal gemeint war. Wenn das die Nettodatenrate ist, dann könnte der RFM22B ja sogar 320kbps verarbeiten. Ich werde mir das mal auf dem Oszi angucken. Danke erst mal für die Antwort.
Hallo, in den HopeRF Modulen sind augenscheinlich die Silabs 4432 drin. Da ist die Maximale Bruttodatenrate bei 128kbps. Die 256kbps gehen nur, wenn man den FIFO nicht benutzt. Mit Manchester bleiben also noch 64kbps übrig. Das die Dinger überhaupt mit 160kbps funktionieren wundert mich. Grüße Fasti
Och, wo steht das, daß die RFMs nur bis 256kB gehen, wenn die FIFOs nicht verwendet werden? Ich hab die RFMs jetzt zwar auf 120kbps runtergeschraubt, aber besser als bei 160kbps gehen die jetzt auch nicht. Ich teste im Moment aber auch nicht auf Entfernung, aber immerhin ohne Sendeantenne ;-). Ich brauch nur max. 50m. Mal davon abgesehen hat sich bei meinem Modul ein sehr eigenartiger Fehler aufgetan. Ich kann den RX FIFO nicht löschen. TX FIFO geht, aber wenn ich das ACK Byte einmal empfangen habe, dann zeigt das Modul immer ACK an, obwohl ich just vor dem Auslesen des FIFOs eben jenes lösche. (Ja, mit 1 und dann 0 im Register 08h ;-)) Hat jemand schon mal so ein Verhalten bei den Modulen beobachtet. Woran kann das liegen? Gruß, Dirk
p.s. Hab inzwischen auch das "Kleingedruckte" im Exelsheet gefunden. Die einzutragende Datenrate ist die Datenrate vor dem Manchesterencoding. Dann machen die RFMs anscheinend tatsächlich 320kbps brutto ;-).
So, da bin ich wieder ;-) Könnte mir vielleicht jemand, der mit den RFM22B Modulen arbeitet, mal den Gefallen tun und checken, ob er bei den Teilen den Empfangs-FIFO löschen kann? Ich verwende foolgenden Code für Atmel ATMega: CLR_FIFO: ; bit 1 = ffclrrx / RX FIFO Reset/Clear first 1, then 0 ; bit 0 = ffclrtx / TX FIFO Reset/Clear first 1, then 0 ldi work, 0x03 ; first write with "1" ldi spi_adr, 0x08 ; set address rcall SPI_WRITE ; send data to the RFM22B ldi work, 0x00 ; second write with "0" ldi spi_adr, 0x08 ; set address rcall SPI_WRITE ; send data to the RFM22B ret Das Sende-FIFO scheint sich so tatsächlich löschen zu lassen, aber das Empfangs-FIFO definitv nicht. Kann jemand helfen? So langsam glaube ich, daß die Dinger einen Bug haben. Gruß, Dirk
Etwas zu wenig Code, um schnell mal auszuprobieren. Hardware liegt ohnehin woanders. Habe selbst mit den Transceivern noch nicht viel mit 'low-level'-Registerzugriffen programmiert, da ich hier mit portierter Software vom IC-Hersteller experimentiert habe, in der vieles vorgekaut ist. Folgendes daher mglw. nicht wirklich hilfreich: Wie ist der Device-Status vor/nach der versuchten Aktion (Register 0x02)? Versucht, vor der Aktion "Ready Mode" einzustellen (0x01 in Reg. 0x07)? Irgendwelche Interrupts aktiviert (Reg. 0x05 und 0x06)? Im Zweifel: ITs deaktivieren und auch beide Statusbytes abfragen(löschen). Versucht, nur RX-FIFO zu löschen (0x02 gefolgt von 0x00 in Reg. 0x08)?
Hallo Martin, danke erst mal für die Antwort. Die von Dir vorgeschlagenen Versuche habe ich alle schon durch. Auch der Support von Hope und Silicon Labs weiß nur, daß man die Registerbits im 08h erst setzen und dann löschen soll. Insbesondere hat auch das Löschen direkt vor dem Auslesen und auch nach dem Auslesen keinerlei Auswirkungen. Ich habe übrigens zwei Module hier am laufen, die sich diesbezüglich beide gleich verhalten unabhängig davon, daß das eine Modul im Interruptbetrieb läuft und das andere im Pollingmode. Alles sehr mysteriös :-/ Gruß, Dirk
Hm, also ich hänge hier mal eine Antwort vom SiLabs Support ein: ------------------------- Hi Dirk, Finally I found the issue. Actually this is not a bug, this is how the chip works. Here is an example for the FIFO clearing: - receive 3 bytes - read out 3 bytes from the RX FIFO (wich is "ACK") - clear the RX FIFO - read out 3 bytes from the RX FIFO (all the 3 bytes will be 'A', so you get "AAA") So it looks when you clear the FIFO and if you have 3 bytes in the FIFO, then after clearing the FIFO will be the first byte of the FIFO. Regards, ------------------------ Nach dem Motto, it's not a bug, it's a feature ;-). Daraus ergibt sich jetzt natürlich das Problem, daß man das RFM22B Modul nicht so ohne weiteres ohne Interrupt verwenden kann, da sich im FIFO nach dem Clear ggf. noch das letzte übertragene Datenbyte befindet und man nun nicht unbedingt erkennen kann, ob das aus einer neuen, korrekten Übertragung stammt oder ein Überbleibsel ist. Da lauert also beim Polling eine böse Falle, wenn man grad nur ein Byte übertragen will. Die Philosphie hinter diesem "Feature" ist mir nach wie vor schleierhaft ;-). Im Interrupt Modus sagt einem natürlich der Interrupt immer, wenn aktuelle Daten vorliegen. Dann sind die alten Daten ja auch auf jeden Fall überschrieben.
Okay, und jetzt die Lösung/Erklärung des Problems : ------------------------------- Hello, So the FIFO reset is only reset the FIFO pointer and not the FIFO content. This is the reason why we read out always the same value from the RX FIFO after resetting, because the pointer is on the first byte. Regards, Sandor -------------------------------- Es wird also beim "clear FIFO" nicht der Inhalt des FIFOs gelöscht sondern nur die Pointeradresse des FIFO auf null zurück gesetzt. Da muß man erst mal drauf kommen ;-). Gruß, Dirk
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.