Kleiner Tip zum RFM12

Olaf Kaluza schrieb:

Also einen kurzen blick in meinen Source: ... rf12_TX(0x0); //dummy byte ... rf12_loop_until_FFIT_RGIT(); //enable receiver rf12_cmd(RF12_POWER_SETTING, RF12_ER | RF12_DISABLE_CLOCK_OUTPUT);

Ich sende also nur 1Byte dummy daten und polle dann das Statusbit auf Receiver-FIFO ready.

Für welche CPU schreibst du?

Gruß Andy

PS: Jetzt gibt es ja doch wieder diverse Threads zu dem Modul, können wir nicht mal irgendwo die Daten sammeln?

Letzteres spare ich mir da ich es ja indirekt mache wenn ich zwei Byte sende oder sagen wir mal lieber in den Puffer schreibe. Gesendet werden die naemlich nicht mehr.

68338 (aka Dragonball) und M306020 (M16C/62A)

Ich werde aber auf jedenfall noch auf M16C/28 und vielleicht auch R8Cxx implementieren.

Mach doch. :-) Mir reicht Usenet.

Olaf

Zitat aus dem Heinz Ruehmann Film "Der Luegner": Das ist zu einfach!

--
Gruesse, Joerg

http://www.analogconsultants.com/

heureka! das gestern beschriebene problem, daß ich die daten doppelt senden muß, um sie 1.2 mal zu empfangen, hat sich grad gelöst.

ich glaub nämlich, das datasheet belügt uns: ich interpretiere jedenfalls die graphik "Typical TX register usage" auf s. 24 in rf12.pdf so, daß ein dummy-byte ausreichend ist. scheint aber nicht so zu sein, wenn ich nämlich in rf12_send 2 dummy-bytes sende, schaut die übertragung (im kurzen test) zuverlässig aus ohne doppeltes senden.

ich mach hier jetzt also

rf12_cmd(RF12_POWER_SETTING, RF12_ET | RF12_DC); // turn on xmit rf12_send((uint8_t *)&data, sizeof(data)); rf12_cmd(RF12_POWER_SETTING, RF12_DC); // turn off

ciao,

cm.

--
Hat irgendwer schlechte Schwingungen in seiner globalen
Eierkuchen-Aura bekommen weil man ihm gesagt hat er soll bitte nicht
andauernd mit Vollquotes in 10 Gruppen gleichzeitig crossposten?
 Albert Koellner in at.usenet

christian mock schrieb:

Hint: rf12_TX (zumindest in der Version von Andreas) wartet nicht, bis das TX-Register wieder aufnahmebereit ist. Dann benötigt man natürlich zwei Dummy-Bytes. Ein Dummy-Byte sollte reichen, wenn man ganz zum Schluss von rf12_send noch einmal rf12_loop_until_FFIT_RGIT aufruft. Denn erst wenn ein Dummy-Byte geschrieben wurde und danach RGIT wieder gesetzt ist, wurde das letzte Datenbyte gesendet.

Alternativ müsste man nach dem letzten Datenbyte auch auf ein "TX register underrun" warten können.

Eigentlich alles ganz logisch.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Also jetzt wo ich das Diagramm sehe , muss ich dir zustimmen.

Wobei aber auch von der Baudrate und der Prozessorgeschwindigkeit abhaengt. Wenn dir der RF12 sagt das er jetzt ein neues Byte gebrauchen kann, dann hat er ja kurz vorher 8Bit freigemacht und sendet das obere Bit der anderen 8Bit.

Wenn man jetzt eine sehr hohe Baudrate haette, und sich ausserdem beim holen des naechstens Bytes etwas Zeit laesst, oder man selber die SPI Anbindung relativ langsam betreibt dann koennte er ja schon mehr Bits gesendet haben und dann ist bis zum abschalten bereits wieder ein Byte ganz draussen.

Bei mir war es aber definitiv so das immer die letzten beiden Bytes zerstoert waren.

Wenn ich das richtig sehe dann sollte es nach dem einschalten noch eine gewisse Wartezeit geben damit Clock, Pll hochfahren. Bei mir klappte es zwar auch ohne dem, aber ich sende sichheiteshalber mal 6x

0xAA vor der Uebertragung.

Also so:

rf12_txmode(); /* RF12 in Sendebetrieb */

rf12_txbyte(0xaa); /* Das braucht der andere */ rf12_txbyte(0xaa); /* Empfaenger um sich zu */ rf12_txbyte(0xaa); /* syncronisieren */ rf12_txbyte(0xaa); rf12_txbyte(0xaa); rf12_txbyte(0xaa);

rf12_txbyte(0x2d); /* Kennung fuer Empfaenger */ rf12_txbyte(0xd4); /* Damit er seine Fifo einschaltet */

for (i=0;i

Warum sollte eine Senderoutine darauf warten das der Sender das Byte gesendet hat? Damit verschwendet man doch Rechnenzeit die man wohlmoeglich woanders, z.B zum bearbeiten/holen des naechstens Bytes bitter noetig hat. Ich warte immer vor dem reinschreiben bis wieder Platz fuer mein frisches Byte ist.

Olaf

laut diagramm (das allerdings schon einmal der lüge überführt wurde) sendet er die bytes aus seinen TX-registern aber erst, wenn der transmitter bereit ist.

ich hatte im code zuerst nach dem einschalten des transmitters ein

do { rf12_read_status(); } while(!status_H.bits.ATS_RSSI);

drin, und hab das dann auskommentiert -- das wirkt sich auf die durchlaufzeit eines paketes überhaupt nicht aus, während dieses warten alleine 1.5ms dauert. mit anderen worten: wenn man das wegläßt, wartet man halt später länger darauf, daß das TX register wieder frei wird.

ich hab diese variante (transmitter aktivieren, bytes rüberschaufeln,

2 dummy-bytes am ende) jetzt über nacht laufen gehabt, 6700 pakete empfangen, 45 verloren.

ciao,

cm.

--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
Ich beraube mich doch nicht des Vergnügens zu beobachten, wie sich diese
zarte Knospe der Dummheit weiter entfaltet.
 Markus Pirchner ueber xxx in abm-mi

Wie gross sind deine Pakete?

Ich versende hier 24Byte und erwarte 24Byte. Also insgesamt 48Byte, gesichert mit CRC. Ohne es genau nachgehalten zu haben liegt da die Fehlerrate so bei beschaetzten 10%.

Mit anderen Worten es lohnt sich schon ueber etwas aufwendigere Fehlercodes/wiederherstellung nachzudenken. Man hat ja vielleicht nur ein falsches Bit, aber die CRC-Pruefung sortiert dann natuerlich das ganze Paket aus.

Olaf

10 bytes ohne die dummies am ende, aber mit präambel und sync bytes.

ich denk, das kommt auf den anwendungszweck an -- bei mir ist das derzeit nur die datenübertragung von sensoren, die sollen einmal die minute einen wert senden, wenn der einmal für eine oder zwei minuten nicht kommt, ist das (in meiner anwendung) nicht tragisch; dafür erspar ich mir eine menge overhead und damit läuft der sensor wiederum länger auf einem Paar AA-zellen.

ciao,

cm.

--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
Other languages don't walk up to web designers in the street and call
out "hey, big boy, wanna inline some code with me?"
  -- Peter da Silva about PHP

christian mock schrieb:

Hi cm, du solltest nach dem einschalten noch etwa 500µs warten, siehe in meinem Header rf12.h:

Aus dem Datenblatt: Umschaltung RX/TX Transmitter - Receiver turnover time: (Synthesizer and crystal scillator on during TX/RX change with 10 MHz step) 425 ?s Transmitter turnover time: (Synthesizer and crystal oscillator on during RX/TX change with 10 MHz step) 300 µs

Daher lasse ich auch den Synthesizer und Oszillator immer an.

Wegen senden wirf z.B. ein blick in rf12_ping(..):

rf12_cmd(RF12_POWER_SETTING, RF12_ET | RF12_DISABLE_CLOCK_OUTPUT); //enable transmitter _delay_ms(0.5); uint8_t buf[3]; buf[0]=target; buf[1]=stack_address; buf[2]=0x00; //PING rf12_send(buf,3); rf12_loop_until_FFIT_RGIT();

Also wie Olaf schrieb, die reine sendefunktion wartet nicht, bis das letzte Byte gesendet wurde. Wenn du den Transmitter abschalten willst, musst du vorher FFIT prüfen. (Oder halt 2dummybytes senden, am anfang von rf12_TX wird ja gewartet)

Aber mich freut, dass es anscheinend nach Stunden bei dir lief, ich habe etwa 4age gebraucht, bis ich erstmals kommunikation hatte. Allerdings hab ich mich anfangs nach dem HopeRF PDF gerichtet.

Gruß Andy

christian mock schrieb:

nochmal ausdrücklich: Wenn du schnell zwischen RX und TX umschalten willst, dann lass Synthesizer und Oszillator laufen.

Siehe auch die ping/pong in rf12_stack.c funktion

Gruß Andy

5ms, weil ich hier nicht zwischen empfangen und senden umschalte, sondern zwischen aus und senden -- aber, siehe mein anderes posting von heute, offenbar hat das datasheet hier recht, die bytes im TX-buffer werden erst gesendet, wenn der sender sendebereit ist.

in meiner anwendung geht das nicht, die soll möglichst lang auf batterien laufen. die derzeitige version (mit einem "dummen" 868MHz-modul) läuft schon 9 monate auf dem ersten Paar AA-zellen, was meine schätzungen deutlich übertroffen hat.

da müßt ich zwischen den ganzen anderen dingen erstmal die zeit finden, um auf die neueste version deines codes umzustellen :-)

eben. ich muß mal messen, ob sich beim warten ein signifikanter zeitunterschied ergibt...

gelaufen ist es eigentlich nach ca. einer stunde, weil ich vergessen hatte, den transmitter abzudrehen und daher das letzte byte nicht verlorenging. die bastelei war dann, die sache mit den 2 dummy-bytes rauszukriegen...

ciao,

cm.

--
Es ist jedenfalls VIEL besser als "Sie haben keinen Virus versandt und
hätten auch keinen erhalten, aber irgendwo in den Weiten des Internet
wurde eine mail gekillt, die zufällig ihre Adresse im From hatte."
-- Matthias Kahlert in aip

in der tat gibt es einen: mit 2 dummy-bytes 12ms, mit 1 dummy + warten auf FFIT 11ms.

ciao,

cm.

--
Es ist jedenfalls VIEL besser als "Sie haben keinen Virus versandt und
hätten auch keinen erhalten, aber irgendwo in den Weiten des Internet
wurde eine mail gekillt, die zufällig ihre Adresse im From hatte."
-- Matthias Kahlert in aip

Ist mikrocontroller.net wohl immer noch der beste Ort für so langfristige spezielle Threads mit Attachments in diesem Bereich. Kannst auch z.B. einen Code-Sammel-Thread RFM12 o.ä. dort aufmachen und das Zeug dort erstmal uploaden (lassen) und verwalten. Wenns dicke kommt sf.net ..