RFM12B Daten auswerten

[Funk-Neuling (Gast)]

Hallo alle miteinander, ich beschäftige mich seit ungefähr 2 Monaten mit 
den RFM12B Funkmodul auf 868Mhz Basis.

Dabei habe ich den Code vom Benedikt benutzt.
Meiner Meinung nach Empfange ich jetzt. Ich Bekomme ein Signal am ARSSI 
Ausgang was den Datenblatt entspricht und meine Buskommunikation ist 
ebenfalls eindeutig.

Ich habe nun das Problem, dass ich Daten empfange aber diese auf mein 
LCD Display nicht richtig angezeigt bekomme. Ich übertrage einen String 
mit folgenden Inhalt: "Dies ist ein 868 Mhz Test!!!". Bei mir werden auf 
mein Display aber nur Zahlen angezeigt, wie zum Beispiel 100 oder 96. 
Woran kann das liegen?

Meine LCD Ausgabe:

[/c}
void lcd_prototyp(){

  char test1;

  test1=test[1];

  lcd_init();

  lcd_data( 'T' );
  lcd_data( 'e' );
  lcd_data( 's' );
  lcd_data( 't' );
  lcd_data( ':' );

  lcd_setcursor( 5, 1 );

  {
    char Buffer[32];
    itoa(test1, Buffer, 10 );

    lcd_string( Buffer );
  }
[/c}

Mfg

[ich (Gast)]

Hallo Funk-Neuling,
Könnte es sein das das du die Bytes und den String anzeigst weil diese 
Zahlen alle für Buchstaben stehen?
Gucke mal in einer Ascii Tabelle ob die Zahlen mit den passenden 
Buchstaben übereinstimmen. Hätte noch eine Frage:Ich habe diese Module 
selber hier und möchte wissen ob du den Code von Benedikt verändert hast 
oder nicht

LG

[Funk-Neuling (Gast)]

ich hab am code vom Benedikt soweit nichts verändert, nur die 
Einstellungen an die Frequenz für 868 Mhz angepasst. Anscheinend kann 
ich mein Empfangs register nicht auslesen. Ich habe mein array test[32] 
auf null gesetzt im globalen Bereich und auf mein Display steht auch die 
ganze zeit eine Null. Hat jemand eine Idee?

[Felix P. (fixxl)]

Wie hast du die Frequenzeinstellung angepasst? Also wie sieht die rf12.h 
aus? Benedikts Code ist nur für 433 MHz gedacht und die 
Frequenzeinstellung unterscheidet im Original nur zwischen zwei 
Einstellungen im Bereich 433 MHz.

Lad doch einfach mal dein komplettes Projekt mit allen Libraries - also 
auch mit allen RFM- und LCD-Funktionen - hoch, dann kann dir sicher 
geholfen werden.

[Funk-Neuling (Gast)]

In der rf12.h habe ich mir ein Makro angelegt womit die 868Mhz berechnet 
werden.

#define FREQ868

#ifdef FREQ433
#define RF12FREQ(freq)  ((freq-430.0)/0.0025)
#elif defined FREQ868
#define RF12FREQ(freq)  ((freq-860.0)/0.005)
#endif

In meiner Main.c habe ich dann wie folgt die Einstellungen vorgenommen

int main()
{
  rf12_init();                    // ein paar Register setzen (z.B. CLK auf 10MHz)
  delay_ms(500);                  // Initialisierung muss manchmal mehrmals gemacht werden,
  rf12_init();                // da Modul lange braucht
  delay_ms(1000);
  rf12_init();  
  //rf12_setfreq(RF12FREQ(433.92));  // Sende/Empfangsfrequenz auf 433,92MHz einstellen
  rf12_setfreq(RF12FREQ(868.92));  
  rf12_setbandwidth(4, 1, 4);      // 200kHz Bandbreite, -6dB Verstärkung, DRSSI threshold: -79dBm 
  rf12_setbaud(19200);            // 19200 baud
  rf12_setpower(0, 6);            // 1mW Ausgangangsleistung, 120kHz Frequenzshift
  lcd_init();
  
  while(1)
  {  
    receive();
    delay_ms(100);
  }
  return 0;
}

Mit der "rf12_setfreq(RF12FREQ(868.92));" übergebe ich jetzt den Wert 
für den jeweiligen Frequenzbereich. In diesen Fall 868,92 Mhz.

Mit meiner receive Funktion übergebe ich jetzt noch zusätzlich mein 
Array an meine LCD Ausgabe. Das klappt auch soweit, meiner Meinung nach.

void receive(void)
{  
  unsigned char test[32];
  rf12_rxdata(test,32);
  lcd_prototyp(test);
  
  }

auf mein Display steht jetz auch dauerhaft die Zahl 136.

MFG

[Felix P. (fixxl)]

Zunächst mal zu den Warnungen, die es bei mir gibt, wenn man das Projekt 
kompiliert:

In der Deklaration der for-Schleife zum Umwandeln fehlt das i = 0, bei 
dir heißt es

for (uint8_t; i < 32; i++) {

Es soll aber wahrscheinlich

for (uint8_t i=0; i < 32; i++) {

 heißen.

Außerdem ist die Library der itoa-Funktion nicht eingebunden, so dass 
die Funktion nicht erkannt wird, füge doch mal

#include <stdlib.h>

 ganz oben mit ein.

Dann würde ich noch

void lcd_prototyp(char *data)

 auf

void lcd_prototyp(unsigned char *data)

 ändern, dann sollte man auch die letzte Warnung los sein.

Was passiert, wenn du das alles anpasst?

[Funk-Neuling (Gast)]

Erstmal danke für die Fehlerkorrektur. Das habe ich anscheinend im 
Arbeitswahn nicht mehr erkannt.

Jetzt stelle ich aber ein anderes Phänomen fest.Sobald ich die Funktion 
lcd_prototyp  in der receive Funktion aufrufe bricht meine Bus 
Kommunikation zusammen. In der LCD Anzeige stehen jetzt nur nullen.

Das heißt der Sender sendet noch ohne Probleme aber der Empfänger 
reagiert nicht mehr.



MFG

[Funk-Neuling (Gast)]

Ich muss noch hinzufügen das mein LC-Display keine SPI Schnittstelle zur 
Verfügung hat. Ich verwende das IC KS0070B.

[Felix P. (fixxl)]

Habe gerade noch weiter im Code geschaut und etwas getestet. Ein Problem 
ist auf jeden Fall die lcd_prototyp-Funktion:

Warum wird das LCD bei jedem Schleifendurchlauf neu initialisiert? Das 
ist völlig unnötig und unsinnig. Es einmal in der main-Funktion vor 
Beginn der Endlosschleife zu initialisieren genügt völlig, danach läuft 
es bis zur nächsten Trennung von der Betriebsspannung.

Bei jeder Initialisierung löschst du zudem am Ende den Bildschirm und 
setzt den Cursor nach ganz oben links, kannst dir also denken, was du da 
am Ende noch von dem siehst, was du tatsächlich empfangen hast - nämlich 
relativ wenig...

Außerdem würde ich zu Testzwecken das Umwandeln der empfangenen Zeichen 
in Zahlen erst einmal weglassen, also folgende simple Funktion 
verwenden:

void lcd_prototyp(unsigned char *data) {
  lcd_data('T');
  lcd_data('e');
  lcd_data('s');
  lcd_data('t');
  lcd_data(':');

  lcd_string(data);
}

Wenn hier dann nach dem Doppelpunkt "Das ist" usw. erscheint, dann 
funktioniert das Programm grundsätzlich und man kann weiter machen.

Nachtrag: lcd_string noch als Parameter einen unsigned char verpassen, 
dann gibt es auch keine signedness-Warnung.

[Funk-Neuling (Gast)]

Ich habe diese Änderungen jetzt auch vorgenommen aber  auf mein Display 
Sehe ich jetzt nach "Test: ||F@!(8 |||N'",also undefinierbare Zeichen.


Ist es vielleicht möglich das ich nicht das richtige Empfange?

Ich könnte jetzt viele Vermutungen aufstellen woran es liegt, aber dafür 
fehlt mir leider die Erfahrung in diesen Segment.

Am C-Code fürs Funkmodul wurde von meiner Seite aus nicht viel verändert 
außer die Einstellungen für die Frequenz und die rf12 ready wodurch ich 
jeweils eine Abfrage für den Sender und Empfänger habe.

MFG

[Funk-Neuling (Gast)]

Ich habe am Oszilloskop gerade nochmal Miso beim Sender Und Empfänger 
verglichen.
Meiner Meinung nach ist dort eine große Diskrepanz zwischen den beiden 
Signalen zu erkennen. Müssten diese nicht annähernd gleich sein?.

[Felix P. (fixxl)]

Das Umschreiben der rf12_ready könnte ein Problem sein, denn durch die 
Wartezeit von 10 Mikrosekunden störst du den Sendeablauf und das Timing. 
Bei einer Bitrate von 19200 dauert jedes Bit etwa 52 µs, so dass eine 
Wartezeit von 10 µs einen Timingfehler von knapp 20% verursachen kann. 
Wenn du unbedingt einen Timeout einbauen willst, dann setze timeout als 
höheren Wert in Abhängigkeit von F_CPU (z.B. F_CPU/128 für eine maximale 
Wartezeit von 7,8ms) und lass den delay weg.

Ändere außerdem mal bitte in der rf12.c bei der rxdata-Funktion die 
Zeile

#ifdef HAMMING_CODE

zu

#if HAMMING_CODE

Aus dem Oszi-Plot kann ich leider wenig herauslesen.

[Funk-Neuling (Gast)]

Hey, ich habe deinen rat befolgt und zusätzlich noch die rf12_ready 
funktion abgeändert so wie es aus den code vom benedikt war.

Zurzeit spiele ich etwas mit der send funktion rum und ich ändere den 
inhalt des strings "test[]". Jetztwerden auf mein Display auch 
verschiedene Zeichen angezeigt, die aber leider nicht defenierbar sind.

MFG

[Christian K. (the_kirsch)]

Zeig mal deinen aktuellen Code

[Funk-Neuling (Gast)]

Ich habe meine Code noch etwas aufgeräumt. Das heißt den Teil wo der 
Haming Code integriert war habe ich erstmal entfernt.

Ich habe auch nochmal die PDF von meinen LC-Display herausgesucht:
https://cdn-reichelt.de/documents/datenblatt/A500/LCD162C%23DIS.pdf

MFG

[Felix P. (fixxl)]

Habe leider gerade keine entsprechende Hardware da, um es zu testen, 
aber es könnte sein, dass es ein Problem bei der Darstellung des Strings 
auf dem LCD gibt:

lcd_string wartet auf das Zeichen '\0', welches aber nie kommt, da alle 
32 Speicherstellen von test belegt sind und am letzten Platz ein 
Leerzeichen steht. Wenn aber keine 0 kommt, dann geht die Funktion aber 
weiter durch den Speicher, bis irgendwann mal zufällig eine 0 im 
Speicher steht und schreibt bis dahin alles munter auf das LCD.

Abhilfe:

void receive(void) {
  unsigned char test[33]; // Array um eine Stelle verlängern

  for (uint8_t i = 0; i < 33; i++) { // Damit wird test[32] zu 0
    test[i] = 0;
  }

  rf12_rxdata(test, 32); // test[0] bis test[31] werden beschrieben
  delay_ms(100);
  lcd_prototyp(test); // Spätestens beim 33. Zeichen (test[32]) kommt 0
}

[Funk-Neuling (Gast)]

Hallo,

das habe ich jetzt ausgiebig getestet aber ich komme zu keinen ergebnis 
was mich zufrieden stellt. Ich kann auf mein display leider immer noch 
nicht den übrtagenen string lesen.

Ich habe jetzt versucht Zahlen zu übertragen und mit der itoa 
anzuzeigen. Dies klappt auch nicht, aber wenn ich Jetzt die Funktion 
meiner pt100 Auswertung zum Projekt hinzufüge undauf mein display 
ausgebe funktioniert es einwandfrei.

Kann ich mir daraus jetzt herleiten das die Funkübertragung nicht 
funktioniert?

MFG

[Funk-Neuling (Gast)]

Hat niemand mehr eine Ahnung?

MFG

[steffen (Gast)]

Hallo Funk-Neuling,

ja fertigen Code zu nutzen ist das eine. Aber diesen zu verstehen das 
andere. Ich nutze selber mehrere RFM Funkmodule, mit denen muss man erst 
mal "warm" werden. Ich habe angefangen das ein Modul immer den gleichen 
String sendet wenn man eine Taste drückt. Dann habe ich die 
Übertragungsraten weit nach unten gedreht (1200) Dann den Empfänger 
gebaut um zu sehen was gesendet wird. In dem Fall nur ein RFM01 mit 
serieller Ausgabe. Zeig mal das gesamt Bild, also den Aufbau, den RFM 
Code, so weit ich mich erinnere, war die Initialisierung bei 800Mhz 
etwas anders als bei 400Mhz. Wenn das erst mal läuft, dann kannst du 
anfangen mit Display und weiteren Ausgaben zu arbeiten.

Gruß Steffen