mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wer verwendet RFM69?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe nur 7 Einträge hier gefunden, deshalb würde mich interessieren:
Wer verwendet eine Variante des Rfm69, das lt Hope der Nachfolger der 
Rfm12/12b/22/23 ist?

Vg,
Conny

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Ja, die RFM69 scheinen noch nicht allzu weit verbreitet zu sein. Ich bin 
aktuell dabei, vom RFM12 auf das RFM69CW umzusteigen und muss sagen, 
dass das schon um einiges komfortabler ist (Hardware-CRC, Autom. 
Paketkonfiguration, größere FIFO, ...). Einzig den guten alten 
Wake-Up-Timer vermisse ich.

von Flip (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zu teuer

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Felix Pflaum schrieb:
> Ja, die RFM69 scheinen noch nicht allzu weit verbreitet zu sein. Ich bin
> aktuell dabei, vom RFM12 auf das RFM69CW umzusteigen und muss sagen,
> dass das schon um einiges komfortabler ist (Hardware-CRC, Autom.
> Paketkonfiguration, größere FIFO, ...). Einzig den guten alten
> Wake-Up-Timer vermisse ich.

Ok, lass wissen, wie es läuft, das steht mir ja auch bald bevor.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du eine gut funktionierende Bibliothek für RFM12 hast, ist die 
Umstellung zumindest strukturell relativ einfach. Mein Ziel war, nach 
außen dieselben Schnittstellen zur Verfügung zu stellen, weil ich in 
meinem System alte Bausteine mit RFM12 und neue mit RFM69CW gemeinsam 
verwenden will, und das Hauptprogramm mit den gleichen Funktionen auf 
beide Typen zugreifen soll.

Unter der Haube sind natürlich ein paar Umstellungen nötig, denn die 
SPI-Ansteuerung funktioniert anders und es gibt mehr Register und 
Einstellmöglichkeiten. Wenn man sich aber am RFM12 und den dort 
getroffenen Einstellungen wie Bitrate, Carrierfrequenz, 
Empfängerbandbreite und Frequenzhub orientiert und Kompatibilität 
untereinander (FIFO-Schlüssel, Paketmodus, ...) sicherstellen will, hat 
man die nötigen Werte für die einzelnen Register schnell raus.

Angenehm ist, dass man die Daten nicht mehr Byte für Byte schicken und 
empfangen muss, sondern das alles über die FIFO geregelt wird.

Zum Arbeiten bietet sich das Datenblatt zum Chip SX1231 vom 
Chiphersteller Semtech an, Hope-RF hat das größtenteils 1:1 übernommen, 
aber irgendwie die Bits zur Einstellung der Sendeleistung vergessen. Von 
Semtech gibt es auch eine Application Note, wie man die CRC16 des 
RFM69CW in Software nachbilden kann: Dazu muss das Polynom 
x^16+x^12+x^5+1 mit Seed 0x1D0F verwendet werden und nach dem 
Durchschieben aller Bytes das Ergebnis invertiert werden.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, das ist hilfreich.
Ja, habe eine Bib für Rfm12 mit etwas ähnlichem wie dem Snap Protokoll 
und Crc/Paketwiederholung ergänzt.
Würde tatsächlich am liebsten die Anpassung "unter der Haube" vornehmen.
Hast es schon in Betrieb gehabt, gibt es Unterschiede in der Reichweite?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
In Betrieb hatte ich es bereits, um meinen Code zu verifizieren, was 
auch wunderbar geklappt hat. Mein Reichweitentest hat sich bislang aber 
auf etwa fünf Meter Luftlinie innerhalb des Hauses beschränkt, draußen 
war ich mit dem Modulen noch nicht.

Mit den RFM12 habe ich bei 9600bps etwa 200m im freien Feld mit 
Dipolantennen überbrücken können und hausintern von jedem Punkt jeden 
anderen erreicht - das war für mich immer ausreichend. Das RFM69CW 
sollte theoretisch mit 6dB mehr Sendeleistung und niedrigeren 
Rauschteppich um einiges weiter kommen können, muss nur noch überlegen, 
wann ich das brauche.

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

bin auch gerade dabei auf RFM69C umzusteigen. Die Ansteuerung 
funktioniert ganz anders, aber ich finde die Umstellung lohnt sich, und 
die Teile können endlich OOK. Die FS20 Funksteckdosen kann ich bereits 
ansteuern. Auch das konfigurierbare Syncword und die Packetengine nehmen 
einem viel Arbeit ab.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab sie bei mir herumliegen, aber noch keine Zeit gehabt mich damit 
zu beschäftigen...

Würde mich freuen, wenn wir hier weiterhin Erfahrungsberichte und Tipps 
sammeln würden.

von Horst H. (horha)


Bewertung
0 lesenswert
nicht lesenswert

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe einen Artikel zum Modul angelegt:

http://www.mikrocontroller.net/articles/RFM69

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Ich habe einen Artikel zum Modul angelegt:
>
> http://www.mikrocontroller.net/articles/RFM69

Super, danke!!

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Hat schon jemand eine veröffentlichbare Library dafür?
Habe seit einer Weile leider kaum Zeit für Elektronik gehabt, keine 
Chance da an einer Ansteuerung des Moduls zu arbeiten :-(

von Speedy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

seit ein paar Tagen habe ich einen 433 MHz RFM69CW für ein sogenanntes 
Vario im Einsatz. D.h. ich übertrage eigentlich keine Werte, sondern 
nutze die FM um an einem LPD-Empfänger einen entsprechenden Ton zu 
empfangen (siehe VolksVario: 
http://www.volksvario.de/volksvariopro.html). Die Umstellung von RFM12 
auf RFM69CW war nicht nur dank der gleichen Pinbelegung einfach, sondern 
auch wegen der sehr einfachen Anwendung. Es reicht den Sender 
anzuschmeissen und regelmäßig einen 2,5 kHz Hub zu Erzeugen. Mir ist 
jedoch aufgefallen, daß der RFM69CW nicht nur auf den eingestellten 
Kanal sendet, sonder in mindestens vier oder fünf andere Kanäle auch.

Ist sowas jemandem hier schon aufgefallen? Beim RFM12 passiert es wohl 
nicht. Ich habe mein anderes Vario als spectrum analyser mit dem 
Programm nRfMon eingesetzt. Der RFM69CW sendet mindestens auf zwei 
Frequenzen mit fast der gleichen Stärke. Im Allgemeinen sendet es 
ziemlich viel in dem Bereich. Ist das Teil vielleicht defekt? Der 
Quarzoszillator schwingt brav mit ziemlich genau 32 MHz.

Der Aufbau ist wie im VolksvarioPro: Arduino pro Mini 328 3.3V, RFM69CW, 
Barometer, und eine selbsgebaute Koaxialantenne (172mm Antenne und 
weitere 172mm als "Grundplatte" noch mit der Abschirmung ummantelt).

Viele Grüße,
Andrés

von Ulli (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe gerade eine PCB entwickelt, welche mit RFM12 und RFM69 
arbeitet. (Kommt in 2 Wochen :) Derzeit habe ich einiges mit RFM12 
realisiert. OOK und FSK Signale...
Das würde ich jetzt gerne auf RFM69 umstellen, stehe aber noch ganz am 
Anfang. :(
Da ich unter anderem FS20 Signale einlesen möchte würde mir sehr der 
Quellcode für das Senden von FS20 Signalen weiter helfen. Würdet Ihr die 
Beispielquellen zur Verfügung stellen?

Grüße,
 Ulli

von Felix P. (fixxl)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Falls es jemanden interessiert, habe ich in den Anhang den derzeitigen 
Stand meiner RFM69-Bibliothek gepackt, wie ich sie auch erfolgreich in 
einem Netz mit RFM69- und RFM12-Modulen im Einsatz habe.

Ich arbeite mit den Modulen am Atmega328p in Minimalkonfiguration, d.h. 
nur das SPI-Interface ist angeschlossen, keine digitalen IOs zur 
Erzeugung von Interrupts.

Die Einstellungen zu Pinbelegung, Frequenz, Bitrate sind in der 
Headerdatei anzupassen, Hardware-SPI kann nur mit Controllern der Reihe 
Atmega88, 168, 328 genutzt werden, bei denen das SPI-Interface auf den 
Pins B3, B4 und B5 liegt.

Weitere Fragen gerne hier im Thread.

von Marius S. (lupin) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mal ganz doof gefragt...

Wofür verwendet Ihr die Module? (Projekt-Ideen :))

Und warum nicht 2,4GHz mit nRF24L?


Speedy schrieb:
> 433 MHz RFM69CW für ein sogenanntes Vario im Einsatz

Reicht die Reichweite dafür aus?

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Marius S. schrieb:
> Mal ganz doof gefragt...
>
> Wofür verwendet Ihr die Module? (Projekt-Ideen :))

Home Automation Netzwerk, Funkfernsteuerung und per Funk angebundene 
Sensoren.

> Und warum nicht 2,4GHz mit nRF24L?

Je höher die Frequenz desto geringer die Reichweite. Deshalb sind mir 
die 868 MHz lieber.

von Ulli (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Felix danke das du deinen code gepostet hast. Schonmal ein guter 
Einstieg.

@Stefan: Würdest du deinen Code für OOK Signale auch posten. Der würde 
mich brennend interessieren da ich derzeit mit dem RFM12 Funksteckdosen 
steuere und FS20 Module einlese. Das möchte ich zukünftig mit dem RFM69 
machen.

von P. S. (p01)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Felix,

hast du deine Routinen ohne Hardware SPI getestet? Ich probiere die 
RFM69CW (433 MHz) mit einem Attiny84. Ich habe die Module jeweils an die 
Pins A2..A5 angeschlossen und die Definitionen in der rfm69.h 
entsprechend angepasst. Hardware-SPI und RFM12COMP sind aus, Frequenz 
auf 433 MHz eingestellt.

Wenn ich rfm_status() aufrufe, erhalte ich nach der Init 0xD800, aber 
empfange leider nichts. Hast du eine Idee?

Eines der Modul arbeitet als Sender:
#include "main.h"

int main(void) {
  uint8_t string[] = "HELLO!";
  uint8_t tx_length = sizeof(string)/sizeof(uint8_t);
  
  rfm_init();

  for(;;) {
    rfm_transmit((char *) string, tx_length);
    _delay_ms(500);
  } 
  return 0;
}

Das andere Modul als Empfänger (UART-Funktionen nicht beigefügt):
#include "main.h"

int main(void) {  
  char array[MAX_ARRAYSIZE+1];
  uint8_t rx_length = 0;

  rfm_init();
 
  while(1) {
    if(rfm_receiving()) {
      rfm_receive(array, &rx_length);
      uart_string(array);
    }
  }
  return 0;
}

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Die Software-SPI funktioniert bei mir problemlos und scheint es auch bei 
dir zu tun, wenn der Status nach der Initialisierung korrekt ausgelesen 
wird.

Trägerfrequenz und Bitrate sind bei beiden Controllern identisch 
eingestellt?

Wenn dem so ist, kann es helfen, den Build-Ordner komplett zu leeren und 
neu zu kompilieren, damit auch wirklich auf die aktuelle Version der 
Source- und Headerfiles zugegriffen wird.

von P. S. (p01)


Bewertung
0 lesenswert
nicht lesenswert
Ich konnte es noch etwas eingrenzen. Beide Module haben nach der 
rfm_init() den selben Status und sind auch gleich eingestellt. Das 
sendende Modul hat einen Timeout beim Setzen der RX-Ready-Flag nach dem 
Senden. Hast du eine Idee woran das liegen könnte?

von P. S. (p01)


Bewertung
0 lesenswert
nicht lesenswert
Antworte mir mal selbst: Problem behoben durch 2 Drahtantennen. Damit 
funktioniert alles!

Vielen Dank an Felix für die Bereitstellung der Bibliothek!

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Mit welchen Antennen hattest du davor gearbeitet? Ganz ohne Antenne kann 
ich mir schon vorstellen, dass das Modul unvorhergesehenes Verhalten 
zeigt.

Im Datenblatt findet sich die Angabe, dass am Antennenausgang bei 
maximaler Ausgangsleistung das Stehwellenverhältnis höchstens 3:1 
betragen darf. Das entspricht einer maximal zulässigen am 
Antennenausgang reflektierten Leistung von 5mW (7 dBm). Weil ohne 
Antenne komplette Fehlanpassung vorliegt, wird die gesamte Sendeleistung 
zurück in die Sendeendstufe reflektiert. Ich möchte nicht testen, was 
passiert, wenn man mehr als 7 dBm Ausgangsleistung einstellt und sendet, 
während keine Antenne angeschlossen ist.

von Ulli (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade dran meinen ersten RFM69 in Betrieb zu nehmen. Aktuell 
erpfange ich FSK Pakete von ItPlus Temperatursensoren (LaCross)
Ich musste den RFM12 auf eine Frequenz v on 868.3 MHz und eine Bitrate 
von 17240 BPS anpassen.

Derzeit nutze ich für den RFM69 die Library von LowPowerLab und schaffe 
ich leider nicht die Packete korrekt zu empfangen. Ich bekomme zwar ab 
und an mal Packete, die sehen aber nicht korrekt aus und kommen auch 
nicht im korrekten regelmäßigen Abstand.
Was muss ich dem am RFM69 korrekterweise konfigurieren?

Derzeit sieht es so aus
#define RF_BITRATEMSB_17240 0x07 //ITPlus Bitrate  17.24 kbps
#define RF_BITRATELSB_17240 0x40

    /* 0x01 */ { REG_OPMODE, RF_OPMODE_SEQUENCER_ON | 
RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY },
    /* 0x02 */ { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | 
RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00 }, 
//no shaping
    /* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_17240}, //default:4.8 
KBPS
    /* 0x04 */ { REG_BITRATELSB, RF_BITRATEMSB_17240},
    /* 0x05 */ { REG_FDEVMSB, RF_FDEVMSB_5000}, //default:5khz, (FDEV + 
BitRate/2 <= 500Khz)
    /* 0x06 */ { REG_FDEVLSB, RF_FDEVLSB_5000},

    /* 0x07 */ { REG_FRFMSB, (freqBand==RF69_315MHZ ? RF_FRFMSB_315 : 
(freqBand==RF69_433MHZ ? RF_FRFMSB_433 : (freqBand==RF69_868MHZ ? 
RF_FRFMSB_868 : RF_FRFMSB_915))) },
    /* 0x08 */ { REG_FRFMID, (freqBand==RF69_315MHZ ? RF_FRFMID_315 : 
(freqBand==RF69_433MHZ ? RF_FRFMID_433 : (freqBand==RF69_868MHZ ? 
RF_FRFMID_868 : RF_FRFMID_915))) },
    /* 0x09 */ { REG_FRFLSB, (freqBand==RF69_315MHZ ? RF_FRFLSB_315 : 
(freqBand==RF69_433MHZ ? RF_FRFLSB_433 : (freqBand==RF69_868MHZ ? 
RF_FRFLSB_868 : RF_FRFLSB_915))) },

    /* 0x25 */ { REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01 }, //DIO0 is 
the only IRQ we're using
    /* 0x2e */ { REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | 
RF_SYNC_SIZE_2 | RF_SYNC_TOL_0 },
    /* 0x2f */ { REG_SYNCVALUE1, 0x2D },      //attempt to make this 
compatible with sync1 byte of RFM12B lib
    /* 0x30 */ { REG_SYNCVALUE2, 0x4D }, //NETWORK ID

Was habe ich denn vergessen? Wie setzt ich denn die Bandbreite für den 
Empfang?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Die Register 0x03 und 0x04 sind bei dir beide mit dem MSB (0x07) 
beschrieben, das ergäbe eine Bitrate von 17788 bit/s, es muss wohl so 
lauten:
/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_17240}, 
/* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_17240},

Die Empfängerbandbreite wird im Register 0x19 mit den unteren fünf Bits 
eingestellt. Näheres dazu auf Seite 67 im Datenblatt von Hope-RF.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe vor 2/3 Wochen auch angefangen meine Software auf das RFM69 zu 
migrieren.
Habe auch die Lowpowerlab-Lib als Basis genommen und sie etwas auf meine 
Zwecke modifiziert und sorgfältig Register für Register die 
Konfiguration auf die RFM12 abgestimmt.
Konnte nach 3 Abenden Pakete von meinen RFM12 empfangen, ohne bei denen 
etwas anpassen zu müssen. Hervorragend!
Senden noch nicht getestet, das steht als nächstes an.
Danach ist noch mein CRC/Paketwiederholungsprotokoll implementieren - 
das dürften nochmal 1-2 Abende sein (die RFM69 können das zwar tlw 
Built-In, das kann ich aber ohne Modifikation des alten RFM12-Code nicht 
verwenden). Damit verstehen sich alte und neue Schaltungen dann perfekt 
und die Migration ist fertig.
Ich fahre bisher nur mit einer Bitrate von 9.600 um die Reichweite zu 
maximieren, möchte auch Nodes im Garten erreichen können.
Das klappt mit den RFM12 gerade so. Meine Hoffnung ist, dass das mit dem 
RFM69 deutlich leichter wird.

von Ulli -. (ulli2k)


Bewertung
0 lesenswert
nicht lesenswert
Welche Register hast du denn alle anpacken müssen? Mein Stand ist 
folgender:

#define XTALFREQ      32000000UL

/* Carrierfrequenz in Hz */
#define FREQUENCY      868300000LL
#define BITRATE        17240L

// Don't change anything from here
#define FRF            ((FREQUENCY*524288LL + (XTALFREQ/2)) / XTALFREQ) 
//FSTEP = FXOSC/2^19
#define FRF_MSB        ((FRF>>16) & 0xFF)
#define FRF_MID        ((FRF>>8) & 0xFF)
#define FRF_LSB        ((FRF) & 0xFF)

#define DATARATE      ((XTALFREQ + (BITRATE/2)) / BITRATE)
#define DATARATE_MSB  (DATARATE>>8)
#define DATARATE_LSB  (DATARATE & 0xFF)

  const byte CONFIG[][2] =
  {
    /* 0x01 */ { REG_OPMODE, RF_OPMODE_SEQUENCER_ON | 
RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY },
    /* 0x02 */ { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | 
RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00 }, 
//no shaping
    /* 0x03 */ { REG_BITRATEMSB, DATARATE_MSB}, //default:4.8 KBPS
    /* 0x04 */ { REG_BITRATELSB, DATARATE_LSB},
    /* 0x07 */ { REG_FRFMSB, FRF_MSB },
    /* 0x08 */ { REG_FRFMID, FRF_MID },
    /* 0x09 */ { REG_FRFLSB, FRF_LSB },
    /* 0x18 */ { REG_LNA,  RF_LNA_ZIN_50| RF_LNA_GAINSELECT_AUTO }, 
//LNA Gain setting to auto
    /* 0x19 */ { REG_RXBW, RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_24 | 
RF_RXBW_EXP_1 }, //(BitRate < 2 * RxBw) --> 166,7 kHz
    /* 0x25 */ { REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01 }, //DIO0 is 
the only IRQ we're using
    /* 0x2e */ { REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | 
RF_SYNC_SIZE_2 | RF_SYNC_TOL_0 },
    /* 0x2f */ { REG_SYNCVALUE1, 0x2D },      //attempt to make this 
compatible with sync1 byte of RFM12B lib
    /* 0x30 */ { REG_SYNCVALUE2, networkID }, //NETWORK ID
   }

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Es fehlen vor allem noch die Paket-Konfigurationseinstellungen im 
Register 0x37, wo du Dinge wie das Paketformat (feste oder variable 
Länge) und den Hardware-CRC-Check konfigurieren musst. Standardmäßig ist 
dort eingestellt, dass du eine feste Paketlänge von 64 Bytes empfängst 
und das Paket, sofern der CRC-Check fehlschlägt, verworfen wird. Das 
musst du an dein Übertragungsprotokoll anpassen, wäre schon ein arger 
Zufall, wenn du genau mit dieser Länge und dem in Hardware 
implementierten CRC-Algoritmus arbeiten würdest.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Ulli -- schrieb:
> Welche Register hast du denn alle anpacken müssen? Mein Stand ist
> folgender:

Ich bin einfach akribisch durch alle Register des RFM69 gegangen und 
habe die entsprechenden Werte des RFM12 nachgebildet, oder 
recherchiert/überlegt, welches Setting das RFM69 für meinen Zweck 
braucht.
So habe ich die Encryption und Crc aus der Lowpower Lib rausgeschmissen, 
weil das mein Crc/Resend-Protokoll schon macht, das dann oben drauf 
sitzt.
Hilft Dir wenig, wenn ich Dir meine Config schicke, weil Du dann dich 
andere Frequenzeinstellungen für Deine Bitrate brauchst.

von Ulli -. (ulli2k)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

ich versuche gerade das FS20 Protocol mit einem RFM69 zu empfangen.
Kannst du mir nen Hinweis geben? Ich habe bereits das Wiki 
(https://www.mikrocontroller.net/articles/RFM69) gelesen und folgende 
Konfiguration vorgenommen:
/* 0x01 */ { REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_LISTEN_OFF | 
RF_OPMODE_STANDBY }, //Sequencer on | Standby Mode
/* 0x02 */ { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | 
RF_DATAMODUL_MODULATIONTYPE_OOK | RF_DATAMODUL_MODULATIONSHAPING_00 }, 
//no shaping
/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_5000},
/* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_5000},

/* 0x07 */ { REG_FRFMSB, 0xD9 }, //FRF_MSB }, //868,37 MHz
/* 0x08 */ { REG_FRFMID, 0x17 }, //FRF_MID },
/* 0x09 */ { REG_FRFLSB, 0xAE }, //FRF_LSB },

/* 0x18 */ { REG_LNA,  RF_LNA_ZIN_200| RF_LNA_GAINSELECT_AUTO }, // 
200Ohm default / rfm12 MAX-LNA Gain setting
/* 0x19 */ { REG_RXBW, RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_20 | 
RF_RXBW_EXP_1 }, //(BitRate < 2 * RxBw) -> (17,24kbs < 2* rfm12 200 kHz
/* 0x25 */ { REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01 }, //DIO0 is the 
only IRQ we're using
/* 0x28 */ { REG_IRQFLAGS2, RF_IRQFLAGS2_FIFOOVERRUN }, // Writing to 
this bit ensures the FIFO & status flags are reset
/* 0x29 */ { REG_RSSITHRESH, (97*2) }, //(91*2) rfm -91dBm //must be set 
to dBm = (-Sensitivity / 2) - default is 0xE4=228 so -114dBm
/* 0x2E */ { REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_MANUAL | 
RF_SYNC_SIZE_7 | RF_SYNC_TOL_0 },
/* 0x2F */ { REG_SYNCVALUE1, 0x33 }, //FS20 Sync Header
/* 0x30 */ { REG_SYNCVALUE2, 0x33 },
/* 0x30 */ { REG_SYNCVALUE3, 0x33 },
/* 0x30 */ { REG_SYNCVALUE4, 0x33 },
/* 0x30 */ { REG_SYNCVALUE5, 0x33 },
/* 0x30 */ { REG_SYNCVALUE6, 0x33 },
/* 0x30 */ { REG_SYNCVALUE7, 0x38 },
/* 0x37 */ { REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | 
RF_PACKET1_DCFREE_OFF |
                 RF_PACKET1_CRC_OFF | RF_PACKET1_CRCAUTOCLEAR_OFF |
                 RF_PACKET1_ADRSFILTERING_OFF },
/* 0x38 */ { REG_PAYLOADLENGTH, 0x40 }, //max0x40 in variable length 
mode: the max frame size, not used in TX
/* 0x3D */ { REG_PACKETCONFIG2, RF_PACKET2_RXRESTARTDELAY_NONE | 
RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF }, //RXRESTARTDELAY 
must match transmitter PA ramp-down time (bitrate dependent)

Leider empfange ich kontinuerlich irgend einen Misst und bei einem 
Tastendruck empfange ich zeitgleich garnichts :(

Stefan schrieb:
> Moin,
>
> bin auch gerade dabei auf RFM69C umzusteigen. Die Ansteuerung
> funktioniert ganz anders, aber ich finde die Umstellung lohnt sich, und
> die Teile können endlich OOK. Die FS20 Funksteckdosen kann ich bereits
> ansteuern. Auch das konfigurierbare Syncword und die Packetengine nehmen
> einem viel Arbeit ab.

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich Versuche seit geraumer Zeit das RFM69CW zu laufen zu bringen , am PI 
klappt es auch schon ganz gut , nur am Arduino will es nicht 
funktionieren und verhält sich immer mal anders. Nun will ich es mit 
einem ATMega328 versuchen und wollte Felixs Code verwenden, bekomme aber 
schon beim Compilieren den Fehler:

Der Befehl "mmcu" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
make: [RFM69.elf] Error 1 (ignored)
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature 
RFM69.elf RFM69.hex
process_begin: CreateProcess(NULL, avr-objcopy -O ihex -R .eeprom -R 
.fuse -R .lock -R .signature RFM69.elf RFM69.hex, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
make: *** [RFM69.hex] Error 2
Build failed with 1 errors and 0 warnings...

Weis jemand bzw. Felix woran es liegen kann.
Ich habe die drei Header und die beiden C files in mein Projekt 
integriert aber wenn ich es Builden will kommt das bei raus ??? :/

danke schonmal

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
"mmcu" ist normalerweise ein Schalter, welcher der avr-gcc.exe übergeben 
wird und den verwendeten Controllertyp bezeichnet. Da steht dann in der 
Kommandozeile irgendwas wie:
avr-gcc -Wall -Os -mmcu=atmega328p ...

Wie kompilierst du deinen Code? Funktioniert das Kompilieren eines 
Minimalbeispiels?

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ich musste den Kompiler Path extra angeben, damit klappt es jetzt. nun 
hab ich noch probleme mit dem Programmer , der sagt start register 
sollte 0x00 sein ist aber 0xFF ... aber das hat ja sicherlich nichts mit 
deinem Programm zu tun ... falls mir jemand trotzdem hälfen könnte wär 
es cool
beste grüße

von Alfred Q. (higedigdag)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich spiele mit dem Gedanken, die freie CUL Firmware (culfw) auf RFM69CW 
anzupassen. Der CUL verwendet das CC1101 von TI.
Laut der Datenblätter sind die Features ähnlich: RFM69CW vs. CC1101.
Hat sich zufällig damit schon jemand hier befasst?

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Ich spiele gerade wieder ein bisschen mit dem RFM69, an der Umsetzung 
einer Lib, die mir transparent RFM12 und RFM69 verwenden lässt.
Und es scheint so, dass das RFM69, selbst dann wenn man CRC 
ausgeschaltet hat beim Empfang, die letzten beiden Bytes schluckt (wo 
normalerweise der CRC drinsteht).
Hat das schonmal jemand beobachtet?

Ich hab schon mehrmals meinen Code durchgesehen auf Fehler und werde mir 
immer sicherer, dass man zwar das CRC Checking abschalten kann, dass das 
den Packet Handler des RFM69 nicht daran hindert trotzdem die letzten 2 
Bytes wegzunehmen...
Wenn dem so wäre, dann ist das ein Bug im RFM69.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du es gemeinsam mit den RFM12 verwenden willst, benutzt du 
wahrscheinlich den Paketmodus mit variabler Länge, oder? Hast du das 
richtig eingestellt, die maximale Payloadlänge groß genug gewählt und 
gibst du die Länge richtig an? Ohne Code kann man nur raten.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Ja, genau, Paketmodus mit Variabler Länge und PayloadLen = 66.
Und nach diversen Versuchen bin ich mir recht sicher, dass der RFM69 
Paket Handler dann die letzten beiden Bytes unterschlägt, obwohl ich CRC 
ausgeschaltet habe.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Code?

Testest du mit RFM12 und RFM69 oder mit zwei RFM69?

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Code posten macht gerade nicht so viel Sinn, zu komplex. Müsste ich 
reduzieren, das ist relativ aufwändig.
Deshalb frage ich auch vorab, ob jemand das schonmal hatte, BEVOR ich 
diese 2. Stufe der Diagnose zünde und mir das Ganze als Minimal zum 
Testen zusammenstelle.

Ich teste mit RFM12 und RFM69, folgende Szenarien getestet:
- RFM12 empfängt von RFM12: alles prima, bekomme die Prüfsumme (klar, 
das Protokoll erfordert es, musste ja funktionieren)
- RFM69 empfängt von RFM12: geht nur, wenn ich beim RFM69 CRC-Prüfung 
ausschalte (klar, die RFM12 senden einen anderen CRC) und es fehlen die 
letzten 2 Bytes, der CRC den ich dem RFM12 mitgebe.

Bin gerade dabei das RFM12 einen mit RFM69 kompatiblen CRC senden zu 
lassen, das hat angeblich schon jemand geschafft:
https://lowpowerlab.com/forum/index.php/topic,209.msg1017.html#msg1017

Bei mir will's gerade noch nicht, aber ich hab noch potenzielle 
Fehlerquellen, die ich noch untersuchen muss.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Und du hast daran gedacht, dass das Längenbyte, welches du vom RFM12 
schickst, den Wert Länge der tatsächlichen Payload plus zwei haben muss?

Falls du für die Semtech/HopeRF-CRC den Code brauchst:
// CRC16 gemäß Semtech-CCITT (Finales Ergebnis muss vor Senden/Prüfen bitweise invertiert werden!)
uint16_t crc16(uint16_t crc, uint8_t data) {
  crc ^= (data << 8);
  for (uint8_t i = 0; i < 8; i++) {
    data = ((crc & 0x8000) && 1); // Wird durch && entweder 0 oder 1
    crc <<= 1;
    if (data) crc ^= 0x1021; // 0x1021 weil Generatorpolynom x^16+x^12+x^5+1 und MSB first
  }
  return crc;
}

Du musst den Wert ab dem Längenbyte nach jedem Byte aufrufen und den 
bisherigen CRC-Wert als Startwert nehmen, der Seedwert 0x1D0F ist von 
Semtech festgelegt.
// CRC-Variable festlegen
uint16_t crcwert;

// Anfangen mit dem Längenbyte
crcwert = crc16(0x1D0F, laengenbyte);

// Nach jedem Datenbyte
crcwert = crc16(crcwert, datenbyte);

// Und am Ende vor dem Senden (MSB zuerst senden!)
crcwert ^= 0xFFFF;

: Bearbeitet durch User
von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Felix Pflaum schrieb:
> Und du hast daran gedacht, dass das Längenbyte, welches du vom RFM12
> schickst, den Wert Länge der tatsächlichen Payload plus zwei haben muss?

Das ja.

> Falls du für die Semtech/HopeRF-CRC den Code brauchst:
> ...
> Du musst den Wert ab dem Längenbyte nach jedem Byte aufrufen und den
> bisherigen CRC-Wert als Startwert nehmen, der Seedwert 0x1D0F ist von
> Semtech festgelegt.
>
>
> // CRC-Variable festlegen
> uint16_t crcwert;
> 
> // Anfangen mit dem Längenbyte
> crcwert = crc16(0x1D0F, laengenbyte);
> 
> // Nach jedem Datenbyte
> crcwert = crc16(crcwert, datenbyte);
> 
> // Und am Ende vor dem Senden (MSB zuerst senden!)
> crcwert ^= 0xFFFF;
> 

Da könnte ich ein Problem haben, ich glaube ich habe die falsche 
CRC-Routine.

Danke!!

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt mal den Spieß umgedreht und sende vom RFM69 an das RFM12, 
mit CRC aus.
Und siehe da, das RFM69 sendet auch "0x55 0x55" am Ende extra.
D.h. der Modus "CRC off" ist nicht so implementiert, wie man meinen 
würde.
Beim Senden werden 2 Bytes extra gesendet, beim Empfangen werden 2 
geschluckt.
Ich komme also gar nicht drumherum alle Module mit dem CRC des RFM69 
laufen zu lassen.

Hier (gesendet: "A"), was das RFM12 empfängt:

41 64 7A     CRC ein beim RFM69
41 55 55     CRC aus beim RFM69

: Bearbeitet durch User
von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Conny G. schrieb:
> Felix Pflaum schrieb:
>> Falls du für die Semtech/HopeRF-CRC den Code brauchst:
>> ...
>> Du musst den Wert ab dem Längenbyte nach jedem Byte aufrufen und den
>> bisherigen CRC-Wert als Startwert nehmen, der Seedwert 0x1D0F ist von
>> Semtech festgelegt.
> Da könnte ich ein Problem haben, ich glaube ich habe die falsche
> CRC-Routine.

Felix, das war's, herzlichen Dank, you made my day!

Das RFM12 spricht jetzt erfolgreich mit dem RFM69 indem ich den 
richtigen CRC mitschicke!

von Christian S. (roehrenvorheizer)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

RFM69HCW funktioniert bei mir mit seinesgleichen seit Ende März in einem 
Experimentier-Projekt. Auch mit AES-Verschlüsselung.

mfG

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Conny G. schrieb:
> Ich habe jetzt mal den Spieß umgedreht und sende vom RFM69 an das RFM12,
> mit CRC aus.
> Und siehe da, das RFM69 sendet auch "0x55 0x55" am Ende extra.
> D.h. der Modus "CRC off" ist nicht so implementiert, wie man meinen
> würde.
> Beim Senden werden 2 Bytes extra gesendet, beim Empfangen werden 2
> geschluckt.
> Ich komme also gar nicht drumherum alle Module mit dem CRC des RFM69
> laufen zu lassen.
>
> Hier (gesendet: "A"), was das RFM12 empfängt:
>
> 41 64 7A     CRC ein beim RFM69
> 41 55 55     CRC aus beim RFM69

Klasse, dass dir der Code weitergeholfen hat und es mit der RFM69-CRC 
jetzt läuft!

Das Problem ohne CRC würde mich aber schon noch interessieren:
Was hast du dem Packet-Handler beim Senden des "A" jeweils als 
Längenbyte übergeben? In beiden Fällen 1?
Ansonsten kann das Problem natürlich auch beim RFM12 und dessen 
Konfiguration liegen. Man muss dem RFM12 ja sagen, wie viele Bytes es 
empfangen muss. Wenn du nur zwei Bytes vom RFM69 schickst (Länge und 
'A'), das RFM12 aber aufgefordert ist, noch zwei weitere Male die FIFO 
auszulesen, kann da natürlich irgendein Wert drinstehen. Ich weiß nicht, 
was die FIFO des RFM12 ausgibt, wenn man sie einfach mal so ausliest, 
ohne dass irgendwas empfangen wurde.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Felix Pflaum schrieb:
> Conny G. schrieb:
>> Ich habe jetzt mal den Spieß umgedreht und sende vom RFM69 an das RFM12,
>> mit CRC aus.
>> Und siehe da, das RFM69 sendet auch "0x55 0x55" am Ende extra.
>> D.h. der Modus "CRC off" ist nicht so implementiert, wie man meinen
>> würde.
>> Beim Senden werden 2 Bytes extra gesendet, beim Empfangen werden 2
>> geschluckt.
>> Ich komme also gar nicht drumherum alle Module mit dem CRC des RFM69
>> laufen zu lassen.
>>
>> Hier (gesendet: "A"), was das RFM12 empfängt:
>>
>> 41 64 7A     CRC ein beim RFM69
>> 41 55 55     CRC aus beim RFM69
>
> Klasse, dass dir der Code weitergeholfen hat und es mit der RFM69-CRC
> jetzt läuft!
>
> Das Problem ohne CRC würde mich aber schon noch interessieren:
> Was hast du dem Packet-Handler beim Senden des "A" jeweils als
> Längenbyte übergeben? In beiden Fällen 1?

Das läuft so (die wichtigen Stellen zusammenkopiert):
    char buf[] = {
        0x0, 0x3 ^ 0x0 ^ 0xff, 'A' };

    spi_transfer(REG_FIFO | 0x80);
    spi_transfer(sizeof(buf));

    for (byte i = 0; i < sizeof(buf); i++)
        spi_transfer(((byte*)buf)[i]);

Ich habe da einen "Transport Layer" check drin, der bei den RFM12 direkt 
beim Empfang mit einer Prüfsumme prüft, ob Längenbyte, Pakettyp (hier 
0x0) stimmen, das sind die 2 Bytes vor dem 'A'.


> Ansonsten kann das Problem natürlich auch beim RFM12 und dessen
> Konfiguration liegen. Man muss dem RFM12 ja sagen, wie viele Bytes es
> empfangen muss. Wenn du nur zwei Bytes vom RFM69 schickst (Länge und
> 'A'), das RFM12 aber aufgefordert ist, noch zwei weitere Male die FIFO
> auszulesen, kann da natürlich irgendein Wert drinstehen. Ich weiß nicht,
> was die FIFO des RFM12 ausgibt, wenn man sie einfach mal so ausliest,
> ohne dass irgendwas empfangen wurde.

Der Empfang beim RFM12 basiert darauf, dass das Modul per INT 
signalisiert, dass Daten im Fifo sind. Ich empfange also nur, wenn das 
RFM12 mir sagt, es ist etwas da.
D.h. wenn es so wäre, dass die Länge falsch ist, dann würde folgendes 
passieren:
- nach den obigen Bytes kommt nix mehr beim RFM12
- die Statemachine gibt aber die Daten noch nicht frei (empfange Bytes < 
Längenbyte)
- es kämen später irgendwelche zufälligen Daten
- die werden empfangen und das Paket freigegeben

Dann dürfe es nicht immer 0x55 sein, die ich empfange.
Deshalb ist davon auszugehen, dass diese vom RFM69 gesendet werden.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe HopeRF angeschrieben und eine Erklärung dafür bekommen, weshalb 
ich die zwei x55 extra empfange:

"When RFM69W enter the TX mode, it will continuously send Preamble 
signal automatically, like 0x55 or 0xAA.
If you only send one byte data, but the receiver read 3 bytes instead of 
1 byte, then the last byte will receive 0x55."

D.h. ich muss nach der angekündigten Anzahl Bytes aufhören zu empfangen, 
da das rfm69 munter weiter Präambel sendet.

Bzgl Abschneiden der 2 Bytes beim Empfang mit Crc=Off hat man sich nicht 
geäußert, ich habe nochmal nachgefragt.

: Bearbeitet durch User
von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Wie ist das bei dir in der Software mit dem Tx-Mode geregelt? Ich 
handhabe es so, dass ich in den Grundeinstellungen die TxStartCondition 
auf 1 (FifoNotEmpty) setze und dann zum Senden FIFO zunächst im 
Standby-Modus fülle, dann Tx aktiviere, darauf warte, dass das 
PacketSend-Bit gesetzt wird und sofort wieder in den Standby-Mode 
wechsle.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Verwende diese Lib als Basis und passe sie für meine Zwecke an:
https://github.com/LowPowerLab/RFM69

Habe es gerade nachgesehen:
TxStartCondition ist FifoNotEmpty.

Ablauf:
- Standby-Modus setzen
- INT-Pin wird auf "Packet sent" gemappt
- Fifo füllen
- TX Mode setzen
- INT-Pin abwarten, das Vollzug signalisiert
- Standby setzen

Entspricht also Deinem Ablauf mit dem Unterschied, dass für die 
Erkennung der Versanddurchführung nicht ein Register abgefragt wird, 
sondern das Int-Pin verwendet wird. Komisches Verfahren eigentlich.

Das würde bedeuten, dass das RFM69 auf jeden Fall 1x Präambel 
hinterherschickt, auch wenn man sofort den TX Mode abschaltet.

Bzgl. 2 Bytes Abschneiden hat HopeRF geantwortet es würde nichts 
abgeschnitten, wenn Crc=Off.
Wenn ich das nochmal ganz sicher wissen wollte, dann müsste ich eine 
Minimalversion bauen, die ohne Int, ohne State Machine und alles nur das 
Senden/Empfangen macht. Weiss nicht, ob ich da noch Lust drauf habe, 
nachdem es mit der Verwendung des RFM69-Crc-Algorithmus beim RFM12-Code 
ja jetzt geht.
Brauche sowieso CRC und die anderen Schaltungen neu flashen, das ist ok.
Nur alle Funkmodule wechseln wäre blöd - zumal die RFM12 alle auf 5V 
laufen.

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Servus miteinander,

ich bräuchte mal einen kleinen Tip auf was ich vielleicht nicht achte. 
Ich versuche jetzt seit ein paar monaten mit den RFM69 etwas zu senden 
bzw zu empfangen. Ich habe eine lib für den RasPI bekommen die 
funktionieren sollte, dort angeschlossen und auch was empfangen , aber 
nur sporatisch und nur müll (nicht interpretierbar). Dann zusammen mit 
arduino und lowpowerlab lib, die läuft zwar auch durch und 
sendet...(angeblich) und empfängt scheinbar nichts. Ich habe versucht 
gegenseitig was zu empfangen, hat nicht geklappt. dann habe ich es in 
verbindung mit ATmega328P und felix seinem programm/lib versucht auch 
nichts (aber es ist laut blinkender LED zumindest in einer schleife 
gelaufen)... nun habe ich einfach versucht mit felix seinerm Programm 
zwei atmega328P mit eineander reden zu lassen, da ich dachte die 
Grundeinstellungen sind ja gleich ... komme ich scheinbar nicht mal 
durch die rfm_init() durch...
rfm12 comp steht auf 0 und hardware spi ist ein...
manichmal hab ich schon allein das gefühl das er es nicht schaft die 
register zu beschreiben und in einer der while schleifen hängt ... kann 
das sein ???
gibt es irgendwas auf das ich nicht geachtet habe.
ich kann mir halt nichts ausgeben lassen was sie so an nachrichten 
empfangen es läuft alles über led-debugging um zu schauen ob bereiche im 
code abgearbeitet werden... so lange reder kurzer sinn ... es funzt 
einfach nett ;-)
grüße

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Mögliche Fehlerquellen gibt es viele.

Verwendest du immer dasselbe Modul (defekt?) oder hast du schon mehrere 
getestet? Wie sind die Module angeschlossen (Kurzschlüsse zwischen 
Pins?)? Mit welcher Spannung (3.9 V max. zulässig!) und aus welcher 
Quelle versorgst du die Module? Passen die Antennen zum verwendeten 
Frequenzbereich? Sind alle GND-Pins angeschlossen?

Um zu testen, ob die Registerzugriffe funktionieren, kann man bei den 
RFM69 recht einfach die Registerzustände auslesen. Wenn man also z.B. 
das Mode-Register oder die Register für Frequenz und Bitrate beschreibt 
und anschließend deren Werte zurückliest, sollte der zuvor 
eingeschriebene Wert zurückgegeben werden.

von kleiner_meiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hiho zusammen,

erstmal großen dank an Felix Pflaum für die bereitstellung der Lib.

Ich bin dabei das Funkmodul 
http://www.pollin.de/shop/downloads/D810302D.PDF
zu benutzen um von einem Mirkocontroller zum anderen (beides 1284p) 
Daten zu übertragen. Konregt gesagt abgespeicherte werte aus einem Array 
zu übertragen. Ich habe die die Lib auch größten Teils angepasst und die 
beschrieben SPI-Hardeware ausgestellt. Dazu muss gesagt werden der 
Spi-Bus geht über einen Spannungsteiler der aus 5V --> 3,2V macht. also 
ansich aussreichtend für das Funk-Modul. Als nächstes haben ich an Ana 
einen Spektrum-Analysator angeschlossen und wollte wissen ob das 
Funkmodul die entsprechend etwas rausschickt. Leider konnte ich nix 
erkennen. Und nun frage ich mich bissel woraus liegen kann?
Eventl Pinbelegung falsch? oder was anderes wäre über jede idee oder 
denk anstöße sehr dankbar. Desweiteren sollten Informationen noch 
benötigt werden werde ich diese gerne nachreichen.

In dem Sinne ;D

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
kleiner_meiner schrieb:
> Eventl Pinbelegung falsch? oder was anderes wäre über jede idee oder
> denk anstöße sehr dankbar. Desweiteren sollten Informationen noch
> benötigt werden werde ich diese gerne nachreichen.

Ohne Schaltplan, den Quelltext ist es unmöglich zu ahnen, wo das Problem 
liegen könnte.

von greg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nordic Semiconductor hat übrigens auch ICs für 433/900 MHz, z.B. den 
nRF905. Module inkl. Antenne gibt's ab 5 EUR in der Bucht. Die 
Ansteuerung ist sehr ähnlich wie beim nRF24L01+, nur Enhanced Shockburst 
fehlt. Bin gerade ma Überlegen ob ich damit etwas experimentiere. 
Irgendwie ist mir die Firma auch sympathischer als HopeRF.

Wo ich gerade das Datenblatt von HopeRF durchlese, stelle ich fest, dass 
es Unterstützung für AES-Verschlüsselung gibt. Klingt ja ganz 
interessant, aber anscheinend gibt's nur ECB als mode. Was für ein Witz. 
Warum machen die sich überhaupt die Arbeit so ein Feature einzubauen 
wenn es prinzipbedingt unbrauchbar ist?

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Huhu,
ich habe nur 2 Module, das sie defekt sind glaube ich nicht, zumindest 
haben sie bei den sonstigen Versuchen es geschaft die init zu 
durchlaufen ( arduino und Raspi) also beschreiben und zu lesen. Die Pins 
hab ich alle gegenseitig durchgeklingelt, da gab es auch keine brücke 
oder so. gespeist werden die Module und der Controller von meinem 
Netzteil, mit 3,3 Volt.Ich hatte mir bei Pollin extra die 868MHZ Module 
bestellt, aber wwenn ich das richtig verstehe,kann man die Module ja eh 
frei konfigurieren was die Frequenz angeht?!? Es sind sonst auch alle 
Pins angeschlossen(2xGND, MOSI,3,3V..) bis auf die DIOx da habe ich 
keinen in verwendung brauch ich ja auch nicht oder?
Ich muss dann mal das mit den beschreiben und auslesen versuchen , mal 
schauen ob es klappt.
Aber schonmal vielen dank für deine Antwort, ich weis das Ferndiagnosen 
so gut wie unmöglich sind.


Grüße

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Servus, ich nochmal
nur so als Frage Felix du hast den defines in der rfm69.h
#define SDIPORT        B
#define SDI        3
#define SDOPORT        B
#define SDO        4
es ist ja serial data Out & in vom Master oder? müsste man dann nicht 
die 3 und 4 tauschen? also beim ATmega328P ist B3-MOSI (SDO) und B4-MISO 
(SDI) ???

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Sauer schrieb:
> Ich hatte mir bei Pollin extra die 868MHZ Module
> bestellt, aber wwenn ich das richtig verstehe,kann man die Module ja eh
> frei konfigurieren was die Frequenz angeht?!?
konfigurieren schon - nur nützt dir das nichts. Die Anbindung / Filter 
der Antenne sind für den jeweiligen Frequenzbereich in Hardware 
"gegossen". Das geht vielleicht auf dem Tisch, aber nicht wenn du auch 
Strecke überbrücken willst.

Sascha

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Sauer schrieb:
> Servus, ich nochmal
> nur so als Frage Felix du hast den defines in der rfm69.h
> #define SDIPORT        B
> #define SDI        3
> #define SDOPORT        B
> #define SDO        4
> es ist ja serial data Out & in vom Master oder? müsste man dann nicht
> die 3 und 4 tauschen? also beim ATmega328P ist B3-MOSI (SDO) und B4-MISO
> (SDI) ???
Die Definitionen sind vom Funkmodul aus:

SDI ist Eingang am Funkmodul, dementsprechend Ausgang am Controller. SDO 
ist am Funkmodul Ausgang und am Controller Eingang.

von kleiner_meiner (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
so nun nochmal hoffe bin dieses mal besser auf gestellt :D.

hoffe man erkennt auf dem Bild alles. Ist dies soweit richtig?
EADER DATEI PIN BELEGUNG
//************************************************************************************
/* Carrierfrequenz in Hz */
#define FREQUENCY      433000000LL

/* Bitrate in bps (1200 ... 300000) and shall it be calculated as for RFM12
* in order to get equal bitrate for RFM12 and RFM69 if used together? */
#define BITRATE        9600L
#define RFM12COMP      1

/* Output power in dBm (-18...13) */
#define P_OUT_DBM      0      // Output power in dBm

/* Pin assignment */
#define NSELPORT      B
#define NSEL        0
#define SDIPORT        B
#define SDI          5
#define SDOPORT        B
#define SDO          6
#define SCKPORT        B
#define SCK          7
//*******************************************************************************

NSEL kann ja auf beliebigen Port gesetzt werden.
int main(void)
{
  char sensor[MAX_ARRAYSIZE + 1]; // gemessene Werte der Sensoren ins Array speichern
  uint8_t rx_length = 0, tx_length = 0;


  adc_init();  //ADW initalisieren
  rfm_init();   //Funkmodul initalisieren    

  while (1){

    sensor[0] = ds1820_read_temperatur();
    sensor[1] = HIH_4010_001_read_lufteuchtigkeit(1, 8);
    sensor[2] = MPX_4115A_read_luftdruck(2, 8);



    rfm_transmit(sensor, tx_length);

    //______________________________________________________

    if (rfm_receiving())
      rfm_receive(sensor, &rx_length);


  }

und ansonsten haben wir das bis jetzt so programmiert und sind der 
meinung das Funkmodul irgendwas senden sollte. Leider wie gesagt nix 
gemessen. Würden uns über hilfe sehr freuen, da es sich um ein 
Schulprojekt handelt :).

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
In Skizze hast SCK und NSEL vertauscht.

Bitte ganzen Code posten (einfach als Datei .c und .h), wir haben keine 
Ahnung, was hinter
  rfm_init();   //Funkmodul initalisieren    

  rfm_transmit(sensor, tx_length);

    //______________________________________________________

  if (rfm_receiving())
      rfm_receive(sensor, &rx_length);

steckt.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Die Anweisung
tx_length = 3;
   fehlt noch...

: Bearbeitet durch User
von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Felix Pflaum schrieb:
> Die Anweisung
tx_length = 3;
   fehlt noch...

Stimmt!!!

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich glaube du hast auch in der Zeichnung SDI und SDO vertauscht, aber im 
Code, sollte es dann eventuell stimmen, zumindest, wenn ich es richtig 
verstanden habe was Felix mir weiter oben auf meine Frage zu SDI und SDO 
geantwortet hat.

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achso, und ich weis nicht ob  10k etwas zu groß gewählt ist , immerhin 
hast du dann maximal 0,5mA aber da bin ich mir nicht sicher.

von Christian W. (kortix)


Bewertung
0 lesenswert
nicht lesenswert
Im Code von Felix funktioniert Software SPI nicht. So funktioniert es:

  for (uint8_t i = 8; i; i--) {
    SCK_PORT &= ~(1 << SCK);
    if (spibyte & 0x80) {
      SDI_PORT |= (1 << SDI);
    }
    else {
      SDI_PORT &= ~(1 << SDI);
    }
    spibyte <<= 1;
    SCK_PORT |= (1 << SCK);
    if (SDO_PIN & (1 << SDO)) spibyte |= (1<<0);
  }
  SCK_PORT &= ~(1 << SCK);


Ich habe jedoch Probleme mit der Reichweite. 868Mhz-Modul, 8,3cm 
Drahtantenne. Nach ein paar Metern ist Schluss, auch bei 13dbm. Dipol 
(2. Draht von Masse aus) bringt etwas, aber mehr als 4 Meter sind nicht 
drin.

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Servus

bestellt ihr die Funkmodule eigentlich alle bei Pollin oder gibt es noch 
einen anderen vertrauenswürdigen Anbieter, von mir aus auch in CHina 
oder so

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Sauer schrieb:
> Servus
>
> bestellt ihr die Funkmodule eigentlich alle bei Pollin oder gibt es noch
> einen anderen vertrauenswürdigen Anbieter, von mir aus auch in CHina
> oder so

Octamex, empfehlenswert:
http://www.octamex.de/shop/?page=shop/flypage&product_id=8327&category_id=44963f0fdda6ad2bdf98e07a9177fc9b&/RFM69CW-868-S2_Funkmodul

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Christian W. schrieb:
> Im Code von Felix funktioniert Software SPI nicht.

Kannst du mir dazu detailliertere Infos geben (verwendeter Controller, 
Taktfrequenz)?

In meinen Projekten funktioniert die Soft-SPI jeweils ohne Probleme, 
kann aber natürlich sein, dass es irgendwelche Spezialfälle gibt, auf 
die ich bisher nicht gestoßen bin. Wenn ich mein Steckbrett mal wieder 
zur Hand habe, würde ich dann mal beide Varianten laufen lassen und mit 
dem Logic Analyzer das Ergebnis überprüfen.

Bezugsquelle aus China:
http://www.aliexpress.com/item/RFM69CW-13dBm-transceiver-module-pin-to-pin-compatible-to-RFM12B-433-868-915mhz-can-be-selected/2010762457.html

: Bearbeitet durch User
von Kleiner_Meiner (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallo zusammen,

ich wollte nochmal nachtragend alle programme hochladen. Und zum Thema 
SDI und SDO noch was gefragt haben. Habe noch einwenig drüberinformiert 
und festgestellt das dies doch die " alten" bezeichnungen für MISO und 
MOSI sind aber leider auch anders beschaltet werden müssen.

Funkmodul     --->      Mikrocontroller

SDO                         SDI


Mirkrocontroller   <----    Funkmodul

SDI                          SDO

Bedeuten ja sowas wie Serial DATA Input und Serial DATA output.

Danke für die bisherige unterstützung :) .

von Christian W. (kortix)


Bewertung
0 lesenswert
nicht lesenswert
Felix Pflaum schrieb:
> Christian W. schrieb:
>> Im Code von Felix funktioniert Software SPI nicht.
>
> Kannst du mir dazu detailliertere Infos geben (verwendeter Controller,
> Taktfrequenz)?
>
> In meinen Projekten funktioniert die Soft-SPI jeweils ohne Probleme,
> kann aber natürlich sein, dass es irgendwelche Spezialfälle gibt, auf
> die ich bisher nicht gestoßen bin. Wenn ich mein Steckbrett mal wieder
> zur Hand habe, würde ich dann mal beide Varianten laufen lassen und mit
> dem Logic Analyzer das Ergebnis überprüfen.
>
> Bezugsquelle aus China:
> 
http://www.aliexpress.com/item/RFM69CW-13dBm-transceiver-module-pin-to-pin-compatible-to-RFM12B-433-868-915mhz-can-be-selected/2010762457.html

Ich verwende ATMega8 mit internem RC-Oszillator 1 MHz.

Was verwendest Du als Antenne? Ich schaffe nicht mehr als ca 4 Meter. 
Änderungen der Sendeleistung bringen nicht viel. (die 20db habe ich 
allerdings noch nicht probiert)
Mein Modul ist RFM69HCW 868Mhz. Ich habe probiert 8,6cm Kabel am 
Antennenausgang, sowie Dipol (direkt am Modul 8,6cm An Antennenanschluss 
sowie Masse) probiert.

: Bearbeitet durch User
von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Versorgungsspannung an den Modulen bzw. am Empfänger zu unsauber?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Christian W. schrieb:
> Ich verwende ATMega8 mit internem RC-Oszillator 1 MHz.

Kann gut sein, dass es beim ATmega8 noch nicht möglich ist, Pins per 
Schreibzugriff aufs  PINx-Register zu togglen. Das würde erklären, warum 
mein Code bei dir nicht läuft.

Als Antenne verwende ich einen Selbstbau, ist hier beschrieben - letzter 
Post: Beitrag "Sperrtopfantenne für RFM12"
Reichweite > 100m ohne große Hindernisse.

von Christian W. (kortix)


Bewertung
0 lesenswert
nicht lesenswert
> Kann gut sein, dass es beim ATmega8 noch nicht möglich ist, Pins per
> Schreibzugriff aufs  PINx-Register zu togglen.

Ist es auch nicht. Die Pins können über PINx nur gelesen werden. Ich 
dachte schon der Schreibzugriff auf PINx wäre ein Fehler.

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Servus,
ich hätte mal wieder eine Frage, ich habe jetzt raus bekommen das ich 
die Register 0x07 und 0x08 nicht beschreiben kann. Das sind die Register 
für das MSB und MID- Bit für die Carrier Frequency. Das LSB also 0x09 
kann ich beschreiben. Hatte das problem schonmal jemand. Das komische, 
ich kann bei beiden Modulen die ich habe diese Regsiter nicht 
beschreiben. Die anderen Register waren kein Problem , aber deswegen 
komme ich nichtmal durch die init.????

bester Grüße

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Wann hast du den Inhalt von 0x07 und 0x08 geprüft?

Im Datenblatt auf Seite 17 findet sich folgender Hinweis:
"The Frf setting is split across 3 bytes. A change in the center 
frequency will only be taken into account when the least significant 
byte FrfLsb in RegFrfLsb is written."

Also zunächst alle drei Register beschreiben und dann die Inhalte 
zurücklesen; erst wenn dann immer noch falsche Werte in 0x07 und 0x08 
stehen, ist es wirklich ein Problem.

von Sauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ahh Super !!!
Du bist genial !!!

deswegen hat es nur funktioniert als ich 0x09 (also LSB) beschrieben und 
direkt wieder ausgelesen habe.
Ich habe im Grunde dein Code genommen und kleine Veränderungen 
vorgenommen.
So schreibe ich zB meistens ein register und lese gleich zurück ob auch 
das richtige drinnen ist ;-)
Ich war schon kurz davor dem Hersteller zu schreiben.
Nach 2 Monaten werden die Dinger doch auch irgenwann endlich mal bei mir 
funktionieren...

Dank dir nochmal vielmals
Grüße

von kleiner_meiner (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

stehe derzeitig voll auf dem Schlauch...
haben heute den SPI bus mit hilfe eines speichersozilloskops aufgenommen 
und unser Meinung nach klappt das auch sieht zumindest so aus wie wir 
uns das vorstellen. Lade aber noch Bilder mit noch. Doch leider sehen 
wir bei unserem Spektrum-Anaysator immer noch keine veränderung. Dazu 
muss geesagt werden das SPI-Signal kommt sehr unregelmäßig.

Daher versuch ichs nochmal:

  int main(void)
  {
    char sensor[MAX_ARRAYSIZE + 1];
    uint8_t rx_length = 0, tx_length = 3;


    adc_init();  //ADW initalisieren
    rfm_init(); //Funkmodul initalisieren    

    while (1){

      sensor[0] = ds1820_read_temperatur();
      sensor[1] = HIH_4010_001_read_lufteuchtigkeit(1, 8);
      sensor[2] = MPX_4115A_read_luftdruck(2, 8);

      rfm_transmit(sensor, tx_length);


      /*if(rfm_receiving())
      rfm_receive(sensor, &rx_length);     */

      

    }
    return (0);
  }


Im Anschluss schicke ich noch die angepasste Header-Datei wo wir die 
SPI-HARDWARE aber noch seperat angepasst haben.
#ifndef RFM69_H_
#define RFM69_H_

/* Carrierfrequenz in Hz */
#define FREQUENCY      433000000LL

/* Bitrate in bps (1200 ... 300000) and shall it be calculated as for RFM12
 * in order to get equal bitrate for RFM12 and RFM69 if used together? */
#define BITRATE        9600L
#define RFM12COMP      1

/* Output power in dBm (-18...13) */
#define P_OUT_DBM      0      // Output power in dBm

/* Pin assignment */
#define NSELPORT      B
#define NSEL        0
#define SDIPORT        B
#define SDI          5
#define SDOPORT        B
#define SDO          6
#define SCKPORT        B
#define SCK          7

/* Use Hardware-SPI if available? */
#define USE_HARDWARE_SPI  0


die anderen header-file schicke ich nicht mit da in diesen files ja nix 
geändert werden muss. Ansonsten hoffe ich auf nachsicht da es sich hier 
bei ja wie oben erwähnt um ein schulprojekt handelt.
liebe grüße ansonsten :)

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist, ob ihr mit diesem Spektrumanalysator und diesen 
Einstellungen überhaupt irgendetwas zu sehen bekommt.

Ein Sendevorgang dauert mit drei Präambelbytes, zwei Bytes 
Schlüsselwort, Längenbyte, drei Datenbytes und zwei Bytes CRC, was 
insgesamt 11 Bytes, also 88 Bits, bedeutet, nicht einmal 10 ms. Die 
Sweep Rate eines HM 5005/5006 beträgt 43 Hz, so dass der Scanner bei den 
Frequenzen für 0 und 1 (45 kHz oberhalb und unterhalb von 433,0 MHz) 
gerade mal alle 23 ms "vorbeikommt". Und selbst wenn ihr das mal 
zufällig genau erwischen solltet, wird es ziemlich schnell wieder vom 
Bildschirm verschwunden sein.

Was man tun kann:
Euer Frequenzbereich ist mit 50 MHz (5 MHz/div) viel zu groß gewählt, 
stellt ihn auf 0,1 MHz/div. Auch bei dieser Einstellung ist dann links 
und rechts noch mehr als genug Platz, da sich alles innerhalb einer 
Division um die Mitte (433,0 MHz) herum abspielen sollte.

Verlängert die Sendedauer und schickt über einen langen Zeitraum nur 0 
oder 1, also 0x00 oder 0xFF. Wenn man 60 Bytes schickt (dazu muss 
MAX_ARRAYSIZE angepasst werden und tx_length entsprechend geändert), 
dauert das 50ms, der Spektrumanalysator wird also während des Sendens 
mindestens zweimal die entsprechende Frequenz abscannen.

Auch die Bitrate kann zu Testzwecken noch verkleinert werden, mit 1200 
Bits/s würde man noch einmal an Beobachtungszeit gewinnen.

Ansonsten bietet euer Gerät auch noch die Möglichkeit eines Zero-Scans, 
also eines Voltmeters bei einer bestimmten Frequenz. Das könnte man auch 
mal bemühen, wenn man mit den vorher beschriebenen Änderungen nichts 
sieht.

von fuubaah (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich muss mich hier mal kurz einklicken.
Woher kommt der Wert "0x80" für die SPI Mask?
Ich kann im Datenblatt nichts dazu finden...

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
fuubaah schrieb:
> Hallo,
>
> ich muss mich hier mal kurz einklicken.
> Woher kommt der Wert "0x80" für die SPI Mask?
> Ich kann im Datenblatt nichts dazu finden...

Die 0x80 entspricht als Binärwert b10000000. Man überprüft durch die 
Abfrage immer, ob das MSB von spibyte gesetzt ist oder nicht, und 
setzt dementsprechend den uC-Ausgang high oder low, bevor man durch die 
steigende Clock-Flanke den Wert "einloggt". Anschließend schiebt man die 
Bits von spibyte um 1 nach links, so dass Bit 7 herausfällt, Bit 6 das 
MSB wird, dann Bit 5, usw. Man überträgt so die 8 Bit von spibyte im 
Modus MSB-first, wie es das Datenblatt auf Seite 44 beschreibt.

Würde man LSB-first übertragen, wäre die Maske 0x01 und man würde nach 
rechts schieben.

: Bearbeitet durch User
von Kleiner_Meiner (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hiho,

erstmal vielen dank Felix. Hat super geklappt mit deinen Tips. Denke 
zumindest das es das ist ;).

Daraufhin versuchten wir direkt das gesendete zu empfangen und 
auszuwerten. Das erwiess sich aber ebenfalls nicht ganz so einfach wie 
gedacht. Hättest du dort eventl auch Tips für uns wie wir das am besten 
angehen. Freue mich schon auf eine antwort.

liebe grüße und nochmal vielen dank für die großartige unterstützung.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Die Basis zum Tipps geben ist recht breit, ein paar mehr Infos 
deinerseits wären nicht schlecht:

Ihr habt jetzt zwei 433-MHz-RFM69, die miteinander reden sollen? Welcher 
Abstand ist zwischen den Modulen? Sind geeignete und zur Frequenz 
passende Antennen verbaut? Sind beide Funkmodule auf identische Weise 
initialisiert, so dass Bitrate, Mittenfrequenz, Frequenzhub und 
Empfängerbandbreite übereinstimmen bzw. zusammenpassen? Wird 
sichergestellt, dass immer nur einer sendet und der andere währenddessen 
zuhört? Wie kontrolliert ihr, ob etwas empfangen wurde und wenn ja, was 
empfangen wurde?

von Lukas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie funktioniert die Anbindung der Antenne? Muss beim Layout noch etwas 
beachten? Wie sieht es mit dem Abgleichen aus?
Danke für die Infos

von Kleiner_Meiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
guten abend,

Felix Pflaum schrieb:
> Ihr habt jetzt zwei 433-MHz-RFM69, die miteinander reden sollen?
Nicht ganz wir möchten gerne Daten von einem Modul zum anderen schicken. 
Dabei soll ein Modul nur empfangen und die gewonnen Daten an einem LCD 
ausgeben.

Felix Pflaum schrieb:
> Welcher
> Abstand ist zwischen den Modulen?

Derzeitig nicht viel max 1 meter später sollen es ca 5-6meter werden.

Felix Pflaum schrieb:
> Sind geeignete und zur Frequenz
> passende Antennen verbaut?

Haben dazu unseren Lehrer befragt und haben daraufhin 833Mhz. Dazu die 
Faustformel Lichtgeschwindigkeit / Frequenz benutzt. Und davon LAMBDA 
viertel. Dabei kamen wir auf eine antennen länge von ca 9cm.

Felix Pflaum schrieb:
> Sind beide Funkmodule auf identische Weise
> initialisiert, so dass Bitrate, Mittenfrequenz, Frequenzhub und
> Empfängerbandbreite übereinstimmen bzw. zusammenpassen?

wir rufen bei beiden die von der lib verwendeten rfm_ini auf.Bitrate 
haben wir bissel mit rumgespielt wie du oben geschrieben hattest haben 
nur immer bei beiden die gleiche Zahl reingeschrieben. Mit Frequenzhub 
welches die höhsten und tiefsten Signalwerte sind???

Sender:
wollen halt wie unten abgebildet die Werte die vom Sensor kommen 
rüberschicken und dort verarbeiten.
rfm_init(); //Funkmodul initalisieren    

    while (1){

      sensor[0] = ds1820_read_temperatur();
      sensor[1] = HIH_4010_001_read_lufteuchtigkeit(1, 8);
      sensor[2] = MPX_4115A_read_luftdruck(2, 8);

      rfm_transmit(sensor, tx_length);


Empfänger:

beim Empfänger dachte ich halt genau anders herum.
  while (1){
                       rfm_receive(sensor, tx_length);
      
                        zwischenwert1 = sensor[0];
            zwischenwert2 = sensor[1] ;
      zwischenwert3 = sensor[2] ;


Felix Pflaum schrieb:
> Wird
> sichergestellt, dass immer nur einer sendet und der andere währenddessen
> zuhört
wie oben erwähnt haben wir nur ein Sender und Empfänger.

Felix Pflaum schrieb:
> Wie kontrolliert ihr, ob etwas empfangen wurde und wenn ja, was
> empfangen wurde?

der zeitig kontrollieren wir nicht ob etwas empfangen wurde, da wir 
nicht mal wissen ob wir was empfangen. Wir wissen nur das ein modul 
sendet.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Kleiner_Meiner schrieb:
>> Sind geeignete und zur Frequenz
>> passende Antennen verbaut?
>
> Haben dazu unseren Lehrer befragt und haben daraufhin 833Mhz. Dazu die
> Faustformel Lichtgeschwindigkeit / Frequenz benutzt. Und davon LAMBDA
> viertel. Dabei kamen wir auf eine antennen länge von ca 9cm.
833 MHz? Das Modul initialisiert ihr mit 433 MHz, dort seht ihr auch 
euren Peak im Spektrum. Tippfehler? lambda/4 bei 433 MHz sind 17,3cm. 
Das wäre also auch die nötige Antennenlänge für ein Stück Draht.

> der zeitig kontrollieren wir nicht ob etwas empfangen wurde, da wir
> nicht mal wissen ob wir was empfangen. Wir wissen nur das ein modul
> sendet.
Und wie wollt ihr erfahren, ob ihr was empfangen habt, wenn ihr nicht 
nachschaut? Das Modul teilt das nur auf Nachfrage mit, in solchen Dingen 
ist es eigen. ;-) Genaueres siehe unten!

Was ihr beim Sender im Programm stehen habt, ist so in Ordnung, auch 
wenn eine Wartezeit nach dem Senden sicher nicht verkehrt wäre. Man will 
ja nicht tausende Male pro Sekunde Daten schicken. Ein _delay_ms(5000) 
würde nicht schaden.

Der Empfänger wird so einfach nicht funktionieren, schon alleine, weil 
der Funktionsaufruf der receive-Funktion falsch ist (2. Argument muss 
ein Pointer auf uint8_t sein). Das wird euch der Compiler aber sicher 
gesagt haben, Fehlermeldungen und Warnungen?

Bevor man die receive-Funktion aufruft, muss außerdem geprüft werden, ob 
irgendwas empfangen wurde, dafür gibt es die Funktion rfm_receiving(), 
die 0 zurück gibt, wenn nichts empfangen wurde, sonst einen von 0 
verschiedenen Wert.

Also:
if(rfm_receiving()) {                 // Wenn Daten empfangen wurden:
   rfm_receive(sensor, &rx_length);   // Daten aus FIFO holen
                                      // und
   zwischenwert1 = sensor[0];         // Sensordaten
   zwischenwert2 = sensor[1];         // in andere
   zwischenwert3 = sensor[2];         // Variablen speichern
}

von kleiner_meiner (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hiho, ich bins mal wieder

erstmal sry hatte was anderes im Kopf 868 meinte aber 433 Mhz. Aber 
danke für die Rechnung :).

Wir haben jetzt gerade alles so eingestellt und bekommen an unserem LCD 
nur einen wert von 255 angezeigt. Kann das mit der Funktion zutun haben.
rfm_spi(wnr ? data[0] : 0xFF);

Gleichzeitig lassen wir uns auch rfm_receiving() anzeigen und dort 
bekommen wir immer eine 1 angezeigt, daher vermuten wir das er 
aufjedenfall was empfangen hat.
Danach haben wir nochmal mit unserem Speicheroszilloskop den Spi-bus 
gemessen und wir bekommen dort ebenfalls was angezeigt. Siehe Bild. Sind 
aber der meinung das die daten eine zu kleine spannung haben um erkannt 
zu werden.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
kleiner_meiner schrieb:
> Wir haben jetzt gerade alles so eingestellt und bekommen an unserem LCD
> nur einen wert von 255 angezeigt. Kann das mit der Funktion zutun haben.
>
>
> rfm_spi(wnr ? data[0] : 0xFF);
> 
Nein, mit dem Rückgabewert der Funktion hat das nichts zu tun. Das 
bedeutet lediglich, dass der Controller im Falle eines Schreibzugriffs 
(wnr != 0) das Byte data[0] an das Funkmodul schicken soll, im Fall 
eines Lesezugriffs (wnr == 0) einfach 0xFF. Dem Funkmodul ist egal, was 
bei einem Lesezugriff an seinem SDI-Eingang anliegt, während es am 
SDO-Ausgang die Daten an den Controller schickt.

> Gleichzeitig lassen wir uns auch rfm_receiving() anzeigen und dort
> bekommen wir immer eine 1 angezeigt, daher vermuten wir das er
> aufjedenfall was empfangen hat.
Diese Vermutung könnte falsch sein ;-). Da der Pullup-Widerstand im 
Controller am Dateneingang aktiv ist, wird das PayloadReady-Bit auch 1, 
wenn die Leitung hochohmig ist. Ersetzt mal die Funktion rfm_receiving() 
durch folgende:
uint8_t rfm_receiving(void) {
  uint8_t status;
  ACTIVATE_RFM;
  status = rfm_cmd(0x28FF, 0);
  DEACTIVATE_RFM;
  // Check if PayloadReady is set AND unused bit is not set (if bit 0 is set, module is not plugged in or communication fails)
  return ((status & (1<<2)) && !(status & (1<<0)));
}
Damit wird jetzt nicht nur das PayloadReady-Bit geprüft, sondern auch 
das Bit 0 im Register 0x28, welches lt. Datenblatt immer 0 sein muss. 
Die Funktion gibt dann nur 1 zurück, wenn PayloadReady gesetzt und Bit 0 
ungesetzt ist.

> Danach haben wir nochmal mit unserem Speicheroszilloskop den Spi-bus
> gemessen und wir bekommen dort ebenfalls was angezeigt. Siehe Bild. Sind
> aber der meinung das die daten eine zu kleine spannung haben um erkannt
> zu werden.
Was ich mich vor allem frage, wenn ich mir die violette NSEL blaue 
CLK-Kurve anschaue: Ihr versorgt das Modul nicht ernsthaft mit 5V? Es 
ist für 1,8V - 3,6V spezifiziert (typischerweise wird man 3,3 V 
verwenden). 5V gehen auf gar keinen Fall. Oder habt ihr Widerstände in 
den Ansteuerleitungen und messt mit dem Oszi auf der Seite des 
Controllers?

: Bearbeitet durch User
von Kleiner_Meiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
erstmal frohes neues,
nein wir messen am mc ^^. Wir benutzen einen Spannungsteiler um die 
spi-ports runter zu bekommen. Aber wir haben jetzt eher ein anderes 
problem unser display hört auf zu schreiben sobald wir den SCL ans das 
Funkmodul anschliessen hört das display sofort auf zu arbeiten. Und das 
finden wir sehr merkwürdig. Aber denke das gehört hier nicht zu.

Wollte mich eigentlich nur vergewissern das man zum runterregeln der 5 V 
ruhig ein spannungsteiler benutzen kann.

von Ulli (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich brauch unbedingt euren Rat.
Ich habe einen funktionierenden Sketch auf einem ATMEGA328p @16MHz.
Diesen Sketch habe ich jetzt auf einem ATMEGA328p @8MHz (internal 
clock).

Wenn ich nun Nachrichten von dem 16MHz auf den 8MHz senden funktionert 
es.
Andersherum von dem 8MHz azf den 16MHz kommst aber nie was an.

Habt Ihr eine Idee woran das liegen kann? Ich bin am verzweifeln!!!

von kleiner_meiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hiho, ich nochmal habe ne andere Frage da wir zum verrecken einfach 
keine übertrageung hinbekommen. Wie lange darf die rfm_ini dauern. weil 
ich habe beim empfänger folgenden c code:

die normale ini funktion aus der lib.
// Initialise RFM
void rfm_init(void) {
  uint32_t utimer;
  utimer = TIMEOUTVAL;

  // Configure SPI inputs and outputs
  NSEL_PORT|= (1 << NSEL);
  SDO_PORT|= (1<<SDO);
  SDO_DDR &= ~(1 << SDO);
  SDI_DDR |= (1 << SDI);
  SCK_DDR |= (1 << SCK);
  NSEL_DDR|= (1 << NSEL);

#ifdef SPCR
#if HARDWARE_SPI
  // Activate and configure hardware SPI at F_CPU/4
  SPCR |= (1 << SPE | 1 << MSTR);
#endif
#endif

  for (uint8_t i = 0; i < 20; i++) {
    _delay_ms(5);
    
    rfm_cmd(0x0200, 1); // FSK, Packet mode, No shaping

    //Bitrate + corresponding settings (Receiver bandwidth, frequency deviation)
    rfm_setbit(BITRATE);
    

    rfm_cmd(0x131B, 1);           // OCP enabled, 100mA

    // DIO-Mapping
    rfm_cmd(0x2500, 1);           // Clkout, FifoFull, FifoNotEmpty, FifoLevel, PacketSent/CrcOk
    rfm_cmd(0x2607, 1);           // Clock-Out off

    // Carrier frequency
    rfm_cmd(0x0700 + FRF_MSB, 1);
    rfm_cmd(0x0800 + FRF_MID, 1);
    rfm_cmd(0x0900 + FRF_LSB, 1);

    // Packet config
    rfm_cmd(0x3790, 1);           // Variable length, No DC-free encoding/decoding, CRC-Check, No Address filter
    rfm_cmd(0x3800 + MAX_ARRAYSIZE, 1);   // Max. Payload-Length
    rfm_cmd(0x3C80, 1);           // Tx-Start-Condition: FIFO not empty
    rfm_cmd(0x3D12, 1);           // Packet-Config2

    // Präambel length 3 bytes
    rfm_cmd(0x2C00, 1);
    rfm_cmd(0x2D03, 1);

    // Sync-Mode
    rfm_cmd(0x2E88, 1);           // set FIFO mode
    rfm_cmd(0x2F2D, 1);           // sync word MSB
    rfm_cmd(0x30D4, 1);           // sync word LSB

    // Receiver config
    rfm_cmd(0x1800, 1);           // LNA: 50 Ohm Input Impedance, Automatic Gain Control
    rfm_cmd(0x582D, 1);           // High sensitivity mode
    rfm_cmd(0x6F30, 1);           // Improved DAGC
    rfm_cmd(0x29DC, 1);           // RSSI mind. -110 dBm
    rfm_cmd(0x1E2D, 1);           // Start AFC, Auto-On
    while (!(rfm_cmd(0x1EFF, 0) & (1 << 4)))
      ;
      variable_ausgeben(i, 10,10);
      

    rfm_cmd(0x1180 + P_OUT, 1);       // Set Output Power
    int u = 20;
      variable_ausgeben(u, 20,20);
  }
  rfm_cmd(0x0A80, 1);             // Start RC-Oscillator
  while (!(rfm_cmd(0x0A00, 0) & (1 << 6)) && --utimer)
    ;   
    int o = 21;
    variable_ausgeben(o, 30,30);                  // Wait for RC-Oscillator

  rfm_rxon();
}

und bis ich eine variable herausbekommen habe an meinem display dauert 
es je nachdem bis zu 5-10 min. Ist das normal ich denke eher nicht meine 
frage ist daher was hab ich falsch gemacht. Muss ich evnetl eine 
bestimmte cpu frequenz haben. Habe derzeitig die standart 1MHZ drin. spi 
bus funkt habe auch daten gemessen. siehe oberen beitrag.

ansonsten ist dies unser quell test vom sender :
int main(void)
{  
   char sensor[MAX_ARRAYSIZE+1]; // gemessene Werte der Sensoren ins Array speichern
   uint8_t rx_length=0, tx_length=3;
   
  
   adc_init();
   lcd_prototyp();  //ADW initalisieren
   rfm_init();   //Funkmodul initalisieren    
   
   while( 1 ){
    
       sensor[0]=5;
       sensor[1]=3;
       sensor[2]=2;
       
     /* if(rfm_receiving()) {
        
        rfm_receive(sensor, &rx_length);
        tx_length = rx_length;
        rfm_transmit(sensor, tx_length);
      }*/
    
     rfm_transmit(sensor, tx_length);
     
    //______________________________________________________
    
    /*if(rfm_receiving()) 
      rfm_receive(sensor, &rx_length);     */
    _delay_ms(5000);
    lcd_prototyp();
     }
   return (0); 

und beim empfänger habe ich folgenden text bei RFM69.H files wurden 
angepasst und verglichen so das in beiden das selbe steht.


int main (void)
{  ks0108Init(0);
  //set_RTC();
  rfm_init();
  //adc_init();
  //lol=(int)PT100(7,8,100);
  /*while(1){
    
    read_RTC();
*/
while (1)
{
  int ausgabe = 124;
  variable_ausgeben(ausgabe,40,40);
  /*if (rfm_receiving())
  {rfm_receive(sensor,&rx_lenght);
    
    zwischenwert1 = sensor[0];
    zwischenwert2 = sensor[1];
    zwischenwert3 = sensor[2];
    variable_ausgeben(rfm_receiving(),30,30);
    variable_ausgeben(zwischenwert2,20,20);
    variable_ausgeben(zwischenwert3,10,10);
  }
  */
}
Die receiving habe ich erstmal raus genommen um mir die varibalen 
anzeigen zu lassen leider sehe ich nicht mal die 124 am display. Die 
funktion so alleine funktioniert immer...
daher wäre es nett wenn jemand nochmal drüber gucken könnte bin langsam 
am verzweifeln : / . Und wer ne idee oder  mir ein denkanstoß geben 
könnte.

vielen danke schonmal :D

von kleiner_meiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ich nochmal update zum obrigen eintrag,

durch das verschiedene anzeigen lassen wo ich bin konnte ich verstellen 
das nach der
while (!(rfm_cmd(0x1EFF, 0) & (1 << 4)))
      ;

feststecke. Da mein Display heute morgen nur bis 10 gezählt hat. Lustige 
daran war als ich miso abgeklemmt hatte arbeite das display normal 
weiter und beendete auch die  rfm_ini. Jetzt habe ich bemerkt das miso 
nur auf 2,5v kommt. Benutze aber die gleichen widerstände im 
spannungsteiler(20k zu 10k) wie bei den anderen Eingänge wie mosi und 
nss und sck. daher vermute ich das der spannungspegel viel zugering ist 
um vom mc als high erkannt zu werden. da dieser auf 5 V arbeitet.

könnte diese vermutung richtig sein oder hab ich wieder was übersehen.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
kleiner_meiner schrieb:
> Jetzt habe ich bemerkt das miso
> nur auf 2,5v kommt. Benutze aber die gleichen widerstände im
> spannungsteiler(20k zu 10k) wie bei den anderen Eingänge wie mosi und
> nss und sck. daher vermute ich das der spannungspegel viel zugering ist
> um vom mc als high erkannt zu werden. da dieser auf 5 V arbeitet.
>
> könnte diese vermutung richtig sein oder hab ich wieder was übersehen.
Die Vermutung wird wohl richtig sein, da der Controller mindestens 60% 
seiner Versorgungsspannung als High-Pegel an seinem Eingang sehen will.

MISO (Master In, Slave Out) ist ein Ausgang des Funkmoduls und wird nie 
mehr Spannung liefern können als die Versorgungsspannung des Funkmoduls. 
Wenn du diese Spannung dann auch noch mit einem Spannungsteiler 
verringerst, kommt folglich noch weniger heraus.

Du könntest versuchen, den Spannungsteiler in der MISO-Leitung 
wegzulassen und zum Schutz des Funkmoduls vor hohen Strömen einfach 
zwischen Controller und Modul in die Leitung einen Widerstand mit 
einigen kOhm (z.B. 2,2kOhm) zu hängen.

Aus solchen Gründen bin ich kein großer Freund davon, Controller und 
Peripherie mit unterschiedlichen Pegeln zu betreiben, wenn es sich 
irgendwie vermeiden lässt.

von kleiner_meiner (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ahhh gut hab ich gemacht. Trotzdem habe ich immer noch das verhalten das 
die ini erst beendet wird wenn ich miso einmal rausziehe und wieder 
reinstecke.

Code vom Empfänger.
while (1)
{
  
  variable_ausgeben(rfm_receiving(),50,50);
  for (i = 0 ; i <100; i++)
  {
    if (rfm_receiving())
    {rfm_receive(sensor,&rx_lenght);
      
      zwischenwert1 = sensor[0];
      zwischenwert2 = sensor[1];
      zwischenwert3 = sensor[2];
      variable_ausgeben(rfm_receiving(),30,30);
      variable_ausgeben(zwischenwert2,20,20);
      variable_ausgeben(zwischenwert3,10,10);
    }
    
  }
  
}  

Dazu habe ich einmal die datenleitung auf genommen Mosi und Miso und da 
sehe ich auch das Daten übertragen werden was erstmal ja gut ist selbst 
beim nix empfangen wir ja mit geteilt habe nix bekommen aka 0 bei der 
rfm_reciving.
Aber es ist doch richtig das Miso ---> an PortB.7 aka Miso kommt.
Und Mosi kommt an ---> PortB.6 aka Mosi.
Sck kommt wie auch sonst an SCK.

Nochmal unseren Code vom Sender

 while( 1 ){
    
       sensor[0]=5;
       sensor[1]=3;
       sensor[2]=2;
       
     /* if(rfm_receiving()) {
        
        rfm_receive(sensor, &rx_length);
        tx_length = rx_length;
        rfm_transmit(sensor, tx_length);
    
    _delay_ms(5000);
    lcd_setcursor( 0, 2 );
    lcd_data( '5' );
    lcd_data( '3' );
    lcd_data( '2' );
    
     }
   return (0);
}
Das lustige ist jetzt messe ich beim Sender bei Miso oder Mosi garkeine 
übertragung mehr Sie dazu SPI_S_04__1_.PNG und  SPI_S_04__2. Hatte 
leider noch nciht die gelegenheit den Spektrumanaysator dran zuhalten. 
Aber das wollte ich noch tun.
Ne andere sache da du wie oben beschrieben sagt Miso ist ein ausgang vom 
funkmodul ist dieser doch dann beim senden eher 2.ranig oder nicht? weil 
wir beim sender halt wie oben auch noch die die spannungsteiler drin 
haben.

Desweiteren wollte ich mal fragen ob die MC Frequenz hier bei eine 
wichtige rolle spielt den wie benutzen nur die standart 1MHZ.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
kleiner_meiner schrieb:
> ahhh gut hab ich gemacht. Trotzdem habe ich immer noch das verhalten das
> die ini erst beendet wird wenn ich miso einmal rausziehe und wieder
> reinstecke.
Liegt wahrscheinlich daran, dass MISO permanent auf low ist und durch 
das Trennen der Leitung der Pullup den Pegel hochzieht. Du bekämpfst 
damit das Symptom, aber nicht die Ursache.

> Aber es ist doch richtig das Miso ---> an PortB.7 aka Miso kommt.
> Und Mosi kommt an ---> PortB.6 aka Mosi.
> Sck kommt wie auch sonst an SCK.
An welchem Port was angeschlossen ist, spielt keine Rolle. Wichtig ist, 
dass die Verbindungen korrekt in der rfm69.h angegeben sind. NSEL, SDI 
und SCK über Spannungsteiler, SDO wie beschrieben mit einem Widerstand 
in der Leitung.

> Ne andere sache da du wie oben beschrieben sagt Miso ist ein ausgang vom
> funkmodul ist dieser doch dann beim senden eher 2.ranig oder nicht? weil
> wir beim sender halt wie oben auch noch die die spannungsteiler drin
> haben.
Doch, du brauchst den SDO, weil du vor dem Senden den Status des Moduls 
abfragst und wissen willst, ob alles bereit zum Senden ist.

> Desweiteren wollte ich mal fragen ob die MC Frequenz hier bei eine
> wichtige rolle spielt den wie benutzen nur die standart 1MHZ.
Reicht zum Senden mit 9600 Bits/s locker aus.

von ich_der_Bastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
kleiner_meiner schrieb:
> Jetzt habe ich bemerkt das miso nur auf 2,5v kommt. Benutze aber die
> gleichen widerstände im spannungsteiler(20k zu 10k) wie bei den anderen
> Eingänge wie mosi und nss und sck.

Was heißt "wie bei den anderen Eingängen"?

Wenn du MOSI, SS und SCK als Eingänge bezeichnest, beziehst du dich 
offenbar auf den Slave. Beim Slave ist aber MISO ein Ausgang. Soweit 
aus deinen Posts zu entnehmen, betreibst du den Master mit 5V und den 
Slave mit 3V3 (mit vernünftigem Schaltplan wäre das einfacher). Was soll 
dann überhaupt der Unfug mit einem Spannungsteiler für das ohnehin schon 
knappe MISO Signal.

von kleiner_meiner (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hiho erstmal danke für die Geduld.

ich_der_Bastler schrieb:
> Was heißt "wie bei den anderen Eingängen"?

ich entschuldige meine blöde ausdrucksweise. Bin wie gesagt noch nicht 
so lange dabei. Daher eventl auch für mich euch mein problem gut 
zubeschreiben.

ich_der_Bastler schrieb:
> (mit vernünftigem Schaltplan wäre das einfacher).

jo, hast du aufjedenfall recht habe mich auch an die arbeit gemacht. 
lade ich auch hoch sry für mein gekritzel hoffe man erkennt alles 
ansonsten reiche ich nochmal einen ordentlichen Plan nach.

gleichzeitig habe ich habe ich es nun nach eurer starken 
Hilfestellung(neu(empfänger und Sender)) angeschlossen und ich bekomme 
auf dem speicheroziloskop beim Empfänger viel angezeigt kann dies leider 
nicht so richtig deuten. Ich habe mal ausschnitte mithochgeladen.
Ich dachte dort würde ich die Register aus der Ini bzw allgemein die 
Daten die übertragen werden sehen. Eventl ist noch zu sagen der Sender 
führt nach neuer beschaltung die Ini aus :). Auch dort habe ich versucht 
die Daten auszulesen aber wie oben erwähnt ist das für mich noch nicht 
ganz nachvollziehbar. Ich stelle zum sender auch nochmal teil 
ausschnitte vom speicherozilloskop hoch.

nochmals vielen dank für die geduld und die weiterhin gute Hilfestellung 
:)

grüß kleiner Meiner

von Georg (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich befasse mich auch seit einiger Zeit mit den RFM69HCW (868MHz) 
Modulen. Habe diese aber bis vor kurzem nicht zum laufen gebracht 
(drahtlose Kommunikation wollte einfach nicht)

Ich will über eine Entfernung von ~50-100 m per "Fernbedienung" etwas 
schalten.
Dazu habe ich mir eine kleine Platine mit dem Mega328P aufgebaut, auf 
der auch das HopeRF Modul aufgelötet ist.
Als Antenne verwende ich im Moment ein Stück Draht mit ~83-85mm Länge 
(868MHz).

Ich habe mich am Beispielcode von Felix orientiert (Vielen Dank schonmal 
hierfür), und wollte eine Funkverbindung aufbauen.

[Das hier nur nebenbei:]
Ich habe festgestellt, dass es bei mir nicht funktioniert, wie im Code 
von Felix, den FIFO vorher zu füllen, und dann in den Sendemodus zu 
schalten. Bei mir wird das Flag "Packet sent" nicht gesetzt. Ich schalte 
vorher in den TX-Mode und fülle gleich den FIFO um erfolgreich senden zu 
können. Dies ist aber nur als Tipp gedacht, falls jemand in die gleiche 
Situation kommt, und "packet sent" nicht gesetzt wird.
[/Das hier nur nebenbei:]

Mein Problem liegt viel mehr an der Reichweite.
Ich schaffe es mittlerweile zum Glück Daten zu Senden, und auch zu 
Empfangen, leider ist die Reichweite mit ~3-5m bei direkter 
Sichtverbindung mehr als dürftig.

Ich habe verschiedene Sendeleistungen ausprobiert (-10, 0 und +10 dBm 
mit PA0) und erhalte in jedem Fall etwa die gleiche Reichweite.

Hat irgend jemand eine Idee, an was das liegen kann? Da ich eine 
Drahtantenne verwende schätze/hoffe ich dass es nur an einem der 
Registerwerte/Der Konfiguration liegt.

Im Anhang sind meine "Registerwerte" kurz aufgeführt.
Bei anderer Bitrate (mit ändern von FDEV) und Empfängerbandbreite hab 
ich schon einiges experimentiert, war auch schon bei 1,2 kBit und 
schmalerer Filterbreite, aber hatte keine Verbesserung in der 
Reichweite.

Bei 1,2 kBit habe ich einen Frequenzfehler (FEI-Registerinhalt) von 
~3kHz bekommen. Ich weiß nicht, ob dieser Wert schon zu hoch ist.

Der RSSI Wert ist meines Erachtens immer sehr niedrig. Auch wenn ich 
beide Module direkt nebeneinander halte (Antennenabstand < 5cm), ist der 
RSSI maximal -70dBm.

Also jeder Hinweis ist Willkommen ich bin schon kurz vorm Verzweifeln.


Grüße,
Georg

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt Neuigkeiten:

Es funktioniert immer noch nicht, aber ich habe jetzt festgestellt, dass 
unabhängig welchen Wert ich ins RegPaLevel schreibe (Ausgangsleistung 
sowie Auswahl zwischen den Endstufen PA0,1 oder 2) ich bekomme beim 
zurücklesen des Werts immer 0x9F (Entspricht dem default = 13 dBm mit 
PA0).

Im Forum bei lowpowerlab (ich weiß nicht ob ich den Beitrag hier 
verlinken darf) ist auch ein Beitrag bei dem jemand schreibt, dass er 
beim Senden mit PA0 aktiv am Spektrum Analyser nichts sieht, nur wenn er 
auf PA1 umschaltet, sieht er was.
Deshalb wollte ich auch einmal auf einen anderen Verstärker umschalten, 
aber der Registerwert ist wie gesagt beim zurücklesen immer auf 
Standard.

Muss ich irgend etwas beachten, darf ich den Wert nur in einem 
bestimmten Zustand des Moduls ändern? Im Datenblatt habe ich nichts dazu 
gefunden.

Dass meine Register Lese/Schreibfunktion nicht funktioniert schließe ich 
fast aus, weil bei allen anderen bisher getesteten Registern klappts 
auch. Und die Adresse vom RegPaLevel habe ich auch auf 0x11 gesetzt...
Ich hab schon an zwei RFM69HCW getestet beide zeigen das gleiche 
Verhalten.

Hat jemand hier auch die Erfahrung gemacht, dass das Senden mit PA0 
nicht gut funktioniert??

von Michael N. (neumo)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich hänge mich hier mal rein. Ich verwende die RFM69CW Module und die 
Libraries von LowPowerLabs.

Ein Modul ist an einen Arduino Nano angeschlossen und fungiert als 
Gateway. Das ganze hängt via USB an einem Rechner.

Ein zweites Modul hängt an einem Arduino Pro Mini 328p @8MHz der auf 
3,3V läuft und als Node (Sensor) fungiert. Alle 3 Sekunden wird ein 
Datenpaket geschickt.

Das Gateway funktioniert unauffällig/wie erwartet.

Kurioses Problem ist, das der Node funktioniert, so lange er am FTDI 
hängt, dann empfängt das Gateway die Daten.
Läuft der Node mit 2 Mignon Batterien, dann kommt keine Nachricht mehr 
an.
Powere ich den den Node über den FTDI Adapter (Datenleitungen 
abgeklemmt) dann kommt ganz sporadisch mal eine Nachricht durch.

Ich hab probeweise mal den ganzen serial.* Kram raus geschmissen, hat 
das ganze aber nicht verändert.

Hat dazu jemand eine Idee? Würde mich sehr freuen!

Danke & Gruß,
neumo

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Michael N. schrieb:
> Kurioses Problem ist, das der Node funktioniert, so lange er am FTDI
> hängt, dann empfängt das Gateway die Daten.
> Powere ich den den Node über den FTDI Adapter (Datenleitungen
> abgeklemmt) dann kommt ganz sporadisch mal eine Nachricht durch.

Skurril. Fungiert der FTDI-Adapter evtl. als Antenne?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Conny G. schrieb:
> Skurril. Fungiert der FTDI-Adapter evtl. als Antenne?
Oder sorgt er durch seine Verbindung mit dem Rechner für eine stabilere 
Masse mit weniger Störungen?

von Michael N. (neumo)


Bewertung
0 lesenswert
nicht lesenswert
Felix Pflaum schrieb:
> Conny G. schrieb:
>> Skurril. Fungiert der FTDI-Adapter evtl. als Antenne?
> Oder sorgt er durch seine Verbindung mit dem Rechner für eine stabilere
> Masse mit weniger Störungen?

Mmh ich hatte eher ein Timing Problem vermutet und darum alles mit 
Serial.* auskommentiert. Hat nur nix gebracht. :-(

Unterschied mit dem FTDI ist schon der, das beide über den Rechner auf 
Masse verbunden sind, da beide Arduinos ja am gleichen Rechner hängen. 
Ich glaube ich teste das mal mit zwei verschiedenen Rechnern. Ich geb 
Bescheid.

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
dann sollte der eine aber ein Laptop sein, der sonst nirgenwo 
angestöpselt ist.

Sasch

von Michael N. (neumo)


Bewertung
0 lesenswert
nicht lesenswert
Sascha Weber schrieb:
> dann sollte der eine aber ein Laptop sein, der sonst nirgenwo
> angestöpselt ist.
>
> Sasch

Ja war es, zwei Laptops, nur Akkubetrieb. Der FTDI Adapter sorgt auch 
hier für das erfolgreiche Senden.
Ich habe noch diverse Tests gemacht, auch kombinierte Versorgung aus 
Arduino über Batterie und FTDI Adapter über USB (gemeinsame Masse) ging 
auch alles.

Fast schon lustig war: Der Laptop legte sich irgendwann schlafen, was 
ich nicht gleich merkte. Auch hier war der (stromlose) FTDI Adapter 
hilfreich für erfolgreichen Versand, wenn auch einzelne Pakete nicht 
ankamen. Ich hatte nun die RX/TX/DTR Pins in Verdacht einen bestimmten 
Pegel zu setzen (Low/High). Mit meinem Equipment (einfaches Multimeter) 
messe ich 8MOhm zu GND und 9MOhm zu Plus.
Kann das so eine Auswirkung haben?

Ein frustrierter neumo :-(

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Was hast denn als Antenne dran?

von Michael N. (neumo)


Bewertung
0 lesenswert
nicht lesenswert
Conny G. schrieb:
> Was hast denn als Antenne dran?

ein ca. 83mm langes Stück Kabel, müsste AWG22 sein glaube ich, 
Servolitze

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Michael N. schrieb:
> Conny G. schrieb:
>> Was hast denn als Antenne dran?
>
> ein ca. 83mm langes Stück Kabel, müsste AWG22 sein glaube ich,
> Servolitze

Das hört sich ok an. Meine Überlegung war: wenn Du es ganz ohne Antenne 
testen würdest, könnte alles was dran hängt u.U. helfen Senden/Empfangen 
zu verbessern im Vgl. zu keiner Antenne.
Und dann große Unterschiede machen, weil der Zustand ohne Antenne nur 
ca. 2-3m Reichweite bringt, d.h. 10% ohne Antenne, 20% mit irgendwas an 
der Schaltung.
Aber 83mm Kabel ist das bestmögliche Minimum, das wirklich ok 
funktioniert - da dürften sich andere Dinge nicht mehr so viel auswirken 
- 70% mit der Drahtantenne, 80% mit irgendwas an der Schaltung.
Demnach braucht man m.E. in dieser Richtung eigentlich nicht 
weitersuchen.

Dann hat es eher mit der Stromversorgung zu tun.
Die RFM sind wohl sehr empfindlich auf Störungen in der Stromversorgung.
Du könntest mal alles anwenden, was man so an Entstörung machen kann:
- Schaltung stabilisieren mit 100uF oder mehr
- Induktivität von 100µH direkt vor dem Modul
- 100nF Kerko und 1-10uF Low ESR-Elko am Modul
- kleine Serienwiderstände an den Datenleitungen (war das irgendwas 
200-300Ohm?)

Das nimmt Dir hochfrequente Störungen von der Versorgung und dämpft 
selbige auf den Datenleitungen, das könnte es sein.

von Michael N. (neumo)


Bewertung
0 lesenswert
nicht lesenswert
Conny G. schrieb:
> Michael N. schrieb:
>> Conny G. schrieb:
>>> Was hast denn als Antenne dran?
>>
>> ein ca. 83mm langes Stück Kabel, müsste AWG22 sein glaube ich,
>> Servolitze
>
> Das hört sich ok an. Meine Überlegung war: wenn Du es ganz ohne Antenne
> testen würdest, könnte alles was dran hängt u.U. helfen Senden/Empfangen
> zu verbessern im Vgl. zu keiner Antenne.
> Und dann große Unterschiede machen, weil der Zustand ohne Antenne nur
> ca. 2-3m Reichweite bringt, d.h. 10% ohne Antenne, 20% mit irgendwas an
> der Schaltung.
> Aber 83mm Kabel ist das bestmögliche Minimum, das wirklich ok
> funktioniert - da dürften sich andere Dinge nicht mehr so viel auswirken
> - 70% mit der Drahtantenne, 80% mit irgendwas an der Schaltung.
> Demnach braucht man m.E. in dieser Richtung eigentlich nicht
> weitersuchen.

Eine Verzweiflungstat - ich habe die Antenne angefasst!!! Er sendet 
dann. Also außen, die Isolierung (und testweise auch mal den blanken 
Draht), beides hilft. Dann habe ich noch ein ca. 40cm Kabel mit Klemme 
an die Isolierung geklemmt. Er sendet nun. Fürmich ist das Voodoo!
Oder kann das einer erklären?

Danke(!) an Conny, Sasch und Felix für Eure Ideen. Ich war gestern Abend 
nach 4h Nichterfolg so richtig frustriert.

: Bearbeitet durch User
von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Ah, spannend.
Also die Wirkung einer solchen 83mm-Einpol-Antenne ist am besten, wenn 
man darunter eine GND-Fläche hat.
Wenn die Platine keine große Massefläche hat, dann ist das definitiv ein 
großer Nachteil für die Antenne.
Google mal nach:
http://de.wikipedia.org/wiki/Antennentechnik#Viertelwellenstrahler
http://de.wikipedia.org/wiki/Groundplane-Antenne

Es braucht GND um die Welle aufzubauen.
D.h. eine Lambda-Viertel-Antenne funktioniert letzten Endes doch als 
Dipol, nur das der zweite Pol implizit vorhanden sein muss.

von Michael N. (neumo)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Okay, ich brauche also eine Massefläche. Derzeit hängt das RFM69CW auf 
der Rückseite des Arduino Pro Mini, nur gehalten von den Kabeln zwischen 
beiden.
Siehe Foto...
Werde versuchen zwischen beide noch ein Stück Leiterplatte einzuschieben 
und das Kupfer auf Masse zu legen. So war das glaube ich gemeint.

Dazu komme ich aber erst am Wochenende.

Btw: warum findet man dazu so wenig? Ich habe viele Fotos gesehen, wo 
das genauso gemacht wurde. Also nur das Kabel dran, fertig. Teilweise 
noch als Spirale aufgedreht. Aber von HF Technik weiß ich leider fast 
nix. :-(

Danke noch mal.

: Bearbeitet durch User
von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Das ist jetzt auch ziemlich "bastelig", aber versuche doch mal ein Stück 
ungeätzte Platine in der Größe des Arduino zwischen die beiden zu 
klemmen und schliesse sie an GND an.
Oder jede andere Art von Metallfläche - Alufolie, Stück Blech, ...
Soll natürlich keine Kurzschlüsse an den anderen Platinen verursachen 
;-)

von Michael N. (neumo)


Bewertung
0 lesenswert
nicht lesenswert
Habe nun noch ein Stück Leiterplatte (einseitig) dazwischen geschoben, 
Kabel zu GND und natürlich isoliert.
==> So funktioniert es!!

Großes Dankeschön an Eure Hilfe noch mal!

von Felix P. (fixxl)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang gibt es eine neue Version meiner Library, in die einige 
Erkenntnisse aus ausgiebigen Tests geflossen sind.

Wichtigste Neuerung ist sicherlich, dass beim Starten von Receiver oder 
Transmitter nur noch auf ModeReady gewartet wird, nicht mehr auf RxReady 
bzw. TxReady. Beim Transmitter macht es keinen Unterschied, beim 
Empfänger aber hat mich die Seite 37 im Datenblatt ein bisschen schlauer 
werden lassen.

Beim Empfang gab es bei mir auch immer wieder Probleme, dass einzelne 
Pakete nicht ankamen. Grund dafür war letztlich wohl, dass AGC und AFC 
durch externe Störer getriggert den Empfänger "verzogen" hatten. Um das 
zu verhindern, erwies sich das Register 0x2B (RxTimeout2) als hilfreich: 
Wenn nach dem Erkennen eines genügend starken Signals nicht innerhalb 
der dort eingestellten Zeit ein gültiges Paket empfangen wurde, wird ein 
Flag im Statusregister 0x27 gesetzt, womit man einen Neustart des 
Empfängers (und damit von AGC und AFC) triggern kann. Seit ich das so 
implementiert habe, gab es bei mir keine Empfangsausfälle mehr.

: Bearbeitet durch User
von Felix P. (fixxl)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gut, dass sich noch niemand gemeldet hat, in der geposteten Version von 
heute früh ist natürlich ein kapitaler Bock. Ohne aktivierten 
Chip-Select kann man dem Modul alles erzählen, passieren tut natürlich 
nichts... Fehler ist gefixt.

von mikro_Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Felix schrieb ja vor rund einem Jahr
"Einzig den guten alten Wake-Up-Timer vermisse ich"
Bislang konnte ich wenig dazu finden.
Ein Kollege weckt damit seine Aussensensoren auf und erziehlt so 
beachtliche Akkulaufzeiten.
Jetzt stehe ich vor dem Problem, ob ich versuchen soll, noch ein paar 
von den abgekündigten RFM12B zu ergattern oder ob es eine Alternative 
zum Wake-Up-Timer gibt, mit der man ein Aussensensor vor der Messung und 
dem Senden der Messwerte mittels RFM69CW zur "Zentrale" aufwecken kann.
Im Gegensatz zum verwendeten Atiny84 beim Kollegen, würden meine 
Aussensensoren auf einem ATMEGA 328P basieren.
Für Tips wäre ich echt dankbar.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Für meine Temperatur- und Feuchtigkeitssensoren (DHT22/AM2302 mit 
ATmega85) daheim habe ich aufgrund des Wake-Up-Timers auch die RFM12 
verbaut.

Wenn man auf die RFM69 zurückgreifen will, könnte man z.B. auf den 
Timerbaustein TPL5110 von TI zurückgreifen, um die Stromversorgung 
periodisch zu aktivieren und anschließend wieder abzuschalten.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Felix Pflaum schrieb:
> ATmega85

ATTiny85 selbstverständlich...

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lieber Felix,

habe einen Fehler in deiner LIB gefunden:

in der
static inline uint8_t rfm_spi
muss es
SCK_PORT &= ~(1 << SCK);
und
SCK_PORT |= (1 << SCK);

statt
SCK_PIN = (1 << SCK);
und
SCK_PIN = (1 << SCK);

heißen.

Sonst klappt es mit der Software SPI nicht, da der SCK fehlt.

Vielen Dank für deine Arbeit!

Beste Grüße
Franz

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Danke. Dieser Hinweis kam weiter oben schon einmal und hängt mit dem 
verwendeten Controller zusammen.

Der Schreibzugriff auf das PINx-Register zum schnellen Umschalten eines 
Pins ist erst bei neueren AVRs (z.B. ATmega88, ATmega168, ATmega328 
sowie die P- oder PA-Versionen) vorgesehen, die alten Controller wie der 
ATmega8 "verstehen" diese Anweisung nicht.

Vielleicht sollte ich das aus Kompatibilitätsgründen wirklich mal 
umstellen.

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ah ok alles klar...
Ich hab hier nen Mega16A...

Könnte man das sonst nicht aus der io lib ziehen? Also zum Beispiel auch 
die Hardware SPI-Pins? Die sind ja auch nicht immer gleich...

Danke trotzdem für deine Antwort :-)

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
[at] fixxl
Ich habe mal eine Frage zu dem Sendebefehl:

Wenn ich ihn das erste mal aufrufe wird die Sendung erfolgreich 
übertragen, er hängt jedoch dann in der Schleife
while (!(rfm_cmd(0x28FF, 0) & (1 << 3)) && --utimer)
Das Programm läuft zwar noch da es über Interrupts läuft, das 
Hauptprogramm ist jedoch festgefahren.
Das Statusregister 0x27 sagt 0b00001000. Also das Paket wurde 
erfolgreich gesendet.
Wenn ich den Befehl über einen Interrupt auslöse (rfm_transmit), dann 
verschluckt sich zwar der Interrupt, aber es wird immer wieder neu 
gesendet.

Hast du eine Idee was das sein könnte bzw. was macht denn die Schleife 
genau und wo wird der utimer verändert?

Beste Grüße
Franz

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Die Schleife prüft, ob das Bit für "Paket gesendet" gesetzt wurde und 
zählt zusätzlich noch einen Counter herunter, um eine Dauerschleife zu 
verhindern. Wenn der Counter bei 0 ist, bricht die Warteschleife ab, 
auch wenn "Paket gesendet" noch nicht gesetzt ist.

Hast du eine Gegenstelle, um festzustellen, ob deine Daten versendet 
werden?

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Auf einem zweiten Modul läuft
if (rfm_receiving()) 
    {
      PORTC |= (1<<PIN0); // AN
      rfm_receive(array, &rx_length);
      tx_length = rx_length;
      rfm_transmit(array, tx_length);
      rfm_rxon();
      PORTC &= ~(1<<PIN0); // AUS      
    }
Die LED blinkt auch und auf meinem ersten Modul lasse ich mir die 
Antwort anzeigen.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Die Daten werden also vom zweiten Modul empfangen, zurückgeschickt und 
vom ersten Modul auch korrekt dargestellt?

Auf Anhieb und ohne Kenntnis deines Codes verstehe ich nicht, wie das 
mit dem Hängenbleiben in der Transmit-Funktion zusammenpassen soll: Denn 
wenn er dort wirklich hängen sollte, dürfte er die Antwort nicht 
empfangen können, weil der Transmitter erst danach abgeschaltet wird.

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich hab jetzt noch ein bischen rumprobiert und folgenden einfachen 
Mindestaufbau:

- Sender:
Ein Modul sendet jede Sekunde ein inkrementiertes Byte an Daten
--> klappt einwandfrei

- Empfänger:
DIO0 löst einen Interrupt aus (wenn CRC=OK), der Empfänger gibt dann 
RSSI und das Byte aus.

Problem:
 - nach dem Einschalten des Empfängers werden etwa 3 bis 10 Pakete 
empfangen, dann nur nach Neustart oder manuellem Triggern des 
Interrupteingangs
 - im Logikanalyzer sieht es wie folgt aus:
1. FIFInotEmpty high, 2. CRC high, beide LOW und Ausgabe der Daten zum 
Display
Das ganze eben einige Male dann nichts mehr. Wenn man es länger laufen 
lässt löst teilweise der FIFOnotEmpty aus und geht wieder zurück

Interessanterweise klappt es deutlich länger wenn die Daten alle 20ms 
gesendet werden.

Die Frage ist also: Warum gibt das Modul kein Interrupt bei CRC aus?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Ohne den kompletten Code des Empfängers ist das schwer zu sagen, woran 
es liegen kann.

Zeig doch mal bitte, wie der beschriebene Ablauf im Programm und der 
Interruptroutine genau umgesetzt ist. Hast du ein Abdriften der Frequenz 
durch die AFC schon mal überprüft?

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

die Tage war mal wieder etwas Zeit für ein paar Tests.

Mit
rfm_cmd(0x1E00, 1);
rfm_cmd(0x2A00, 1);
klappt es jetzt. Auch musste ich die Sendeleistung mit
rfm_cmd(0x117F, 1); // +20dB
festlegen, da mit der Formel in der Bibo leider keine Verbindung möglich 
war. In der Headerdatei hatte ich "13" also das Maximum eingetragen.

Es klappt jetzt wunderbar, aber interessant wäre trotzdem warum es nicht 
mit den Registern 1E und 2A klappt. Mein bester RSSI liegt jetzt bei 
-16, mit den gesetzten Registern hatte ich 0 erreicht, jedoch eben immer 
nur kurz bis dich dann die Module wohl verstimmt hatten. Ausserdem ist 
die Reichweite nun etwas besser (ca 500m Wald).

Beste Grüße
Franz

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Klingt interessant, aber zeig doch bitte mal deinen Code. Vielleicht ist 
dann auch nachvollziehbar, wo das Problem bei Verwendung der AFC liegt.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Welche Version des RFM69 verwendest du eigentlich? Die Lib ist für die 
CW-Version (pinkompatibler Ersatz für RFM12) geschrieben, in der nur der 
Amplfier PA0 verwendet werden kann, daher die Beschränkung auf 13 dBm. 
Nachdem bei dir das Beschreiben des Registers 0x11 mit dem Wert 0x7F 
(PA0 aus, PA1 und PA2 an) funktioniert, gehe ich davon aus, dass du mit 
einer anderen Version arbeitest?

Der Befehl
rfm_cmd(0x2A00, 1);
 lautet bei dir nicht anders als bei mir, also scheint das Problem bei 
dir im Register 0x1E, d.h. im Umfeld der AFC, zu liegen. Soweit ich das 
bisher durchdrungen habe, beginnt das Modul bei Aktivierung des 
Empfängers, im eingestellten Frequenzbereich nach einem Signal zu 
suchen, dessen Intensität über der im Register 0x29 eingestellten 
Schwelle liegt. Wenn dieses Signal aber nicht das von der Gegenstelle 
gesendete ist, sondern von woanders kommt und zu weit von der 
Sendefrequenz der Gegenstelle entfernt liegt, zieht die AFC den 
Empfänger in einen Frequenzbereich, in dem er die Signale der 
Gegenstelle nicht mehr wahrnimmt.

Damit das nicht passiert kann man als Gegenmittel die Empfangsschwelle 
erhöhen, um die Wahrscheinlichkeit einer Störereinkopplung zu 
verringern, und/oder einen Receiver- und AFC-Neustart veranlassen, wenn 
nach Überschreiten der RSSI-Schwelle nicht innerhalb einer bestimmten 
Zeit keine fertige Payload mit korrektem CRC vorliegt. Hierzu muss man 
einen Wert ungleich 0x00 ins Register 0x2B schreiben (bei mir ist der 
Wert dezimal 40, was einer Dauer von 80 Bytes entspricht - damit wird 
auch die längste zulässige Payload noch innerhalb dieser Zeit 
übertragen) und im Statusregister 0x27 prüfen, ob das Timeout-Flag 
gesetzt ist. Wenn Timeout signalisiert wird, startet man den Empfänger 
einfach neu und sollte damit auf der sicheren Seite sein.

von David R. (dave234)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich klinke mich mal ein.

Ich habe noch keine Erfahrung mit Funkmodulen und habe mir 2 RFM69CW 
besorgt.

Ich habe die angehängte Schaltung 2x auf einem Steckbrett aufgebaut, 
einmal als Sender und einmal als Empfänger.

Zur Ansteuerung verwende ich die rfm69lib_v2-1, welche Felix Pflaum hier 
am 04.04.2015 reingestellt hat.

Als Antenne verwende ich jeweils so ein 20cm langen Draht wie er für die 
Steckbretter verwendet wird.

In der Lib habe ich "#define USE_HARDWARE_SPI  1" eingestellt und sonst 
nichts geändert.

Zum testen will ich  "Test" übertragen und schaue mit dem Empfänger ob 
ein 'T' enthalten ist, wenn ja soll eine LED leuchten, tut sie aber 
nicht.

Habe ich etwas nicht bedacht? Was mache ich falsch?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Hallo David,

leuchtet deine LED am Port C nach dem Einschalten für 100ms? Da du AVCC 
nicht angeschlossen hast, welcher für die Spannungsversorgung von Port C 
zuständig ist, kann ich mir das fast nicht vorstellen. Folgenden Artikel 
bitte 
https://www.mikrocontroller.net/articles/AVR_Checkliste#Spannungsversorgung_richtig_angeschlossen.3F 
beachten und AVCC auf dieselbe Art und Weise an 3,3V anschließen wie 
VCC.

Außerdem solltest du beachten, für welche Frequenz deine RFM69CW 
ausgelegt sind. Hast du die Version für 868 MHz, dann sollte deine 
Antenne eher 8,6cm lang sein als 20, hast du die für 433 MHz, dann musst 
du die Frequenz in der rfm69.h umstellen - und auch die Antenne auf 17cm 
kürzen.

von David R. (dave234)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Felix,

danke für die schnelle Antwort.

Ja, beim einschalten leuchten die LEDs jeweils kurz, habe trotzdem mal 
AVCC angeschlossen.

Habe dann mal einen kürzeren Draht als Antenne benutzt (habe das 868MHz 
Modul) und jetzt fubktioniert es. Danke!

Ich bastel mal ein bisschen damit rum :-)

von Ben (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich bin jetzt schon eine Weile dabei das rfm69 zum laufen zu überreden 
und vermute, dass ich irgendwo einen furchtbar trivialen Denkfehler 
habe.

Ich habe das Modul auf einem Board, welches vorher mit rfm12 lief und 
habe mir eine kleine Routine geschrieben, um per USART dem Board SPI 
Befehle zu schicken ( immer schön 16bit ) und die zeitgleiche Antwort zu 
übertragen.

Ich kann soweit auch schon alle Register auslesen und finde in fast 
allen Registern die Default Werte.

Große Ausnahme ist hier jedoch 0x01, also Operation Mode. Hier bekomme 
ich nur 0x00 zurück, was ja sleep-mode bedeuten würde.

Eigenartig ist jetzt leider auch, dass ich in kein Register schreiben 
kann.

Gibt es eventuell Hardware-Probleme, welche einen Sleep-Mode auslösen?

Ich sende jeweils (0x8104 um auf standby zu schalten), bringt aber 
leider nichts.

Eventuell kann mir ja jemand auf die Sprünge helfen...

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Ohne Code und eventuell den Schaltplan wird es schwer. Zeig doch mal 
her!

Das Auslesen nach den Schreibversuchen erfolgt noch einmal separat durch 
einen Lesebefehl? Die direkte Antwort beim Einschreiben gibt den 
Registerwert vor dem Schreibvorgang zurück.

von Ben (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Code rauszuschreiben ist nicht ganz so einfach, da das Projekt mit einem 
CortexM3 umgesetzt wird und die Einstellungen eher weiter verteilt sind.

Daher habe ich einen Plot von der SPI Kommunikation gemacht.

Ich kann den Code wenn nötig noch zusammenschreiben, ich denke aber es 
wird nicht allzu viel Mehrwert bringen, da die Kommunikation ja ohne 
Probleme funktioniert und auch beim ehemaligen rfm12 ohne Probleme lief.

Dabei habe ich auch die Pegel der Übertragung getestet, welche auf allen 
Leitungen über 2,5V sind. ( Hier also auch kein Problem )

Auch die Spannungsversorgung scheint Stabil auf 3.25V zu sein und zur 
Absicherung habe ich noch nahe dem Modul einen 10uF Kondensator an die 
Versorgungsleitung gehängt.

Ich vermute mittlerweile, dass der Quarz meines Moduls nicht anschwingt 
und daher im Sleep Mode ist. ( Ich habe auch das Modul schon getauscht )

Ich nutze das rfm69cw und mir ist aufgefallen, dass hier noch ein 
Löt-platz für einen Kondensator frei gelassen wurde.

Über diesen müsste ich das Schwingverhalten des Quarzes verändern 
können.

von Thomas L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat schon Jemand Erfahrungen mit dem Einsatz des Moduls zum Empfangen 
von RDKS/TMPS Sensoren in PWK-Reifen?
Hierbei würde nur der Empfangsteil genutzt, der Sender nicht.
Mein Ziel ist es die 32 Bit ID des Sensors auszulesen. Mit dem Einsatz 
von ISM-Funkmodulen habe ich bisher keine Erfahrungen, allerdings habe 
ich schon einige Projekte mit ATmega-Prozessoren realisiert. (unter 
Linux mit gcc-avr)

Gruß,
Thomas

von Robert B. (bunta)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich werfe mich mal als Neuling in solchen Basteleien dazwischen.
Ich habe hier zwei Arduino Nano (5V). An jedem habe ich ein RFM69CW 
(433mhz) "gehangen". Der eine ist der Sender, welcher die Daten eines 
DHT22 (später noch mehr sensoren) sendet. Der andere Dient als 
Empfänger.

Dafür habe ich die beiden Sketches "Gateway" und "Node" genutzt. Bekomme 
ich auch zum laufen und die Sendeleistung ist super und reicht für meine 
Zwecke bisher aus.

Nun zu meinem "Problem" oder zu meiner Frage:
Ich habe den RFM69CW Module direkt mit dem Nano verbunden.

Nano         RFM69CW
3.3V  -->    3.3V
GND   -->    GND
----         ANT (17,3cm langes Stück draht, aufrecht)
D2    -->    DI00
10    -->    NSS
11    -->    MOSI
12    -->    MISO
13    -->    SCK

Ich habe etwas gezögert Strom auf die NANOs zu geben, da die RFM ja nur 
3.3 vertragen laut Datasheet... der NANO aber 5V (bzw. 4,8V) auf den 
PINs rausgibt. Zumindest habe ich das z.B. beim MOSI gemessen.
ODER gilt das nur für den 3.3V der RFM und bei den anderen Anschlüssen 
ist das egal?
Weil ich habe nun schon einige durchläufe gemacht um meinen Code zu 
testen. Läuft super ... nichts stört. Oder sagen die RFM irgendwann 
"Goodbye" ... heimlich und leise?

Danke im Voraus.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Robert B. schrieb:
> Weil ich habe nun schon einige durchläufe gemacht um meinen Code zu
> testen. Läuft super ... nichts stört. Oder sagen die RFM irgendwann
> "Goodbye" ... heimlich und leise?

Die Wahrscheinlichkeit dafür ist sehr hoch. Wenn sie mit 3,3V angegeben 
sind sollte man sich danach richten.

von Cetin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin gerade bei der Umstellung von RFM12B nach RFM69CW. Mit dem 
RFM12B
hat vorher alles funktioniert. Nun habe ich die Library von Felix Pflaum
genommen.

Die Header habe ich folgendermaßen angepasst:
/* Carrierfrequenz in Hz */
              
#define FREQUENCY      433920000LL

/* Bitrate in bps (1200 ... 300000) and shall it be calculated as for RFM12
 * in order to get equal bitrate for RFM12 and RFM69 if used together? */
#define BITRATE        19200L
#define RFM12COMP      1

/* Output power in dBm (-18...13) */
#define P_OUT_DBM      8      // Output power in dBm

/* Pin assignment */
#define NSELPORT      B
#define NSEL        2
#define SDIPORT        B
#define SDI          3
#define SDOPORT        B
#define SDO          4
#define SCKPORT        B
#define SCK          5

/* Use Hardware-SPI if available? */
#define USE_HARDWARE_SPI  1

Die Baudrate von meinen RFM12 beträgt 19200 und betrieben werden sie mit 
433.92 MHz. Das Modul hängt am Hardware SPI des Atmega 168.

Das Programm bleibt in der Empfangsroutine hängen? Was muss ich denn 
noch beachten? Jemand eine Idee?

Gruß
Cetin

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
> Das Programm bleibt in der Empfangsroutine hängen

Habe gerade festgestellt, dass das Modul nicht in der Empfangsroutine 
feststeckt. Aber empfangen tu ich trotzdem nichts. Ein bestehendes Modul 
sendet jede Sekunde Testdaten, diese sollte das Modul eigentlich 
empfangen. Habe eine 17cm Drahtantenne.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Was auch sehr komisch ist, das mir das Modul den SPI-Bus blockiert. Ich 
muss von Hand resetten und nach mehreren Versuchen wird das flashen 
erfolgreich durchgeführt.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Cetin schrieb:
> Das Programm bleibt in der Empfangsroutine hängen? Was muss ich denn
> noch beachten? Jemand eine Idee?

Wie immer gilt: Kompletten Code anhängen, aus der angepassten 
Headerdatei wird man das Problem nicht ersehen können.

Als Sender fungiert ein RFM12B? Ist dort der korrekte CRC für das RFM69 
implementiert?

von Cetin A. (exaware)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
anbei der komplette Code.

> Als Sender fungiert ein RFM12B?
Ja

> Ist dort der korrekte CRC für das RFM69
implementiert?
Nein, auf dem RFM12 ist kein CRC implementiert.

Das Status Register liefert folgendes: 1001000000000000

: Bearbeitet durch User
von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du vom RFM12B keinen CRC mitschickst, aber beim RFM69 im Register 
0x37 die Einstellung "CRC on" tätigst, darfst du dich nicht wundern, 
wenn du nie Daten empfängst. Der Package-Handler des RFM69CW erwartet 
die Daten folgendermaßen:

Präambel (0xAA) + Schlüsselwort 1 (0x2D) + Schlüsselwort 2 (0xD4) + 
Payloadlänge (Anzahl an folgenden Bytes ohne CRC-Bytes) + Eigentliche 
Payload (so viele Bytes wie in Payloadlänge angegeben) + CRC-Byte 1 + 
CRC-Byte 2

Du kannst versuchen, in der rfm_init() statt
rfm_cmd(0x3790, 1); 
das Kommando
rfm_cmd(0x3788, 1); 
zu schicken, um den CRC zu deaktivieren.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Habe es mit
rfm_cmd(0x3788, 1);
 probiert, geht leider nicht .

Habe die while-Schleife folgendermaßen umgeschrieben. An der LED_TX sehe
das das Programm nirgends stehen geblieben ist.
Und die LED_RX sollte eigentlich jedesmal toggeln, wenn etwas empfangen 
wird. Di LED_RX bleibt aus.
while (1)
{    
  counter++;
  if (rfm_receiving()) 
  {
    LED_RX_TOG;
    rfm_receive(array, &rx_length);
    uart_send_text(array);
    uart_send_text("\r\n");
  }
  if(counter >= 10000)
  {
    LED_TX_TOG;
    counter=0;
  }
}

Ich habe das Gefühl, das mit dem spi irgendwas nicht stimmt. Sobald das 
Modul initialisiert wird, kann ich schier nicht mehr flashen, muss 
bestimmt 5-10 mal mit gedrückter Reset-Taste probieren. Irgendwann gehts 
dann. Dieses Phänomen hatte ich noch nie. Der Programmer ist in Ordnung.
Wenn ich das Modul auskommentiere, funktioniert das flashen einwandfrei.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Was sendet die Gegenseite genau? Und welche Einstellungen hat das 
RFM12B? Passen Frequenzhub beim RFM12B und Empfängerbandbreite beim 
RFM69 zusammen?

Dass das Modul irgendeinen Einfluss aufs Flashen des Controllers hat, 
darf unter normalen Umständen nicht sein. Mal die übliche Checkliste 
durchgehen:

Ist ein externer Pullup-Widerstand am Chip-Select vorhanden, um das 
Modul bei Controllerreset sicher inaktiv zu halten?
Sind in den SPI-Leitungen zwischen Controller und Modul 
Serienwiderstände vorhanden oder hängt das Funkmodul quasi direkt am 
Programmer? Letzteres könnte ungünstig sein, wenn kein Pullup am 
Chip-Select ist.
Betriebsspannung ist im zulässigen Bereich?

Was mir auch aufgefallen ist: Der USART-Rx-Interrupt wird aktiviert und 
die Interrupts werden mit sei() global freigegeben, die zugehörige 
Interruptroutine habe ich aber nirgends gesehen.

von Cetin A. (exaware)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Felix P. schrieb:
> Was sendet die Gegenseite genau? Und welche Einstellungen hat das
> RFM12B? Passen Frequenzhub beim RFM12B und Empfängerbandbreite beim
> RFM69 zusammen?
Habe mal den Code von meinem RFM12 angehängt

> Ist ein externer Pullup-Widerstand am Chip-Select vorhanden, um das
Nein
> Modul bei Controllerreset sicher inaktiv zu halten?
> Sind in den SPI-Leitungen zwischen Controller und Modul
> Serienwiderstände vorhanden oder hängt das Funkmodul quasi direkt am
> Programmer?
Ja, Modul hängt direkt am Programmer

> Betriebsspannung ist im zulässigen Bereich?
Ja, Spannung wird mit einem LM117 auf 3,3V geregelt

> Was mir auch aufgefallen ist: Der USART-Rx-Interrupt wird aktiviert und
> die Interrupts werden mit sei() global freigegeben, die zugehörige
> Interruptroutine habe ich aber nirgends gesehen.
Du hast Recht, das ist noch alter Code, das ich nicht mehr benötige.
Habe nun den Interrupt + sei() entfernt. geht aber immer noch nicht.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Felix P. schrieb:
> Ist ein externer Pullup-Widerstand am Chip-Select vorhanden, um das
> Modul bei Controllerreset sicher inaktiv zu halten?
Habe gerade den Pullup eingelötet. Nun klappt das flashen ohne Probleme.

Wenn wir es noch hinbekommen, dass Daten empfangen werden, dann werde 
super glücklich sein.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Der Frequenzhub beim RFM12B (105 kHz) dürfte ein bisschen zu hoch für 
die Empfängerbandbreite am RFM69 (62.5 kHz) eingestellt sein. Stell mal 
beim RFM69 in der rfm_setbit() beim "case 1:" den Wert bw auf dezimal 17 
bzw. hex 0x11.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Felix P. schrieb:
> Der Frequenzhub beim RFM12B (105 kHz) dürfte ein bisschen zu hoch für
> die Empfängerbandbreite am RFM69 (62.5 kHz) eingestellt sein. Stell mal
> beim RFM69 in der rfm_setbit() beim "case 1:" den Wert bw auf dezimal 17
> bzw. hex 0x11.
Geht leider immernoch nicht :(

Lasse mir jetzt jede Sekunde das Statusregister anzeigen. Ich bekomme 
folgende Werte (sortiert nach Häufigkeit):

55296 --> Am meisten
56320
56672
55648

: Bearbeitet durch User
von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Was die Zahlen bedeuten, kannst du dem Datenblatt (Register 0x27 und 
0x28) entnehmen, deine Werte (vor allem die letzten beiden) deuten 
darauf hin, dass du schon ganz nah dran bist.

Was wird genau über das RFM12B gesendet? Also was übergibst du der 
rfm12_txdata()? Kann mir vorstellen, dass das erste Zeichen ein zu 
großer Zahlenwert ist und nicht genug Zeichen nachkommen.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Felix P. schrieb:
> Was die Zahlen bedeuten, kannst du dem Datenblatt (Register 0x27 und
> 0x28) entnehmen, deine Werte (vor allem die letzten beiden) deuten
> darauf hin, dass du schon ganz nah dran bist.
Habe auch schon reingeschaut. Dachte ich mir auch, dass da schon etwas 
ankommt.

> Was wird genau über das RFM12B gesendet? Also was übergibst du der
> rfm12_txdata()? Kann mir vorstellen, dass das erste Zeichen ein zu
> großer Zahlenwert ist und nicht genug Zeichen nachkommen.
Hier der Code (TauIn und TauOut sind von Typ "double")
char temp4[4];
strcpy(debugArray, "d");
strcat(debugArray,";");
dtostrf( TauIn, 4, 1, temp4);
strcat( debugArray, temp4 );
strcat(debugArray,";");
dtostrf( TauOut, 4, 1, temp4);
strcat( debugArray, temp4 );
strcat(debugArray,";");
dtostrf( TauIn-TauOut, 4, 1, temp4);
strcat( debugArray, temp4 );
rfm12_txdata(debugArray);

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Das erste von dir übergebene Byte ist ein "d", das entspricht dem 
Zahlenwert 100 - und das wird vom RFM69 als Längenbyte interpretiert.

Wenn du am RFM12-Code nichts ändern willst, ändere beim RFM69 in der 
rfm_init() die
rfm_cmd(3788, 1);
 in
rfm_cmd(3708, 1);
Damit wechselst du auf feste Länge und die
rfm_cmd(3800 + MAX_ARRAYSIZE, 1);
 in
rfm_cmd(3811, 1);
Damit wird die Länge auf 17 Bytes eingestellt.

Wenn ich die Empfangsfunktion des RFM12B richtig gelesen habe, sollte 
deine Nachricht 17 Bytes lang sein, oder?

: Bearbeitet durch User
von Klaus I. (klauspi)


Bewertung
0 lesenswert
nicht lesenswert
Eine funktionierende Konfiguration ohne Crc habe ich mal hier gepostet:
Beitrag "Re: RFM69 - Beispiel für Initialisierung gesucht"
Das ist kompatibel zu einem Beispiel aus dem BASCOM-Forum zu RFM01 und 
RFM02.
CRC ist auch kein Problem wenn man die Datenpaketgröße anpasst.

Die Reset-Beschaltung sollte man mal genauer anschauen. Verbundener 
Reset mit den uC geht gar nicht. Getrennter Pullup funktioniert oft, 
Reset-Pin floaten lassen funktioniert meistens, aber ich habe jetzt 
meine Funkstation mit Reset-Pulldown seit einigen Wochen ohne Probleme 
am Laufen und würde eher das empfehlen. Das sind aber nur meine ersten 
Eindrücke in diesem Gebiet.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Felix P. schrieb:
> Das erste von dir übergebene Byte ist ein "d", das entspricht dem
> Zahlenwert 100 - und das wird vom RFM69 als Längenbyte interpretiert.
>
> Wenn du am RFM12-Code nichts ändern willst, ändere beim RFM69 in der
> rfm_init() die
>
rfm_cmd(3788, 1);
 in
rfm_cmd(3708, 1);
Damit wechselst du
> auf feste Länge und die
>
rfm_cmd(3800 + MAX_ARRAYSIZE, 1);
 in
rfm_cmd(3811, 
> 1);
Damit wird die Länge auf 17 Bytes eingestellt.
>
> Wenn ich die Empfangsfunktion des RFM12B richtig gelesen habe, sollte
> deine Nachricht 17 Bytes lang sein, oder?

Habe jetzt auf dem RFM12 den Text auf "Hallo Welt" eingestellt. 
Funktioniert trotzdem nicht.
ich habe auch mal mit der Preambellänge mit 1,2,3,4 gespielt aber geht 
auch nicht. Aktuell steht die Länge auf 3 sowie auch beim RFM12.

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du "Hallo Welt" sendest, dann muss die Länge logischerweise 10 
Bytes betragen, der Befehl also
rfm_cmd(0x380A, 1);
lauten.

Sehe gerade, dass ich oben das 0x vergessen habe vor den Hex-Werten. Da 
kommt dann natürlich nur Unsinn raus.

Also:
rfm_cmd(0x3708, 1);
rfm_cmd(0x380A, 1);

So müssen diese beiden Register des RFM69 für "Hallo Welt" konfiguriert 
sein.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Felix P. schrieb:
> Wenn du "Hallo Welt" sendest, dann muss die Länge logischerweise 10
> Bytes betragen, der Befehl also
>
> rfm_cmd(0x380A, 1);
> 
> lauten.
>
> Sehe gerade, dass ich oben das 0x vergessen habe vor den Hex-Werten. Da
> kommt dann natürlich nur Unsinn raus.
>
> Also:
>
> rfm_cmd(0x3708, 1);
> rfm_cmd(0x380A, 1);
> 
>
> So müssen diese beiden Register des RFM69 für "Hallo Welt" konfiguriert
> sein.
Juhu, es kommen Daten an :)
Aber es kommt nur "allo Welt"
Hast du eine Idee?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Cetin A. schrieb:
> Juhu, es kommen Daten an :)
> Aber es kommt nur "allo Welt"
> Hast du eine Idee?

Ja. Das liegt an meiner Empfangsfunktion, die für variable Paketlänge 
ausgelegt ist und deswegen das erste empfangene Byte nicht als Datenbyte 
erkennt.

Du musst dazu in der Funktion rfm_fifo_wnr() ein paar Anpassungen 
vornehmen:
  // Read data bytes
  else {
    // Read-access register 0
    rfm_spi(0);

    // Get length
    // data[0] = rfm_spi(0xFF); // Diese Zeile muss auskommentiert sein

    // Make sure there's no array-overflow
    // if (data[0] > MAX_ARRAYSIZE) data[0] = MAX_ARRAYSIZE; // Die hier braucht man dann auch nicht

    // Get data
    for (uint8_t i = 1; i <= 10; i++) { // Hier muss i<=10 gesetzt werden
      data[i] = rfm_spi(0xFF);
    }
  }

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Geht nicht. Ich schau mir die Funktion gerade nochmal an.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
OK, ich hab es hinbekommen. Folgende Funktionen sehen nun wie folg aus:
static uint8_t rfm_fifo_wnr(char *data, uint8_t wnr) { // Address FIFO-Register in write- or read-mode

  ACTIVATE_RFM;

  // Write data bytes
  if (wnr) 
  {
    // Make sure there's no array-overflow
    if (data[0] > MAX_ARRAYSIZE) data[0] = MAX_ARRAYSIZE;

    // Write-access register 0
    rfm_spi(0x80);

    // Transfer length
    rfm_spi(data[0]);

    // Transfer data
    for (uint8_t i = 1; i <= data[0]; i++) {
      rfm_spi(data[i]);
    }
  }

  // Read data bytes
  else {
    // Read-access register 0
    rfm_spi(0);
    // Get data
    for (uint8_t i = 0; i < 10; i++) 
    {
      data[i] = rfm_spi(0xFF);
    }
  }

  DEACTIVATE_RFM;

  return 0;
}
uint8_t rfm_receive(char *data, uint8_t *length) 
{
  char fifoarray[10];
  uint8_t length_local;

// Turn off receiver, switch to Standby
  rfm_rxoff();

// Read FIFO-data into FIFO-array
  rfm_fifo_wnr(fifoarray, 0);

// Read data from FIFO-array
  length_local=10;
  for (uint8_t i = 0; i < length_local; i++) 
  {
    data[i] = fifoarray[i];                     // Data bytes
  }
  data[length_local] = '\0';                         // Terminate string

// Clear FIFO after readout (not necessary, FIFO is cleared anyway when switching from STANDBY to RX)
  rfm_fifo_clear();

// Write local variable to pointer
  *length = length_local;

// Return value is for compatibility reasons with RFM12
// It's always 0 because PayloadReady only occurs after successful hardware CRC
  return 0; // 0 : successful, 1 : error
}

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Sehr schön! Dann kann ich ja jetzt beruhigt schlafen gehen. Gute Nacht!

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
@Felix
Einen herzlichen Dank für die große Hilfe. So Leute wie du machen Foren 
erst liebenswert. Nochmal vielen Danke!

von Werner P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab mal ne blöde Frage. Wozu dient in der rfm_init:
for (uint8_t i = 10; i; i--) {

die for Schleife. Warum wird die 10 mal durchlaufen?

Danke

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank schon einmal für die super Lib.
Eine frage hätte ich noch. Ich will einen Modbus RTU über die RFM69 
senden. Dieses Protokoll hat aber bis zu 256 Byte. Ist dies auch mit 
dieser Lib möglich?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
@Werner P.:
Das zehnfache Durchlaufen der Initialisierung ist noch ein Überbleibsel 
aus RFM12-Zeiten. Damals hatte ich irgendwo in den weiten des Netzes den 
Hinweis gefunden, dass man die Register sicherheitshalber mehrfach 
beschreiben sollte. Wirklich sinnvoll erscheint es mir bei näherem 
Nachdenken auch nicht mehr.

@Peter:
Derart lange Datenpakete habe ich bisher nie verschickt, daher ist der 
Fall in der Lib aktuell auch leider noch nicht abgedeckt. Im Datenblatt 
V1.1 auf Seite 56 ist beschrieben, wie man Pakete, die größer sind als 
der eingebaute FIFO-Buffer, handhaben kann. Für eine zukünftige Version 
werde ich das sicher mal umsetzen.

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sehe ich das richtig das ich die "MAX_ARRAYSIZE 30" auf die Maximale 
Anzahl 64 setzten kann wenn man in dem Modus wie v2.1 fährt und dann bis 
zu 64 Bytes senden und Empfangen kann? LG

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bzw da im Variable Lenght Modus maximal 64 Bytes gesendet werden können 
die länge auf maximal 65 gestellt werden kann?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Habe gerade keine Hardware zum Testen da, aber normalerweise sollte das 
funktionieren, ja.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Felix,

habe erneut ein komisches Problem, vielleicht hast du eine Idee.

Folgende Situation:

Der Sender mit RFM12B sendet jede Sekunde ein 16 Zeichen großes Packet 
an
den Empfänger mit RFM69CW. Der Inhalt des Packets ist ein einfacher 
Zählerwert 0-255, vorne mit Nullen aufgefüllt um auf die 16 Zeichen zu 
kommen.

Nun ist es so, das der Empfänger sporadisch 1-5 Packete nicht empfängt. 
Ich habe herausgefunden, das es in folgender Routine passiert:
uint8_t rfm_receiving(void) 
{
  uint16_t status;
  status = rfm_status();

  // No Payload and RSSI-Rx-Timeout -> Rx-Restart
  if ((!(status & (1 << 2))) && (status & (1 << 10))) 
  {
    rfm_cmd((rfm_cmd(0x3DFF, 0) | 0x3D04), 1);    
  }

  // Check if PayloadReady is set AND unused bit is not set (if bit 0 is set, module is not plugged in)
  return ((status & (1 << 2)) && !(status & (1 << 0)));
}

Wenn ich folgende Zeile auskommentiere, gehen keine Packete verloren 
dafür wird nach einer gewissen Zeit gar nichts mehr empfangen.
rfm_cmd((rfm_cmd(0x3DFF, 0) | 0x3D04), 1);

Was hat es mit diesem RX-Restart auf sich? Was geht hier schief?

: Bearbeitet durch User
von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Der Empfänger befindet sich nach dem Start im AGC- und AFC-Modus, er 
wartet also auf ein Signal oberhalb der RSSI-Schwelle, um seine 
Empfindlichkeit und die Frequenz danach einzustellen. Danach wartet er 
mit der ermittelten Verstärkung und Frequenz auf Daten. Tritt nun der 
Fall ein, dass für ein bestimmtes Zeitfenster keine gültigen Daten 
kommen (=Timeout gemäß RegRxTimeout2), geht der Empfänger wieder in den 
AGC- und AFC-Modus, weil davon auszugehen ist, dass es keine vernünftige 
Präambel sondern ein Störsignal war, welches getriggert hat.

Das habe ich damals eingebaut, um genau den Fall zu vermeiden, den du 
durch das Auskommentieren erlebt hast: Wenn ein Störsignal den Empfänger 
"verzieht", hängt der bei einer falschen Frequenz fest und empfängt bei 
der richtigen nicht mehr.

Was helfen kann:
- Im Register 0x29 die RSSI-Threshold verringern. Der negative halbe 
Registerwert gibt die Empfangsschwelle an, bei 255 wären es also -127 
dBm, bei 200 dann -100 dBm, bei 180 -90 dBm, usw. Je niedriger der 
Registerwert ist, umso stärker muss also ein Signal sein, um die 
RSSI-Erkennung auszulösen.
- Mit der Timeout-Zeit im Register RegRxTimeout2 0x2B spielen. Die Zeit 
berechnet sich aus Registerwert  16  Bitzeit (die ist abhängig von der 
eingestellten Bitrate und deren Kehrwert). Bei 16 Bytes Payload muss der 
Wert also mindestens 8 betragen, durch den Overhead mit Präambel und 
evtl. CRC wird das aber zu wenig sein.

: Bearbeitet durch User
von Cetin A. (exaware)


Angehängte Dateien:
  • preview image for a.PNG
    a.PNG
    29,1 KB, 403 Downloads

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Tipps. Den Erfolg hat die Deaktivierung des 
"TimeoutRssiThresh" gebracht, also 0x2B00.

Eine Frage hätte ich noch, zwischendurch kommen immerwieder nicht 
lesbare Zeichen, siehe Screenshot vom Terminal. Von der Uart-Routine 
kommt es nicht. Kannst du dir das erklären?

Update:
Das deaktivieren des "TimeoutRssiThresh" hat leider zur Folge, dass der 
Empfang irgendwann ganz eingestellt wird, so wie du es oben bereits 
beschrieben hast. Ich benutze kein CRC, aber mit dem Timeout 8 gibt es 
immer noch Probleme. Die Schwelle habe ich auf 29FF gestzt.

Update2:
Mit 0x29A0 und 0x2B1F geht es nun einigermaßen. Ab und zu wir immer noch 
das eine oder andere Packet übersprungen.

: Bearbeitet durch User
von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

denke daran das du mit Funk arbeitest - eine 100% störungsfreie 
Übertragung wirst du nicht erreichen.
Mit CRC würde der Empfänger solche Daten wie in deinem Bild von selbst 
ausfiltern.

Sascha

von Hannes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich hab auch mal ne Frage zu den Modulen.
Wie kann man prinzipiell den RSSI Wert während einer Datenübertragung 
auslesen? Ich kann zwar den Echtzeitwert abfragen. Aber um ein Indiz für 
die Empfangsstärke zu erhalten ist das nicht wirklich brauchbar. Kann 
dieser Wert irgendwo im Modul zwischengespeichert und anschließend 
abgefragt werden?

von Cetin A. (exaware)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Felix,

ich habe wieder ein Problem, ich hoffe du kannst mir hier weiter helfen.
Das Empfangen mit dem RFM69CW funktioniert gut. Nur beim Senden gibt es 
Probleme. Es kommt nichts an.
Habe mal die von mir überarbeitete RFM69CW.c und die main.c angehängt, 
vielleicht findest du den Fehler. Vielleicht habe ich noch in der 
rfm_init einen Fehler.

Gruß
Cetin

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Vermutlich ist der Fehler in der Funktion "rfm_fifo_wnr".

Du arbeitest im Fixed-Length-Mode, hast aber beim Schreibvorgang noch 
die Übertragung der Länge mit drin. Das
    // Transfer length
    rfm_spi(16);

muss raus.

von Cetin A. (exaware)


Bewertung
0 lesenswert
nicht lesenswert
Felix P. schrieb:
> Vermutlich ist der Fehler in der Funktion "rfm_fifo_wnr".
>
> Du arbeitest im Fixed-Length-Mode, hast aber beim Schreibvorgang noch
> die Übertragung der Länge mit drin. Das
>
>
>     // Transfer length
>     rfm_spi(16);
> 
>
> muss raus.
Das war es. Nach dem auskommentieren der Zeile ging es.
Vielen Dank Felix.

von Andreas S. (andy7683)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich versuche nun schon seit drei Tagen 2 RFM69HCW(433 MHz -Version) 
miteinander kommunizieren zu lassen.


Die Funkmodule sind jeweils mit einem ATMega8 verbunden.

Die Kommunikation über den SPI-Bus funktionier einwandfrei. Das weiß 
ich, da ich Register sowohl lesen als auch schreiben kann.

Ich habe mir Felix sein Code unter den "Nagel gerissen" und an meine 
Bedürfnisse angepasst.(Leider sieht jetzt alles ein wenig anders aus und 
durch das debuggen ist er auch nicht schöner geworden :-))

Den Microcontroller betreibe ich mit 3.3V um ihn an die "Bedürfnisse" 
des RFM69 anzupassen. Später wollte ich die Anbindung mit 
Logik-Bausteinen und Spannungsreglern realisieren, um die 5V -> 3.3V 
Brücke zu realisieren.

Jedoch scheiter es immer noch an den Basics.

Ich habe mir sowohl eine Koaxialkabel-Dipolantenne gebaut als auch einen 
Kondensator an die Spannungsversorgung geklemmt um diverse Fehler 
auszuschließen.

Gestern hat die Kommunikation auch kurzzeitig funktioniert... Mag ein 
Zufall gewesen sein.

Wenn ich die Statusregister auslesen, sieht es so aus als ob die Daten 
gesendet werden. Jedoch kommt auf dem 2ten RFM nix an. und ich habe 
einen RSSI-Pegel von FF --> somit nix :-)

Ich weiß echt nicht mehr weiter :-((

Ich habe mal meinen Code und ein Bild von der Antenne angehängt.

Vielleicht sei noch angemerkt, dass ich ein blutiger Elektronik-Anfänger 
bin und auch C und ich sind noch nicht die besten Freunde, also bitte 
keine Schläge für den recht unschönen Code...

: Bearbeitet durch User
von Gucky (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Keine Angst, über Codequalität sag' ich nix. Ich kenne meine eigene.
Ich hab den RFM69 eingesetzt - bin sehr zufrieden. Ging auf Anhieb.

Was ich empfehlen kann:
Verwende eine gängigen Bibliotheken, entweder von
LowPowerLab, oder, wie ich:
http://www.airspayce.com/mikem/arduino/RadioHead/
und davon RH_RF69 uns den RHReliableDatagram Manager.

Diese setzt weitere Bibliotheken voraus, sind sofort lauffähig auf 
Arduino UNO und Mega 2560.

Was helfen kann, man weiss ja nie, ob Sender oder Empfänger defekt sind 
oder beides oder vielleicht die Frequenz zw. Sender und Empfänger nicht 
stimmt oder ob man überhaupt sendet:
Ein DVB T Stick und ein Programm wie SDRSharp, um diesen anzusteuern. 
Damit habe ich verifiziert, das mein Sender auch sendet.

Deine Antenne: Du nimmst das zu ernst.
Ein Stück Draht, etwas Lambda/Viertel (ca. 8 cm bei 866 MHz) , direkt 
auf die Leiterplatte gelötet reicht völlig aus und versorgt die ganze 
Wohnung.

Viel Erfolg!
Gucky

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Gucky schrieb:
> Hallo,
>
> Keine Angst, über Codequalität sag' ich nix. Ich kenne meine eigene.
> Ich hab den RFM69 eingesetzt - bin sehr zufrieden. Ging auf Anhieb.
>
> Was ich empfehlen kann:
> Verwende eine gängigen Bibliotheken, entweder von
> LowPowerLab, oder, wie ich:
> http://www.airspayce.com/mikem/arduino/RadioHead/
> und davon RH_RF69 uns den RHReliableDatagram Manager.

Die Bibliotheken kenne ich beide. Sind mir aber irgendwie zu mächtig. 
Außerdem hätte ich den Code gerne in C, da er so besser in mein Projekt 
integrierbar ist.

>
> Diese setzt weitere Bibliotheken voraus, sind sofort lauffähig auf
> Arduino UNO und Mega 2560.
>
> Was helfen kann, man weiss ja nie, ob Sender oder Empfänger defekt sind
> oder beides oder vielleicht die Frequenz zw. Sender und Empfänger nicht
> stimmt oder ob man überhaupt sendet:
> Ein DVB T Stick und ein Programm wie SDRSharp, um diesen anzusteuern.
> Damit habe ich verifiziert, das mein Sender auch sendet.

Nette Idee ! Jetzt brauch ich nur noch ein Stick :-) Was Sendet bzw. 
empfängt denn noch auf 433 MHz ?

Gibt es noch eine andere Möglichkeit die RFMs einzeln zu testen ?
Kann man davon ausgehen, dass wenn sich die Register lesen und schreiben 
lassen, das ganze Modul i.O ist ?


>
> Deine Antenne: Du nimmst das zu ernst.
> Ein Stück Draht, etwas Lambda/Viertel (ca. 8 cm bei 866 MHz) , direkt
> auf die Leiterplatte gelötet reicht völlig aus und versorgt die ganze
> Wohnung.

Damit hatte ich es anfangs versucht. Wie gesagt hat meines Erachtens 
nach Anfangs auch funktioniert. Jedoch dann irgendwann nicht mehr. (Habe 
zwischendurch am Code gebastelt). Bin daher nicht sicher ob die Hardware 
defekt ist oder einfach nur der Code falsche.


>
> Viel Erfolg!
> Gucky

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht habe ich es in deinem Code auch nur überlesen, aber was mir 
fehlt ist schlicht und einfach die Stelle, an der du die Interrupts 
global aktivierst (sei()).

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Wofür brauch ich die Interrupt-Routine ?
UART empfängt nichts, daher sollte hier auch kein uart-rx interrupt 
nötig sein...
Oder stehe ich gerade vollkommen auf dem Schlauch ?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Nein, war mein Fehler. Hatte nur die SPI-Interrupt-Routine gesehen und 
war damit davon ausgegangen, dass du die SPI-Kommunikation über 
Interrupts regelst.

Die Einstellung, dass im Register 0x11 nicht der PA0 sondern PA1 
verwendet wird, ist Absicht? Mit dem HCW-Modul habe ich leider keine 
Erfahrung.

von Andreas S. (andy7683)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ist Absicht, das ich PA1 verwenden, da ich mit PA0 nix empfangen habe.

Das Ergebnis ist also das gleiche :-(

Was muss ich an deinem Code in Main ändern, sodass ich einfach mal ein 
paar Signale hin und her schiebe ?

Kann man die Module sonst noch irgendwie testen ?

Bin mir echt nicht sicher ob das senden oder das empfangen das Problem 
ist.

Ich habe mal ein Screenshot von meinen Debuggingversuchen beigefügt.

Ich erkenne leider nur dass kein Signal ankommt...

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Eigentlich sollte es ausreichen, wenn du in der rfm69.h die Definition 
von FREQUENCY auf 433000000LL änderst. Und dann muss einfach eine der 
beiden Seiten einen Transmit machen, d.h. du musst in der main-Funktion 
vor der while(1)-Schleife ein rfm_transmit("12345", 5) einfügen. Dann 
sollte das endlos hin und her laufen.

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Hm...
Irgendwie bleibt der Code irgendwo hängen.
Leider war es mit Frequenz anpassen und rfm-transmit nicht getan.

Werde das morgen mal debuggen und morgen ein Update geben.


Danke schon mal!

von Gucky (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Dir ist sicher bewusst, das Du zu viele Unsicherheitsfaktoren auf einmal 
hast? Code, Module, Schaltung, Frequenz, die Level-Shifter ....
Der Vorteil der RFM 69 ist, das man sie mit einem SDR empfangen kann(Das 
wird mit NRF Module(2,4 GHz) schon schwerer).
Vielleicht solltest Du diesen Vorteil nutzen?

Gucky

P.S.:
Wenn bei mir die Code stehen blieb, kam der Interrupt vom RFM nicht an.
Die Routine hing im "warten" darauf.
War einmal ein Zuweisungsfehler und sonst jedesmal ein 
Steckbrett/Verkabelungsfehler.

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Gucky schrieb:
> Hallo,
>
> Dir ist sicher bewusst, das Du zu viele Unsicherheitsfaktoren auf einmal
> hast? Code, Module, Schaltung, Frequenz, die Level-Shifter ....
> Der Vorteil der RFM 69 ist, das man sie mit einem SDR empfangen kann(Das
> wird mit NRF Module(2,4 GHz) schon schwerer).
> Vielleicht solltest Du diesen Vorteil nutzen?

Würde ich gerne nutzen.
Kannst du ein Modul empfehlen ?
Wird sofort bestellt 😀

>
> Gucky
>
> P.S.:
> Wenn bei mir die Code stehen blieb, kam der Interrupt vom RFM nicht an.
> Die Routine hing im "warten" darauf.
> War einmal ein Zuweisungsfehler und sonst jedesmal ein
> Steckbrett/Verkabelungsfehler.

von Andreas S. (andy7683)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zunächst einmal vielen Dank an Gucky und vor allem an Felix.
Die Bibliothek von Felix ist eine 1a Vorlage !

Um es kurz zusammenzufassen: Es läuft !

Meine Problem mit dem hängen bleiben war schlicht weg die vergessene 
Initialisierung der UART-Schnittstelle (Nach einer gewissen Zeit sieht 
man den Wald vor lauter Bäumen nicht mehr).

Habe mit Felixs Code heute noch ein wenig rumexperimentiert...
Dabei ist mir ein echt komischen Phänomen aufgefallen, welches ich mir 
nicht erklären kann.

Ich verwende zum Programmieren ein STK500, dieses hat einen Reset-Button 
für den µC. Diesen habe ich auch reichlich zum Einsatz gebracht.
Das komplette Abschalte habe ich vermieden, da sich manchmal die 
Versorgungsspannung des STK von den eingestellten 3.3V auf den 
Standardwert von 5.0V zurückstellt.

Nun verhält es sich bei mir so, dass nach einen Druck auf den 
Reset-Button, keine Daten mehr ankommen. Schalte ich jedoch kpl. aus, 
also auch die Versorgungsspannung des RFM, funktioniert alles wieder 
einwandfrei.

Das könnte auch die Erklärung für meinen sporadisch funktionsfähigen 
Code sein. Da ich manchmal wohl komplett abgeschaltet habe und meistens 
eben nur resettet habe.


Aber warum ist das so ???
Nach einem Reset des µC wird doch eine komplette Initialisierung des RFM 
durchgeführt. Somit sollte doch alles IO sein oder nicht ??

Komisch ist auch noch, dass dieser "Fehler" nicht bei jedem Reset 
auftritt.

Ich hänge mal ein paar Screenshots bei.

Der Code von Felix wurde hier weitestgehendst im Originalzustand 
belassen,
ich habe nur zwei Funktionen zur Darstellung von Hex-Werten und die 
UART-Funktion angefügt.

@Gucky: Ein SDR-Stick habe ich mir gestern bestellt. Wird wohl am 
Dienstag eintrudeln. Ist echt eine super Idee, die Module auf diese Art 
und weise zu testen.

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

eine Initialisierung des RFM ist kein Reset des selbigen. Ich hab mir da 
auch schon einen Wolf gesucht. Auch wenn das bei Dir jetzt nicht das 
Problem sein sollte, ich habe den Listend-Mode verwendet um Strom zu 
sparen. Der lässt sich nur durch eine bestimmte Bitkombination der 
Betriebsart deaktivieren, macht man am μC einen Reset hängt das Programm 
dann wenn man z.B was senden will.

Sascha

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Mir ist noch etwas aufgefallen, nach einer gewissen Zeit verlieren die 
beiden Module die Verbindung, diese kommt dann auch nicht mehr von 
allein zustande...
Nach einem Reset des µC funktioniert alles wieder super.

Kann sich das jemand erklären ?
Der Code ist der von Felix mit den Ergänzungen in main() wie auf dem 
Bild 2 Threads zuvor zu erkennen.

Noch eine Anmerkung am Rande:
Irgendwo in diesem Thread habe ich gelesen, dass die 10-fache Ausführung 
der Initialisierung nicht benötigt wird bei den RFM69-Modulen. Naja, 
dass kann ich so nicht bestätigen. Ich habe in meinem abgeänderten Code 
die Schleife raus genommen. Ergebnis auf einem RFM69 wurden die Register 
nicht richtig gesetzt auf einem 2 mit dem selben µC(habe ihn hin und her 
getauscht) jedoch schon...

Hat ein Weilchen gedauert bis ich das bemerkt habe.

Ob es nun wirklich 10 Durchläufe sein müssen weiß ich nicht, aber frisst 
ja auch kein Brot :-)

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Die fehlende Möglichkeit, einen Software-Reset durchzuführen, ist bei 
allen sonstigen Vorteilen neben dem Wake-Up-Timer eine große 
Schwachstelle des RFM69 gegenüber seinem Vorgänger RFM12.

Wenn man beim RFM69 resetten will, muss man wohl einen Portpin am 
Controller opfern, eventuell könnte es (nicht ausprobiert) auch 
funktionieren, wenn man den Reset-Pin mit dem Chip-Select kurzschließt:
Man müsste die Leitung dann mit einem externen Pullup versehen (mache 
ich beim Chip-Select eh immer) und könnte sie im Normalbetrieb bei nicht 
gesetztem PORT-Register mittels DDR-Register zwischen Eingang 
(hochohmiges High, führt wie weiter oben beschrieben nicht zum Reset und 
lässt den Chip deaktiviert) und Ausgang (low, aktiviert den Chip, Reset 
sollte laut Datenblatt ebenfalls ausbleiben) hin und her schalten. Will 
man einen Reset durchführen, aktiviert man zunächst bei nicht gesetztem 
DDR den internen Pullup und setzt anschließend das DDR auf Ausgang. 
Vielleicht mache ich da auch einen Denkfehler, aber das könnte man mal 
versuchen.

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin nun wieder ein Stück weiter gekommen. Dank des heute 
eingetroffenen SDR Dongels konnte ich einige Messungen durchführen. 
Hierbei ist aufgefallen, dass eines der beiden Module erheblich weniger 
Sendeleistung hat als das andere. Es sei angemerkt, dass die 
Konfiguration gleich ist. Wird wohl irgendwas mit der Antenne nicht 
stimmen. Des weiteren habe ich festgestellt, dass die Module bei 
gleicher Einstellung auf unterschiedlichen Frequenzen senden. Habe dazu 
auch einen interessanten Artikel gefunden:
ukhas.net/wiki/ideas:rfm69_frequency_trimming
Liegt wohl an den ungenauen internen Quarzen... Kommt mir irgendwie von 
den AtMegas bekannt vor 😀
Nun die Frage hierzu: macht es Sinn, dass die Sendefrequenzen von zwei 
Module gleich sind ?
Kommt es hierbei nicht zum Übersprechen ?
Bei Zwei Modulen kann dies nicht passieren, da sie eh jeweils nur senden 
oder empfangen können. Aber was ist wenn mehrere Module ins Spiel kommen 
?

Persönlichen Anmerkung:
Vor kurzem hat es mich echt genervet, dass ich die Module nicht ans 
Laufen gekriegt habe, aber dank des Forums habe ich viel guten Input 
bekommen... Sodass das Basteln am Ende richtig Spaß gemacht hat.
Der Hinweis auf die Analysemöglichkeit via SDR war dann der letzte 
Schliff.
Denke das ich dank der vielen Tips, am Ende des nächsten Wochenendes 
zwei lauffähige RFM69-Module haben werde.

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Nun die Frage hierzu: macht es Sinn, dass die Sendefrequenzen von zwei
> Module gleich sind ?
ja, denn auf der selben Frequenz empfängt das Modul ja auch
Eine gewisse Abweichung der Sendefrequenz durch Exemplarstreuung ist 
kein Problem da die Module beim Empfang eine AFC haben die die 
Empfangsfrequenz an die des gesendeten Signals anpasst.

> Kommt es hierbei nicht zum Übersprechen ?
du kannst ja eh nur Halpduplex machen

> Bei Zwei Modulen kann dies nicht passieren, da sie eh jeweils nur senden
> oder empfangen können. Aber was ist wenn mehrere Module ins Spiel kommen ?
wenn du die Daten unter mehr als zwei Modulen verteilen willst kann 
trotzdem nur eins senden. Ist bei WLAN nicht anders.

Sascha

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Nun noch eine kleine Zusammenfassung meiner Erfahrungen.

Endlich habe ich eine Verbinung zwischen 2 RFM69-Modulen zustande 
bekommen.
Hauptproblem war die 3.3V-Spannungsversorgung des RFM.
Dies wollte ich umgehen, indem ich sowohl den µC als auch den RFM mit 
3.3V betreibe. Setup waren 2 Breadboards-> eines mit externer 
Spannungsversorgung und eines habe ich direkt über mein STK500 versorgt.
das STK500 lässt sich unter Linux mittels avrdude auf 3.3V runterregeln.
Nun musst ich leider feststellen, das diese Einstellung nicht von Dauer 
ist...
Meistens ist das Setting nach dem Einschalten noch vorhanden, jedoch 
NICHT immer grrrrrrrrrrr!!!!

Ich habe auch irgendwo gelesen, dass erst mit 5V eingeschaltet wird und 
dann runtergeregelt. Lange Rede kurzer Sinn: Ich habe mir ein RFM nach 
dem nächsten zerschossen und es zunächst auch nicht gemerkt. Erst als 
ich mir bei jedem Einschaltvorgang alle Register anzeigen lassen habe 
und diese auch regelmäßig verglichen habe; ist aufgefallen, das 
regelmäßig Müll in die Register geschrieben wurde(komischerweise hat 
meistens das letzt Bit gefehlt).

Der Code war also in Ordnung und ich hatte ein Hardwareproblem. 
Blöderweise habe ich den Fehler die ganze Zeit im Code gesucht.

Lösung war nun die Versorgung beider µC und RFMs mit einer externen 
Spannungsversorgung.
Ich wollte es nun aber gleich "richtig" machen. Also habe ich eine 5V 
Primär-Versorgung gewählt(später soll diese durch eine Powerbank ersetzt 
werden somit sind 5V sehr vorausschauend).

Die Spannungsversorgung der RFMs habe ich von 5V auf 3.3V mit dem 
LD1117V33 runtergeregelt.
Die logischen Eingänge des RFM habe ich mit dem 5V-toleranten CD74HC4050 
Logikbuffer beschaltet.
Den MISO habe ich direkt auf den µC gelegt.

Simsalabim: Es läuft.

Nun stehe ich nur noch vor einem Problem:
Wenn ich die Spannungsversorgung einschalte, senden die Dinger 
gleichzeitig.
Entsprechend Empfangen sie auch gleichzeitig, wenn der selbe Code 
ausgeführt wird.
Ich schalte einen von beiden µC aus und wieder an und dann läuft es 
auch.
Wie kann man dies nun eleganter lösen ?
Ich hatte über die Generierung einer Pseudozufallszahl nachgedacht und 
diese dann in eine delay-Funktion reinpacken.
Wirkt aber irgendwie gebastelt...

Besser wäre doch der Ansatz: Lausche ob die Frequenz frei ist falls ja 
sende, falls nein warte x und prüfe erneut.
Hat schon jemand so etwas implementiert ?


Gibt es vielleicht noch eine bessere Lösung ?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Besser wäre doch der Ansatz: Lausche ob die Frequenz frei ist falls ja
> sende, falls nein warte x und prüfe erneut.
> Hat schon jemand so etwas implementiert ?

habe jetzt nicht alles hier mitgelesen, benutzt du die lowPowerLab RFM69 
lib? Das Lauschen vor dem Senden nennt sich CSMA und das ist in der Lib 
in einfacher Form implementiert.

Welche Software benutzt du mit dem SDR Stick? Ich habe da SDRSharp, aber 
die gesendeten Pakete sind sehr kurz und da kaum zu sehen. Oder ist das 
eine Einstellung?

Ich habe auch gerade einen Empfänger mit RFM59 am Laufen und ein Display 
zur Anzeige von empfangenen Nachrichten dran. Das läuft so vor sich hin 
und ich habe jetzt schon ein paar mal fremden Funk empfangen, ich meine 
auch mehrmals von/an den gleichen Node. Wie robust sind die RFM gegen 
Störungen? FS20 nutze ich auch noch, aber das läuft ja mit ASK und 
sollte keine gültigen Pakete im RFM erzeugen. Ein Encryption Key ist 
auch gesetzt, werden Pakete auch empfangen und weitergeleitet wenn der 
Key nicht übereinstimmt?

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Ich hatte über die Generierung einer Pseudozufallszahl nachgedacht und
> diese dann in eine delay-Funktion reinpacken.
> Wirkt aber irgendwie gebastelt...

Nö, das ist gar nicht gebastelt. Nur delay muss nicht grad sein. Lieber 
einen Timer-Int von 1ms laufen lassen und eine "zufällige" Zahl von 1ms 
lang abwarten, also einen Counter in der Int-Routine hochzählen, das 
sind die ms seit Start.
Hab ich immer in jedem uC-Programm.

Alternativ zur Zufallszahl gibst Du jedem Modul eine "Node ID" (haben 
sie das nicht sowieso damit Du weisst von wem es kommt?) und die benutzt 
Du zur Berechnung einer Verzögerung nach Start. Also Node-ID x 10ms oder 
sowas.

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> habe jetzt nicht alles hier mitgelesen, benutzt du die lowPowerLab RFM69
> lib? Das Lauschen vor dem Senden nennt sich CSMA und das ist in der Lib
> in einfacher Form implementiert.

Ich habe meine eigene Lib geschrieben, da ich Kommunikation wirklich 
verstehen wollte... Diese orientiert sich aber recht stark an der Lib 
von Felix Pflaum


> Welche Software benutzt du mit dem SDR Stick? Ich habe da SDRSharp, aber
> die gesendeten Pakete sind sehr kurz und da kaum zu sehen. Oder ist das
> eine Einstellung?

Ich verwende gqrx, da ich Linux im Einsatz habe. Sotte SDR# aber recht 
ähnlich sein. Unter Gqrx ist es möglich in ein Frequenzband 
"reinzuzoomen".
Im Wasserfalldiagramm kann man recht schön sehen, wie sich die Signale 
überlagern.

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Conny G. schrieb:
> Nö, das ist gar nicht gebastelt. Nur delay muss nicht grad sein. Lieber
> einen Timer-Int von 1ms laufen lassen und eine "zufällige" Zahl von 1ms
> lang abwarten, also einen Counter in der Int-Routine hochzählen, das
> sind die ms seit Start.
> Hab ich immer in jedem uC-Programm.
>
> Alternativ zur Zufallszahl gibst Du jedem Modul eine "Node ID" (haben
> sie das nicht sowieso damit Du weisst von wem es kommt?) und die benutzt
> Du zur Berechnung einer Verzögerung nach Start. Also Node-ID x 10ms oder
> sowas.

Nette Idee !!
Probiere ich bei Zeiten mal aus.

Danke!

Ist bestimmt leichter zu Implementieren als CSMA/CD.

von Alexander Graf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ben schrieb:
> Code rauszuschreiben ist nicht ganz so einfach, da das Projekt mit einem
> CortexM3 umgesetzt wird und die Einstellungen eher weiter verteilt sind.
>
> Daher habe ich einen Plot von der SPI Kommunikation gemacht.

Auch wenn es jetzt über ein Jahr her ist, traue ich mich mal auf diesen 
Post zu antworten.

Für alle, die Probleme bei den Registerzugriffen haben; insbesondere mit 
STM32 Controllern: Das SPI Timing des SX1231 bzw. RFM69 ist etwas 
ungewöhnlich. Der Chip Select Pin muss noch bis NACH der letzten 
steigenden Clk-Flanke (und einige Zeit darüber hinaus) low gehalten 
werden. Das macht der SPI-Master des STM32F4 z.B. nicht. Man muss 
manuell den Chip Select bedienen und das Timing sicherstellen, da dieser 
sonst bereits vor der letzten steigenen Flanke CS loslässt.

Bei derartigen Problemen unbedingt im Datenblatt des SX1231 nochmal das 
Timing ansehen. Der von @Ben gezeigte Waveform-Mitschrieb zeigt ein 
falsches Timing. Das führt unter anderem dazu, dass man aus Registern 
lesen kann, aber nicht schreiben. Beim Fifo Register ist dieses 
Verhalten nach meinen Nachforschungen sogar abhängig vom aktuellen Mode.

von Andreas (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche mit dem RFM69HW einen Garagentor Sender nachzubauen.
Gesendet wird mit OOK. Mit dem (abgeänderten) Code von Felix 
funktioniert es soweit. Allerdings scheint der RFM69 immer ein einzelnes 
bit '1' vor meinen Daten zu senden, was ich mir nicht erklären kann!

Geändert wurde der Code (alles im Anhang):
- Unlimited length Packet (d.h. fixed length = 0)
- sync byte 0x49  ==> |0100|1001|, Keine Preambel.
- Max array size 60
- PA1 output

Empfangen wurde mittels SDR und ausgewertet mit baudline ==> siehe 
Anhang.

Gesendet werden sollte eigentlich
   |01001001|01010001|00101010|.....|00000000|
Empfangen wurde aber:
  1|01001001|01010001|00101010|.....|00000000|

Probiert habe ich auch zuerst Tx-on, dann Fifo füllen, jedoch mit 
gleichem Ergebnis.
Hat jemand schon ähnliches beobachtet?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Eine direkte Antwort habe ich nicht, ich habe mit dem RFM69 aber schon 
FS20 OOK gesendet/empfangen. Dazu habe ich den continous mode und den 
DATA Pin über DIO2 benutzt.

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier ein total seltsames Phänomen.

Mein RFM69 funktioniert nur ohne GND.
Ja... genau wegen diesem Grinse hatte ich lange überlegt ob ich das 
überhaupt posten soll.

Ich bin sogar soweit gegangen jeden der beiden GND-Pins auf je einen 
Jumper zu legen um zu test ob es nur an einem liegt.

Fehlanzeige! Das Modul funktioniert nur dann, wenn ich beide Jumper 
entferne.
Komischerweise funktioniert es wirklich. Es sendet und empfängt wie eine 
eins :-)

Und ja, ich habe bereits mehrere Module ausprobiert.

Hatte schon mal jemand ein derartiges "Problem" ?

Kann sich jemand einen Reim drauf bilden ?

von Klaus I. (klauspi)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Ich habe hier ein total seltsames Phänomen.
>
> Mein RFM69 funktioniert nur ohne GND.
> Ja... genau wegen diesem Grinse hatte ich lange überlegt ob ich das
> überhaupt posten soll.

Zu Recht :oD
Irgendetwas ist hier sehr kurios, zeig mal ein paar aussagekräftige 
Photos und Schaltpläne von Deinen Aufbauten.

Dir geht es hier aber nicht um die Beschaltung vom Reset des RFM69CW, 
oder?

von Andreas S. (andy7683)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem ich mein 0.96" Display ans Laufen bekommen habe, habe ich mich 
heute mal wieder um das RFM96HW-Modul gekümmert.

Es hat sich herausgestellt, dass das Problem irgendetwas mit der 
Spannungsversorgung zu tun hat.

Wenn ich als Spannungsversorgung ein Labornetzteil verwende, dann 
funktioniert alles super.

Wenn ich jedoch eine 5V Powerbank verwende, dann bleibt das Controller 
stehen, sobald ich versuche in ein Register des RFM zu beschreiben.

Entferne ich die Jumper 2 und 3, dann startet auch der Controller ab und 
zu ordnungsgemäß und ich kann die geschrieben Register des RFM auch 
wieder zurücklesen.

Also wie gesagt: Alles recht komisch.

Die Schaltung habe ich zur Zeit auf einem Steckbrett aufgebaut.

Was zu Henker kann das sein ?

Ich habe auch mal ein kleines Video des Ganzen auf Youtube hochgeladen:
Youtube-Video "RFM69 startet nicht mit GND"

: Bearbeitet durch User
von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
So,
ich konnte das Problem weiter eingrenzen.

Die Kalibrierung des RC Oszilators funktioniert nicht.

Wenn ich das Register 0x0A mit 0x80 beschreibe, dann bekomme ich nur 
0x00 als Antwort zurück, wenn ich das Register auslese.

Sobald ich aber die GND-Jumper entferne, bekomme ich ein 0x40 zurück und 
alles läuft.

Kann sich jemand erklären warum das blöde Teil nicht anfängt zu 
schwingen ?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Was ist denn mit dem Reset am RFM? Der Jumper sollte offen sein.
Dieses GND Problem ist auch komisch, ich habe die hier auch in Betrieb 
und so angeschlossen wie es soll. Da solltest du nochmal den Steckbrett 
Aufbau kontrollieren. Oder ein Foto posten.

von Andreas S. (andy7683)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem ich nun die Kalibrierung des RC-Oszilators und den 
anschließenden Wechsel in den Standby-Modus raus genommen habe, bekomme 
ich die geschrieben Register angezeigt.

Resultat:
ist GND angeschlossen steht da nur Müll drin.

Klemmt man GND ab sind die Register geschrieben wie gewünscht.

Echt komisch und wirklich nicht zu erklären.

Falls das Modul kaputt wäre, würde doch gar nix mehr aus den Registern 
rauskommen bzw. rein gehen oder ???

Kann mir mal jemand einen Beispiel von einem Testaufbau zukommen lassen 
?
Ich zweifel so langsam an mir.

Werde morgen mal ein neues Modul testen...

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Kannst du selber etwas auf der verwackelten unscharfen Aufnahme 
erkennen?
Also mir fehlt da als erstes die +3,3 V links oben.

von umpfgr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
So ein paar Gedanken dazu:
1) fehlende Abblock Kondis beim uC und beim Level-Shifter
2) Brown-Out-Detection beim uC gesetzt?
3) durch den 10uF beim 3.3V Regler startet der RFM möglicherweise später 
als der RFM ==> ggf. etwa 50ms im uC Code warten, dann erst den RFM 
schreiben/lesen.

von Andreas S. (andy7683)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So langsam wird es echt hoffnungslos...

Folgendes habe ich getestet:
-"alter" RFM69-HW; ATMega8A und alles auf 3.3V
-"alter" RFM69-HW; ATMega328P und alles auf 3.3V
-"neuer" RFM69-HW; ATMega328P und alles auf 3.3V

Somit habe ich ein Problem des µC ausgeschlossen.
Durch rausschmeißen der Logik-Buffer und die Versorgung mit 
ausschließlich 3.3V können nun auch an dieser Stelle keine Fehler 
auftreten.

Ich habe die Schaltung sowohl mit als auch ohne Kondensator am Reset 
getestet.

Anbei ein paar Bilder vom Steckbrett, die Bildschirmausgabe mit und ohne 
GND.
Meinen Code habe ich auch angehängt.

Schon mal vorab Danke für eure hilfe.

Bin schon am überlegen ob ich ohne GND initialisiere und dann später die 
GND dazuschalte. Ist aber total hässlich und es muss ja einen Grund 
haben warum der Sch... nicht funktioniert.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Da bleibt noch die Software. Und wie hoch ist der SPI Takt? Ist der 
vielleicht zu hoch?

ok, Code ist angehängt, hatte ich auf dem Smartphone übersehen. SPI init 
sieht für mich auch ok aus.

Hast du mal die GND pads gegen die Nachbarn auf Kurzschluss gemessen? Im 
gesteckten Zustand, nicht das das Steckbrett eine Macke hat?

: Bearbeitet durch User
von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Es ist kein direkter Durchgang zu messen.

Komisch ist auch, dass der RFM sporadisch startet. Wenn ich das Netzteil 
ein und Aus schalte, dann ist ca. jeder 10 Vorgang erfolgreich.

von Andreas S. (andy7683)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Fehler nicht gefunden.

Da der Controller sporadisch startet, habe ich den Startvorgang mit 
einem Watchdog versehen. Nachdem der RFM69 initialiert wurde, wird der 
Watchdog wieder deaktiviert.

Echt keine tolle Lösung, aber es funktioniert.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Ich war da fauler und habe die lowpowerlabs Lib benutzt: 
https://github.com/LowPowerLab/RFM69/blob/master/RFM69.cpp
Da wird im init erst das syncvalue register gesetzt und mit Timeout 
rückgelesen. Das ist da sicher auch nicht ohne Grund drin, obwohl ich 
sowas auch nicht im DB gefunden habe.
In deinem Code wird das Init 5 mal ausgeführt, war das so beabsichtigt 
oder sollte nur das Delay 5 mal 50 ms betragen?

von Katatafisch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich grüble derzeit über eine Realisierungsmöglichkeit eines 
Sensornetzwerks auf Funkbasis. Funk, weil ein Sensor durch 2 
Stahlbetondecken durch funken muss und per Batterie versorgt werden 
muss.

Das RFM69CW scheint da ein günstiger Kandidat zu sein.
Würde jemand mit Erfahrungen mit dem Modul mir von der Idee abraten? :-)

Johannes S. schrieb:
> Ich war da fauler und habe die lowpowerlabs Lib benutzt:
> https://github.com/LowPowerLab/RFM69/blob/master/RFM69.cpp

Er hier hat die Lib übrigens in C konvertiert:
https://github.com/cristi85/RFM69

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Die RFM69 funktionieren einfach und gut, auch wenn Andy in den Postings 
hier vor Probleme damit hat(te). Ich habe ein paar Nodes die seit ein 
paar Wochen im Test laufen. Davon auch einer mit PIR Sensor im 
Batteriebetrieb, im Schlafmodus zieht der RFM ja weniger als 1 µA. Durch 
den grossen Fifo sind die auch angenehmer zu programmieren als die 
RFM12. Ich habe die 868 MHz und hier wenig Störsender in der Umgebung, 
eventuell ein Funksender von Nachbars Garagentor. Ich glaube das bekomme 
ich auch auf wenn ich das mitprotokoliere :-) Sicherheit bleibt da 
vielleicht ein Nachteil, das Tor von deinem Raptorengehege solltest du 
nicht damit steuern. Da ist zwar Verschlüsselung AES-128 drin, aber die 
lässt sich vermutlich knacken wenn die Pakete geloggt werden. Ich habe 
jedenfalls auch gelegentlich Mülldaten mit geringer Feldstärke 
empfangen, es sieht so aus als ob trotzdem Daten geliefert werden auch 
wenn der Schlüssel nicht passt.
Die C-Implementierung wäre ein Rückschritt für mich weil ich eine mbed 
Portierung verwende und mbed ist eine C++ lib. Der lowpowerlabs Code von 
Felix Rusu ist aber weit verbreitet und es gibt viele Portierungen, auch 
auf meinem RasPi als Gateway läuft der auf der RFM Seite.

von Katatafisch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Johannes: Danke für die Erfahrungswerte und die Infos.

Dann werde ich demnächst mal zwei, drei Module bestellen und testen.

Die C-Portierung ist in soweit für mich relevant, da ich noch einige 
ATtiny 861 Controller hier liegen habe, welche ich für die Nodes 
einsetzen möchte.

Als Basis stelle ich mir auch als langfristige Lösung einen Raspberry Pi 
vor.

Die Verschlüsselungen sind ja fast alle knackbar. Es kommt immer auf die 
Rechenleistung an, welche dem Angreifer zur Verfügung steht.
So war vor paar Jahren AES-128 mal sicherer als Heute.
Natürlich wird auch manchmal einfach ein Sicherheitsloch gefunden, wie 
beim CSS zum Beispiel.

von Conny G. (conny_g)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Katatafisch schrieb:
> Dann werde ich demnächst mal zwei, drei Module bestellen und testen.
>
> Als Basis stelle ich mir auch als langfristige Lösung einen Raspberry Pi
> vor.

Ich habe das genau so gemacht und bin sehr zufrieden mit dem RFM69. 
Vorher mit dem RFM12 hatte ich sehr mit der Reichweite zu kämpfen und 
musste mir für die Basisstation eine Biquad-Antenne machen, die die 
Clients im Garten erreicht.
Mit dem RFM69 alles gegessen, mit der Standard-Stabantenne eine 
Reichweite von wenigstens 150m draussen, durch die Hausmauer/Fenster.
Ein "Client" zickt, aber ich denke das liegt daran, dass das das eine 
Art Funksteckdose ist und das Netzteil 3cm daneben zu sehr stört.

Habe mir für den Raspberry Pi ein Atmega328 + RFM69 "Hat" gemacht, 
kommunizieren seriell mit einem simplen Text-Protokoll. Sh. Foto.
(Ja, der Micromatch ist etwas angekokelt, da habe ich beim 
Heissluft-Reflow des Prototypen zuviel Gas gegeben.)
Ein Platz für einen 433 Mhz-Sender ist auch drauf, zum Ansteuern von 433 
Mhz Funksteckdosen.
Der Hat läuft seit 1 Jahr problemlos, hatte vorher eine entsprechende 
Breadboard-Schaltung mit RFM12, lief auch schon 1-2 Jahre problemlos 
(abgesehen von den Reichweiten-Problemen).

Auf dem Raspberry Pi läuft dann ein simpler Python-basierter Webserver, 
der HTTP-Befehle entgegennimmt und dann über das RFM rausfunkt oder über 
Apple Homekit etwas arrangiert, was auch immer.
Und es läuft eine NodeJS basierte Homekit-Bridge, die alle Geräte per 
Apple iOS verfügbar macht.
Das ist es:
https://github.com/KhaosT/HAP-NodeJS

Über die serielle Schnittstelle werden auch eingehende Funknachrichten 
angenommen, also was die Clients zurücksenden.
Und dann z.B. in eine Web-IoT-DB geschrieben für Temperaturverläufe etc.
Das RFM-Protokoll habe ich in ein redundantes Protokoll eingepackt, dass 
Prüfsummen mitsendet und Pakete bis zu 5x wiederholt, wenn kein ACK der 
Gegenstelle kommt. Kann zwar das RFM69 auch (zumindest die Prüfsumme), 
aber ich hatte das ja vom RFM12 eh schon.

Dafür braucht es einen Quadcore Raspi, NodeJS braucht viel Ressourcen.
Sonst braucht die Antwort auch mal ein paar Sekunden.

: Bearbeitet durch User
von Tsmeey (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ein sehr interessanter Thread!
Auch wenn, das Thema inzwischen ausläuft, möchte ich noch eine Frage in 
die Runde werfen:

Ich würde gern die Funktion SYNC_WORD (Register 2E) in Verbindung mit 
LISTEN (0D)verwenden. (Ich verwende keine 12er nun 69Wer)
Zunächst versuche ich ein Sync_Word_Match hinzubekommen. Das 
funktioniert nicht.
Lasse ich bei PayloadReady am DIO0 einen INT auslösen und gehe in die 
RX-Routine, funktioniert das. Senden und Empfangen funktioniert also 
grundsätzlich, wenn Daten vorhanden sind.

Ich beschreibe die Register:
RegSyncConfig (2E) mit C8:
SyncOn,
FifoFillCond, weil ich KEIN SyncAddress, sondern nur SyncWord verwende,
SyncSize 0bxx001xxx (000 -> Byte 1, 001 -> Byte 2)

Byte 1 Soll Gruppe sein also z.B. 100, Byte 2 soll ID sein also z.B. 5. 
RegSyncValue1 wäre somit 100 und RegSyncValue2 dann 5.
Beide Werte werden sowohl in Sender wie auch in Empfänger geschrieben.

Die (auf fixe Payloadlänge (RegPacketConfig (37)) eingestellte) 
RegPayloadLen (38) beträgt 5 Byte und beinhaltet nur die eigentlichen 
Daten, kein SyncWord, keine Länge, kein CRC.

RegDioMapping (25) setze ich auf 80 -> DIO0 = SyncAddress.

Ich denke, es sollte so ablaufen:
Sender: 01010101 -> 100 , 5 , Payload....
Empfänger : 0101010 -> 100, 5 -> SyncMatch -> lade FIFO -> löse INT am 
DIO0 aus.

Habe ich ein Register vergessen? Einen falschen Gedanken?
Es scheint kein SyncWord erkannt zu werden. Im Thread wird 2D D4 
verwendet, aber scheinbar nicht ausgewertet. Die Beiden Bytes sind eher 
zufällig ?

Hat jemand eine schicke Idee oder ein brauchbaren Verweis auf die Doku ?

Gruss
Christian

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

Tsmeey schrieb:
> Im Thread wird 2D D4
> verwendet, aber scheinbar nicht ausgewertet. Die Beiden Bytes sind eher
> zufällig ?
Die beiden Bytes 0x2D und 0xD4 stammen aus RFM12-Zeiten, da waren sie 
als Sync-Word fest vorgegeben und nicht frei konfigurierbar. Da ich 
beide Module in einem Netzwerk verwende, musste ich also die RFM69 auch 
auf diese Werte einstellen.

Und natürlich werte ich die beiden Bytes aus: Indem das Bit 
FifoFillCondition  im Register 0x2E auf 0 gesetzt wird, werden Daten 
ignoriert, wenn nach der Präambel nicht das korrekte Sync-Word erkannt 
wird. Dass der Interrupt SyncAddress-Interrupt heißt, ist 
missverständlich, vielleicht liegt hier auch dein Problem. 
Möglicherweise wird mit FifoFillCondition=1 einfach nie ein 
Sync-Interrupt ausgelöst.

: Bearbeitet durch User
von Steffen H. (Firma: www.shotech.de) (mc_sho) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
mein Design mit dem RFM69CW-868 Modul habe ich jetzt auch soweit fertig 
und im Test laufen. Derzeit im Keller, Wohnung und Balkon ohne Probleme.
Derzeit sind die Module nur für 868MHz vorgesehen. Ein neues Design mit 
315MHz bis 915MHz ist in Produktion. Die Leiterplatte wird dann aber um 
6,2mm länger da die Anbindung der Multibandantenne mehr Platz benötigt. 
Die derzeitigen Module mit Cortex-M0+ , RFM69CW, Current-Monitor und 
Antenne sind nur 31mm x 26,26mm. Die Multibandmodule sind dann 37,2mm x 
26,6mm.

Das jetzige RF-Sensor Design mit BME280 ( Bild: SPIRIT_Sensor_BME280 ) 
läuft noch mit dem Spirit1 Modul von ST. Nach dem jetzigen Test werde 
ich die aber auf die RFM69CW umstellen.

Die Software habe ich von https://github.com/cristi85/RFM69 genommen. 
Leider waren da noch einige Fehler enthalten, aber jetzt funktioniert 
das soweit und ich habe die Software auf den Cortex-M0+ angepasst.

Aktuell schreibe ich an dem Bootloader, mit dem dann ein Update über 
Funk möglich ist, oder halt über RS232-TTL. Die Erkennung erfolgt 
automatisch.

Die Software werde ich freigeben sobald alles funktioniert. Da ich mit 
dem IAR Compiler arbeite, suche ich noch jemand, der mir das auf den GCC 
anpasst. Module würde ich zur Verfügung stellen.

von Abdul K. (ehydra) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Respekt, schöne Fotos, schönes Platinenlayout. Wenn deine Software 
genauso aussieht, biste ein echtes Vorbild!

von Tsmeey (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Felix,

danke für die Antwort.
In der Tat bin ich vielleicht einem Gedankenfehler unterlegen.

In den Dox stand, dass sich SyncWordMatch UND SyncAddressMatch das 
Interrupt-Flag SyncAddress teilen.
Ich bin daher davon ausgegangen, dass SyncWordMatch ein Interrupt 
auslösen muss.
Da aber OHNE SyncWordMatch gar kein PayLoadReady erfolgen kann, lässt 
sich auch einfach der PayloadReady-Interrupt am DIO0 nutzen ;)
DAS Problem ist somit zwar umgangen, aber gelöst :)



Nun hänge ich aber am Listen-Modus fest. :/

Ich schalte den RFM69 in ListenModus:
1) STDBY
2) ListenMode | STDBY

Zu Testzwecken habe ich das Zeitfester für RX im RegListen1 bereits im 
mS-Bereich. (~40mS RX, ~100ms Idle) Gesendet werden jede Sekunde 5 Byte.

Trotzdem kommt nicht ein Packet an.
Crieria ist nur RssiTreshold. Rssi-Schwelle wird auch sicher 
überschritten. (mit RegRssiValue ausgewertet)

Ich gehe davon aus, dass zwischen den Idles im RX-Modus dann das gesamte 
Packet eingelesen wird und im FIFO steht.
Ich breche daher den ListenModus in 2 Schritten ab.
1) Abort & STDBY
2) STDBY
(Auch mit RX statt STDBY probiert)

Aber bereits zuvor sollte ein Interrupt wegen PayloadReady ausgelöst 
werden, oder nicht ?
Aber es löst kein Interrupt aus.

Meine möglichen Erklärungen:
1) In der RX-Phase wird das Paket nicht erkannt, obwohl RSSITheshold 
erreicht
2) In der RX-Phase wird das Paket nicht eingelesen, ein zweiter Step mit 
Paket lesen muss folgen
3) Der FIFO wird aus irgendeinem Grund geleert bevor ich die Daten lesen 
kann.

Trotz dieser möglichen Erklärungen erhalte ich auf keinem von mir 
versuchten Lösungsweg einen PayloadReady Interrupt.

Ich fürchte, dass Problem liegt ganz woanders. Hast Du dafür noch ein 
Tip?

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
Ohne deinen Code zu sehen, ist die Diagnose schwierig, zumal ich mit dem 
ListenMode bisher keine praktische Erfahrung habe. Wenn ich dich richtig 
verstehe, funktioniert der PayloadReady-Interrupt, wenn du dauerhaft im 
Rx-Modus bist, so dass der Fehler definitiv irgendwo im Bereich "Listen 
Mode" zu suchen ist?

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Felix,

zum Listenmode

innerhalb der 40ms (bei Dir) muss Präambel, Syncword und evl. Adresse 
erkannt werden.
Da der Sender ja nicht weiß wann der Empfänger gerade Bereit ist, musst 
du beim Sender das Paket entsprechend oft, möglichst ohne Pause, 
wiederholen. Auch sollte das erste Paket möglichst kurz sein. Die aktive 
Zeit des Empfängers muss immer mindestens so lang sein wie das Paket das 
erkannt werden soll + 2x Präambel + Syncword + (Adresse) und noch etwas 
Reserve.

Sascha

von Tsmeey (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tach Felix,

sorry, bei mir hat es etwas gedauert. Und ja, Du hast mich richtig 
interpretiert.

Ich könnte Dir jetzt 400 Zeilen Code schicken, aber ich glaube, dass 
hilft jetzt auch nicht wirklich?!
Ich sehe aber ein, dass ein von Dir in die Glaskugel schauen auch nicht 
hilft ;)

Der Vorschlag von Sascha, einfach, wie effektiv, scheint mir zunächst 
interessant. Einfach mal den Empfänger richtig zutexten um zu sehen, ob 
der Bursche denn auch hinhört ;)

@Sascha: aber ich verstehe das doch richtig, dass der Empfänger in der 
"Wachphase" das ganze Packet einliest und in den FIFO schreibt, nicht?
Und nicht, dass in der Wachphase nur der Sync erkannt wird und ich 
aktiv, das Datenpaket durch ein Umstellen auf von Listen auf RX nochmals 
einlesen und deshalb absichtlich mehrfach senden muss?

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Tsmeey schrieb:
> Tach Felix,
>
> @Sascha: aber ich verstehe das doch richtig, dass der Empfänger in der
> "Wachphase" das ganze Packet einliest und in den FIFO schreibt, nicht?
> Und nicht, dass in der Wachphase nur der Sync erkannt wird und ich
> aktiv, das Datenpaket durch ein Umstellen auf von Listen auf RX nochmals
> einlesen und deshalb absichtlich mehrfach senden muss?

Also beim RFM69 kann man ja einstellen was den Listenmode beendet <rssi> 
oder <rssi & sync>. M.M. nach sollte er das Paket nach dem erkennen der 
Abbruchbedingung auch einlesen. Lässt sich natürlich schlecht 
feststellen ober er dann doch erst das nächste Paket in den Puffer 
einliest. Auf jeden Fall braucht man zum Empfang des Pakets den 
Listendmode nicht beenden, hab ich bei mir schon so verwendet. Beim 
RFM22 war das im Datenblatt irgendwie genauer beschrieben.
Aber es ändert trotzdem nichts daran das der Sender mindestens so lange 
senden muss das die Empfangspause überbrückt wird. Es sei denn du 
könntest Empfänger und Sender so genau syncronisieren das der Sender auf 
die ms genau weiß wann der Empfänger bereit ist.

Sascha

von Christian D. (christian_d347)


Bewertung
0 lesenswert
nicht lesenswert
Moin Sascha,

das mit rssi & sync hatte ich gelesen, trotzdem danke für den Hinweis.

Wenn Du Dir sicher bist, dass ich den Listen-Mode nicht beenden muss, 
ist das schon mal ein guter Hinweis.

Denn in der Beschreibung unter RegListen1  Bits 2-1  ListenEnd ist das 
nach meiner Auffassung ziemlich widersprüchlich beschrieben. "Listen 
mode stops and must be disabled..."

Kannst Du Dich entsinnen welchen Mode Du eingestellt hast? Mir erscheint 
ja 10 (... stays in Rx mode... resumes in idle state..." sinnig, wenn 
ich nur periodisch Daten "einsammeln" will.

Ich werde das am WE mal austesten...

tsmeey -> christian

von Christian D. (christian_d347)


Bewertung
0 lesenswert
nicht lesenswert
Sascha W. schrieb:
> Also beim RFM69 kann man ja einstellen was den Listenmode beendet <rssi>
> oder <rssi & sync>

Wobei ich hier allerdings der Meinung bin, dass Listen nicht beendet, 
sondern nur unterbrochen wird.

Wobei das insgesamt schon merkwürdig ist:
Wenn ich ein Idle und ein Rx Zeitfester habe, dann kann ListenCriteria 
vmtl. sowieso nur im Rx-Zeitfenster wirksam sein.
Das wiederum wäre dann aber das "normale" Verhalten im Rx-Modus und es 
erscheint mir fraglich, warum dann extra dieses Kriterieum angegeben 
werden muss ;)

Fragen über Fragen :)

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Christian D. schrieb:
> Moin Sascha,
>
> das mit rssi & sync hatte ich gelesen, trotzdem danke für den Hinweis.
>
> Wenn Du Dir sicher bist, dass ich den Listen-Mode nicht beenden muss,
> ist das schon mal ein guter Hinweis.
also für den Empfang musst du nicht ausschalten, da ich in meiner 
Anwendung jedoch immer eine Bestätigung sende beende ich den Listendmode 
sowieso nach dem Empfang von Hand.

> Denn in der Beschreibung unter RegListen1  Bits 2-1  ListenEnd ist das
> nach meiner Auffassung ziemlich widersprüchlich beschrieben. "Listen
> mode stops and must be disabled..."
>
> Kannst Du Dich entsinnen welchen Mode Du eingestellt hast? Mir erscheint
> ja 10 (... stays in Rx mode... resumes in idle state..." sinnig, wenn
> ich nur periodisch Daten "einsammeln" will.

ich verwende bei mir RSSI&SYNC als Kriterium und 01 als Ende.
Im Mode:
00 geht das Teil nach erkennen der Bedingung auf Dauer RX, wenn kein 
gültiges Paket erkannt wird legt sich's nicht wieder schlafen und man 
merkt davon nichts
01 weckt auf, und wenn kein gültiges Paket erkannt wird kommt ein 
Timeout Interrupt. Ich hab mir Timeout und PayloadRDY auf einen Pin 
gelegt. Bei Timeout beende ich Listend lösche den FiFo und schalte den 
Listenmode wieder ein.
10 sollte auch gehen man muss den FiFo nur schnell genug auslesen, da 
die Daten beim nächsten Paketbeginn gelöscht werden.

> Wobei ich hier allerdings der Meinung bin, dass Listen nicht beendet,
> sondern nur unterbrochen wird.
ja, wenn du eine andere Betriebsart willst musst du immer erst den 
Listenabort machen - sonst macht das Teil gar merkwürdiges.

> Wobei das insgesamt schon merkwürdig ist:
> Wenn ich ein Idle und ein Rx Zeitfester habe, dann kann ListenCriteria
> vmtl. sowieso nur im Rx-Zeitfenster wirksam sein.
genau - in der IDLE-Zeit ist der Empfänger aus, sonst könnte man ja 
keinen Strom sparen

> Das wiederum wäre dann aber das "normale" Verhalten im Rx-Modus und es
> erscheint mir fraglich, warum dann extra dieses Kriterieum angegeben
> werden muss ;)
das macht schon Sinn, er schaut ob in der RX-Phase ausreichend 
Signalpegel vorhanden ist und evl. ob ein Sync gelingt. Trifft die 
Bedingung zu geht er nicht wieder in den IDLE und kann das Paket 
komplett empfangen.

Sascha

von Matthias T. (matthias_199)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich benutze auch das Modul und es funktioniert,
bin aber etwas von der Reichweite und Sendeleistung eintäuscht.

Mache ich etwas Grob Falsch ?

mein RssiThreshold ist -100dbm, Sendeleistung ist 5dbm.

Als Antenne benutze ich eine Ader aus einem Stromkabel auf lambda/4 also 
rund 8,6 cm

und die Module sind nebeneinander (20 cm) und ich hab folgende Rssi 
Werte.(Bild)

Die Reichweite würde ich auf rund 3 meter schätzen.

würde "richtige" Antennen besser funktionieren mit einem Sma Anschluss,

Die sollten ja um einiges besser auf die 50 Ohm abgestimmt sein als mein 
draht Stummel.

Gibt es beim Anschluss Design was zu beachten.
Habe jetzt nur ein so kurz wie mögliche Feedline gewählt, wo dann die 
Antenne aufgelötet wurde,

kann ich später mal Fotos machen.

MFG
Matthias

MFG Matze

von Felix P. (fixxl)


Bewertung
1 lesenswert
nicht lesenswert
Der zweite, oft nicht beachtete Teil einer lambda/4-Antenne ist das 
notwendige Gegengewicht, eine ausreichend (idealerweise "unendlich") 
große Massefläche. Von daher wäre eine "richtige" Antenne mit 
SMA-Anschluss, welche meist als Sperrtopfantenne ausgeführt ist und 
keine zusätzliche Massefläche benötigt, auf jeden Fall anzuraten.

: Bearbeitet durch User
von Matthias T. (matthias_199)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja genau da liegt das Problem.

das wird auf einem Roboter montiert, da sieht das mit so ner 
Sperrtopfantenne echt mieß aus.
Auf meiner Platine habe ich den Fehler schon eingesehen das die 
Massefläche wohl einfach nicht groß genug ist....

Also wenigstens ein 2 Layer bord und ein Layer sozusagen nur masse wäre 
doch das mindeste was ich optimieren könnte sehe ich das richtig ?

oder vielleicht ein ein Metallgehäuse für die Platine das auch auf Masse 
hängt?

und vielleicht so eine Antenne ?

http://de.rs-online.com/web/p/telemetrieantennen/7934363/

MFG Matze

: Bearbeitet durch User
von Matthias T. (matthias_199)


Bewertung
0 lesenswert
nicht lesenswert
Kleine nachfrage dazu,

ich habe mal den 300kbps modus aus Interesse probiert.

Hier nimmt der dbm Wert drastisch ab, ist das normal so ?
Das Modul generiert doch quasi das gleiche Feld mit gleicher 
Feldstärke...

MFG
Matze

von Fabian F. (fabian_f55)


Bewertung
0 lesenswert
nicht lesenswert
Ich Versuche grad eine RFM69 Lib für ARM umzubauen. Hat jemand einen 
sicher Funktionierenden Stand von dieser Lib, den man als Startpunt 
verwenden kann?
Am Anfang des Posts gab es mal eine Lib, aber seitdem gab es ja offenbar 
viel Diskussionsbedarf....

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich versuche gerade eine Verbindung zwischen zwei RFM69-Funkmodulen 
aufzubauen. Ein STM32 ist TX und ein zweiter RX.
Wenn das eine Modul permanent im RX-Modus ist, funktioniert alles 
wunderbar.
Doch wenn ich nach dem Empfang eines Pakets in den Standby-Modus schalte 
und dann kurz darauf wieder in den RX-Modus, bricht die Verbindung nach 
ein paar empfangenen Paketen ab. Nach einem Reset des µC geht es wieder 
für ein paar Pakete.
Ich bin um jeden Hinweis dankbar, da ich jetzt schon den ganzen Tag nach 
dem Fehler suche...

Hier die Init-Routine RX-on und die IRQ-Routine für den externen 
Interrupt (diese löst aauf positive Flanke von DIO0 aus; in main 
passiert nichts):
void rfm_init(void)
{
  rfm_communication_enable = 0;

  spi_init();
  ext_irq_init();


  rfm_send_spi_cmd(0x0200,1);  // FSK, Packet mode, no shaping


  uint8_t bw;
  uint16_t fdev;

  switch (RFM_BITRATE/19200L)
  {
  case 0:
  case 1:
    bw = 0x03; // 62.5 kHz
    fdev = (45000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC;
    break;
  case 2:
  case 3:
    bw = 0x02; // 125 kHz
    fdev = (90000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC;
    break;
  default:
    bw = 0x09; // 200 kHz
    fdev = (120000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC;
    break;
  }

  // Frequency Deviation
  rfm_send_spi_cmd(0x0500 | (fdev >> 8), 1);
  rfm_send_spi_cmd(0x0600 | (fdev & 0xFF), 1);

  // Data Rate
  rfm_send_spi_cmd(0x0300 | RFM_BITRATE_MSB, 1);
  rfm_send_spi_cmd(0x0400 | RFM_BITRATE_LSB, 1);

  // Receiver Bandwidth
  rfm_send_spi_cmd(0x1940 | bw, 1);

  if (bw) bw--;

  // AFC
  rfm_send_spi_cmd(0x1A40 | bw, 1);


  rfm_send_spi_cmd(0x131B, 1); // OCP enabled, 100mA

  // DIO-Mapping
  rfm_send_spi_cmd(0x2500, 1); // Clkout, FifoFull, FifoNotEmpty, FifoLevel, PacketSent/CrcOk
  rfm_send_spi_cmd(0x2607, 1); // Clock-Out off

  // Carrier frequency
  rfm_send_spi_cmd(0x0700 | RFM_FRF_MSB, 1);
  rfm_send_spi_cmd(0x0800 | RFM_FRF_MID, 1);
  rfm_send_spi_cmd(0x0900 | RFM_FRF_LSB, 1);

  // Packet config
  rfm_send_spi_cmd(0x3790, 1); // Variable length, No DC-free encoding/decoding, CRC-Check, No Address filter
  rfm_send_spi_cmd(0x3800 + RFM_MAX_PAYLOAD_LENGTH, 1); // Max. Payload-Length
  rfm_send_spi_cmd(0x3C80, 1); // Tx-Start-Condition: FIFO not empty
  rfm_send_spi_cmd(0x3DA0, 1); // Packet-Config2

  // Preamble length 4 bytes
  rfm_send_spi_cmd(0x2C00, 1);
  rfm_send_spi_cmd(0x2D04, 1);

  // Sync-Mode
  rfm_send_spi_cmd(0x2E88, 1); // set FIFO mode
  rfm_send_spi_cmd(0x2F2D, 1); // sync word MSB to 0x2D
  rfm_send_spi_cmd(0x30D4, 1); // sync word LSB to 0xD4

  // Receiver config
  rfm_send_spi_cmd(0x1800, 1); // LNA: 50 Ohm Input Impedance, Automatic Gain Control
  rfm_send_spi_cmd(0x582D, 1); // High sensitivity mode
  rfm_send_spi_cmd(0x6F30, 1); // Improved DAGC
  rfm_send_spi_cmd(0x29C4, 1); // RSSI mind. -98 dBm
  rfm_send_spi_cmd(0x1E2D, 1); // AFC auto on and clear
  rfm_send_spi_cmd(0x2A00, 1); // No Timeout after Rx-Start if no RSSI-Interrupt occurs
  rfm_send_spi_cmd(0x2B28, 1); // Timeout after RSSI-Interrupt if no Payload-Ready-Interrupt occurs

  rfm_send_spi_cmd(0x1180 | (RFM_OUTPUTPOWER & 0x1F), 1); // Set Output Power

  rfm_send_spi_cmd(0x0A80, 1); // Start RC-Oscillator

  do
  {
    rfm_send_spi_cmd(0x0A00, 0); // Wait for RC-Oscillator
  }
  while (!(spi_rx_data & (1 << 6)));


  rfm_send_spi_cmd(0x0104, 1);
  do
  {
    rfm_send_spi_cmd(0x27FF, 0);
  }
  while (!(spi_rx_data & (1 << 7)));

}





void rfm_rx_on(void)
{
  rfm_send_spi_cmd(0x0110, 1);  // rx on
  do
  {
    rfm_send_spi_cmd(0x27FF, 0);
  }
  while (!(spi_rx_data & (1 << 7)));
}





void EXTI9_5_IRQHandler(void)
{
  EXTI->PR |= EXTI_PR_PR7;
  GPIOA->ODR ^= GPIO_ODR_ODR_5;



  rfm_send_spi_cmd(0x0000, 0);
  rfm_send_spi_cmd(0x0000, 0);
  rfm_send_spi_cmd(0x0000, 0);
  rfm_send_spi_cmd(0x0000, 0);
  rfm_send_spi_cmd(0x2810, 1);

  rfm_send_spi_cmd(0x0104, 1);
  do
  {
    rfm_send_spi_cmd(0x27FF, 0);
  }
  while (!(spi_rx_data & (1 << 7)));

  //for(volatile uint32_t i=0; i<10000; i++);
  rfm_send_spi_cmd(0x3DFF, 0);
  rfm_send_spi_cmd(spi_rx_data | 0x3D04, 1);
  rfm_send_spi_cmd(0x0110, 1);  // rx on
}

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es liegt scheinbar an der AFC...
Wenn ich AfcAutoOn nicht setze, dann funktioniert es.
Hatte jemand damit auch schonmal Probleme??

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Update:
Hab das mit dem TimeOut weiter oben leider übersehen. Wenn ich bei einem 
TimeOut den RX neu starte, dann geht alles, auch mit AfcAutoOn...

von John (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

ich probiere auch gerade mit den beiden modulen herum, ich sende aber
meine daten über den fsk-pin - also senden ist übertrieben, ich weiß
noch nicht, ob was raus kommt .. ist über sdi eine adere variante, oder
geht fsk gar nicht?

mfg

von Fabian F. (fabian_f55)


Bewertung
0 lesenswert
nicht lesenswert
Keine Ahnung. Ich Habs über SDI Angesteuert. Ging problemlos.

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.