www.mikrocontroller.net

Forum: HF, Funk und Felder RFM22B keine Datenrate über 160kbps?


Autor: dijogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: dijogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fasti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: dijogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: dijogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: dijogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: dijogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: dijogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: dijogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.