Ich werd' noch wahnsinnig: RFM12

30/03/2008 - 21:50 von Heiko Nocon | Report spam
Hallo,

Nachdem ich jetzt schon das dritte WE damit vertrödelt habe, mich mit
diesem Mistmodul auseinanderzusetzen und die Sache immer noch nicht
làuft, hier dieser Hilfeschrei.

Also, die AVR-Software zur Ansteuerung des Teils habe ich selber
geschrieben (interruptgesteuert und mit Hardware-SPI), sie entspricht
aber funktional wohl weitestgehend den bekannten
Bitbang/Polling-Lösungen aus den einschlàgigen Foren. Was man daran
sehen kann, daß diese exakt dieselben Ergebnisse liefern...

Das Problem ist, daß dieses vermaledeite Teil nur Mülldaten aus dem FIFO
rausrückt. (Wohlgemerkt: _nicht_ "nur Mülldaten empfàngt")

Die Sache stellt sich so dar:

Der Sender sendet im Sekundenrythmus folgenden String:

.DB $aa,$aa,$aa,$aa,$2d,$d4,"Hallo World! ",$aa,$aa

Also insgesamt 21 Bytes, wovon die ersten 6 eine üppige Pràambel und das
Syncpattern darstellen.

Frequenz und Bitrate sind für Sender und empfànger natürlich gleich
eingestellt, sonstige Parameter sinnvoll aufeinander angepaßt. Scheint
auch alles ganz nett, denn der Empfànger verhàlt sich wie erwartet. Er
wartet ordentlich darauf, daß das Syncpattern erscheint und beginnt bei
Erscheinen Daten zu liefern. Testweises Entfernen des Syncpatterns aus
dem Sendestring führte erwartungsgemàß dazu, daß der Empfang nicht
startete, ein alternatives Sync-Pattern verhielt sich genau wie der
Standard.

Das Teil empfàngt also definitiv die gesendeten Daten und reagiert
intern korrekt darauf, wie man weiter unten in den Logs noch
detaillierter sehen kann. Zu den Logs noch als Erklàrung: Der
zweistellige Hexstring stellt das vom FIFO rausgerückte, angeblich
empfangene Byte dar, der einstellige Hexstring in den eckigen Klammern
einen Auszug aus den Statusbits des RFM12, nàmlich die Bits für
RSSI(MSB),DQD,CRL und ATGL(LSB).

Nachdem also der Empfànger mit $CC83 "scharf" gemacht wurde, passiert
als erstes folgendes:

00[E]80[E]40[E]40[E]70[E]40[E]30[E]70[E]80[E]40[E]00[E]00[E]00[E]

Was die Statusbits betrifft, sieht das sehr gut aus, denn alles, was
einen kompletten VDI ausmacht, ist gesetzt. Weiter geht es mit einer
Menge Daten á la:

00[0]00[0]00[0]04[0]00[0]00[0]80[0]00[0]00[0]00[2]00[2]00[2]00[0]
...

Sieht auch gut aus. Ab und an meint die CR-Unit zwar mal, gelockt zu
sein, obwohl nur Rauschen empfangen wird, aber das stört keinen.
Interessanter ist schon, warum von den 15 ab Sync gesendeten Byte nur 13
zu sehen waren. Das ist dadurch erklàrlich, daß ich den Sender ziemlich
hart abwürge, wenn das letzte Byte der Zeichenkette gesendet ist. Die
beiden $aa nach dem eigentlichen Nutzstring dienen also nur als Dummy.
Das ist so geplant und funktioniert offensichtlich auch wie geplant.

Nach rund einer Sekunde kommt dann das nàchste Sendeevent.
Erwartungsgemàß wird die empfangene Zeichenkette jetzt lànger, da
Pràambel und Sync mit empfangen werden. Das ganze sieht dann so aus
(gleich mal vier Inkarnationen, zwischen denen liegen im Original
natürlich den Sendepausen entsprechende Phasen von Rauschen):

00[E]20[E]40[E]00[E]00[E]70[E]00[E]10[E]10[E]10[E]10[E]80[E]00[E]D0[E]B0[E]10[E]10[E]08[E]00[E]00[E]
...
00[E]40[E]20[E]40[E]00[E]60[E]20[E]00[E]00[E]40[E]A0[E]70[E]00[E]30[E]B8[E]90[E]40[E]00[E]00[E]00[E]
...
00[E]00[E]20[E]40[E]00[E]60[E]00[E]00[E]00[E]00[E]00[E]C0[E]00[E]60[E]C0[E]00[E]80[E]00[E]00[E]00[E]
...
00[E]00[E]00[E]00[E]20[E]50[E]00[E]00[E]00[E]40[E]40[E]70[E]00[E]60[E]70[E]00[E]40[E]00[E]00[E]00[E]
usw.

Also, soweit alles sehr schön. Der springende Punkt ist eben nur, daß
die angeblich empfangenen Daten rein garnix mit den gesendeten zu
schaffen haben. Meiner Meinung nach ist nichtmal irgendeine Korrelation
zu erkennen. Tatsàchlich empfàngt das Teil aber nachweislich zumindest
das Sync-Pattern korrekt. Man sollte also erwarten können, daß in den
Wiederholungen zumindest diese Sync-Pattern herauskommen müßten, ggf.
mit verschobenen Bits. Tuen sie aber offensichtlich nicht.

Irgendwelche Ideen, Tips, Hinweise?

Die in den einschlàgigen Foren geposteten Hinweise zum Rumspielen mit
diversen Parametern des RFM12 (AFC, PLL, RXCONTROL usw.) sind nicht
hilfreich. Das oben gepostetete stellt nàmlich das Beste dar, was mit
sàmtlichen verfügbaren Bitkombinationen erreichbar war. Letztes WE hatte
ich nàmlich schon aus Verzweiflung ein Programm gebastelt, was die alle
automatisiert durchprobiert hat.

Das Problem ist meiner Meinung nach irgendein Firmware-Bug beim Auslesen
des FIFO. Denn: mit dem automatisiert gefundenen Optimum der
Einstellungen ist es sehr wohl problemlos möglich, eine ordentliche
Übertragung der Daten zu realisieren. Nàmlich ohne den RX-FIFO...

Das nützt mir aber nix. Ich brauche die Rechenzeit im AVR für andere
Sachen.
 

Lesen sie die antworten

#1 Olaf Kaluza
30/03/2008 - 21:25 | Warnen spam
Heiko Nocon wrote:


Das Problem ist, daß dieses vermaledeite Teil nur Mülldaten aus dem FIFO
rausrückt. (Wohlgemerkt: _nicht_ "nur Mülldaten empfàngt")



Also bei mir funktioniert es ganz zuverlaessig, und da dein Empfaenger
ja auch die beiden SyncBytes empfaengt muss es bei dir auch schon
klappen. Daher kann es wohl nur am auslesen der Fifo liegen. Bei mir
sieht das so aus:

/*********************************************************************/
/* Liefert TRUE wenn Fifo leer ist! */
/*********************************************************************/
int rf12_RGIT(void)
{

RF12_DATA_low(); /* Wir geben immer nur 0 aus. Das ist der Statusreadbefehl */
RF12_CS1_low();
if (RF12_DATA_in() == TRUE )
{
/* Ja wir koennen etwas Zuwendung gebrauchen */
RF12_CS1_high();
RF12_DATA_high();
return(TRUE);
}
else
{
/* Nein, wir sind voll bis zum abwinken */
RF12_CS1_high();
RF12_DATA_high();
return(FALSE);

}
}

Dein Problem kommt mir irgendwie bekannt vor. Ich meine ich hatte
dieselben oder jedenfalls aehnliche Probleme. Lag bei mir an irgend
einem Pegel beim lesen. Kann ich aber leider nicht mehr genau
sagen. Aber obiger Code funktioniert. Ich hab ihn identisch in einem
Palmpiloten und in einem M16C laufen.

/*********************************************************************/
/* Ein Byte empfangen */
/*********************************************************************/
unsigned char rf12_rxbyte(void)
{ unsigned char data;
volatile unsigned short i;

/* Warten bis wieder Platz im Puffer ist */
i=RXWAIT;
do { i--; } while ( (rf12_RGIT() =úLSE) && (i!=0) );

/* Wenn es zu lange dauert dann stimmt hier etwas nicht! */
if (i==0) { RF12Err.bit.RxErr = 1; RF12Err.bit.Timeout = 1; return(0x00); }

data = spi_word(0xB000) ;


return (data);
}


Olaf

Ähnliche fragen