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
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.
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.
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.
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?
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.
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.
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.
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 :-(
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
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
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.
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?
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.
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.
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:
1
#include"main.h"
2
3
intmain(void){
4
uint8_tstring[]="HELLO!";
5
uint8_ttx_length=sizeof(string)/sizeof(uint8_t);
6
7
rfm_init();
8
9
for(;;){
10
rfm_transmit((char*)string,tx_length);
11
_delay_ms(500);
12
}
13
return0;
14
}
Das andere Modul als Empfänger (UART-Funktionen nicht beigefügt):
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.
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?
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.
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?
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.
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.
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.
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
"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:
1
avr-gcc -Wall -Os -mmcu=atmega328p ...
Wie kompilierst du deinen Code? Funktioniert das Kompilieren eines
Minimalbeispiels?
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
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?
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.
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.
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.
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.
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:
1
// CRC16 gemäß Semtech-CCITT (Finales Ergebnis muss vor Senden/Prüfen bitweise invertiert werden!)
2
uint16_tcrc16(uint16_tcrc,uint8_tdata){
3
crc^=(data<<8);
4
for(uint8_ti=0;i<8;i++){
5
data=((crc&0x8000)&&1);// Wird durch && entweder 0 oder 1
6
crc<<=1;
7
if(data)crc^=0x1021;// 0x1021 weil Generatorpolynom x^16+x^12+x^5+1 und MSB first
8
}
9
returncrc;
10
}
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.
1
// CRC-Variable festlegen
2
uint16_tcrcwert;
3
4
// Anfangen mit dem Längenbyte
5
crcwert=crc16(0x1D0F,laengenbyte);
6
7
// Nach jedem Datenbyte
8
crcwert=crc16(crcwert,datenbyte);
9
10
// Und am Ende vor dem Senden (MSB zuerst senden!)
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.>>
1
>// CRC-Variable festlegen
2
>uint16_tcrcwert;
3
>
4
>// Anfangen mit dem Längenbyte
5
>crcwert=crc16(0x1D0F,laengenbyte);
6
>
7
>// Nach jedem Datenbyte
8
>crcwert=crc16(crcwert,datenbyte);
9
>
10
>// Und am Ende vor dem Senden (MSB zuerst senden!)
11
>crcwert^=0xFFFF;
12
>
Da könnte ich ein Problem haben, ich glaube ich habe die falsche
CRC-Routine.
Danke!!
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
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!
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.
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):
1
charbuf[]={
2
0x0,0x3^0x0^0xff,'A'};
3
4
spi_transfer(REG_FIFO|0x80);
5
spi_transfer(sizeof(buf));
6
7
for(bytei=0;i<sizeof(buf);i++)
8
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.
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.
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.
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.
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
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.
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
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.
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?
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
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) ???
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
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.
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 :).
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.
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.
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
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
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 :) .
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.
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.
> 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.
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
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.
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
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:
1
intmain(void)
2
{
3
charsensor[MAX_ARRAYSIZE+1];
4
uint8_trx_length=0,tx_length=3;
5
6
7
adc_init();//ADW initalisieren
8
rfm_init();//Funkmodul initalisieren
9
10
while(1){
11
12
sensor[0]=ds1820_read_temperatur();
13
sensor[1]=HIH_4010_001_read_lufteuchtigkeit(1,8);
14
sensor[2]=MPX_4115A_read_luftdruck(2,8);
15
16
rfm_transmit(sensor,tx_length);
17
18
19
/*if(rfm_receiving())
20
rfm_receive(sensor, &rx_length); */
21
22
23
24
}
25
return(0);
26
}
Im Anschluss schicke ich noch die angepasste Header-Datei wo wir die
SPI-HARDWARE aber noch seperat angepasst haben.
1
#ifndef RFM69_H_
2
#define RFM69_H_
3
4
/* Carrierfrequenz in Hz */
5
#define FREQUENCY 433000000LL
6
7
/* Bitrate in bps (1200 ... 300000) and shall it be calculated as for RFM12
8
* in order to get equal bitrate for RFM12 and RFM69 if used together? */
9
#define BITRATE 9600L
10
#define RFM12COMP 1
11
12
/* Output power in dBm (-18...13) */
13
#define P_OUT_DBM 0 // Output power in dBm
14
15
/* Pin assignment */
16
#define NSELPORT B
17
#define NSEL 0
18
#define SDIPORT B
19
#define SDI 5
20
#define SDOPORT B
21
#define SDO 6
22
#define SCKPORT B
23
#define SCK 7
24
25
/* Use Hardware-SPI if available? */
26
#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 :)
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.
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.
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.
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?
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.
1
rfm_init();//Funkmodul initalisieren
2
3
while(1){
4
5
sensor[0]=ds1820_read_temperatur();
6
sensor[1]=HIH_4010_001_read_lufteuchtigkeit(1,8);
7
sensor[2]=MPX_4115A_read_luftdruck(2,8);
8
9
rfm_transmit(sensor,tx_length);
Empfänger:
beim Empfänger dachte ich halt genau anders herum.
1
while(1){
2
rfm_receive(sensor,tx_length);
3
4
zwischenwert1=sensor[0];
5
zwischenwert2=sensor[1];
6
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.
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:
1
if(rfm_receiving()){// Wenn Daten empfangen wurden:
2
rfm_receive(sensor,&rx_length);// Daten aus FIFO holen
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.
1
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.
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.>>
1
>rfm_spi(wnr?data[0]:0xFF);
2
>
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:
1
uint8_trfm_receiving(void){
2
uint8_tstatus;
3
ACTIVATE_RFM;
4
status=rfm_cmd(0x28FF,0);
5
DEACTIVATE_RFM;
6
// Check if PayloadReady is set AND unused bit is not set (if bit 0 is set, module is not plugged in or communication fails)
7
return((status&(1<<2))&&!(status&(1<<0)));
8
}
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?
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.
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!!!
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.
1
// Initialise RFM
2
voidrfm_init(void){
3
uint32_tutimer;
4
utimer=TIMEOUTVAL;
5
6
// Configure SPI inputs and outputs
7
NSEL_PORT|=(1<<NSEL);
8
SDO_PORT|=(1<<SDO);
9
SDO_DDR&=~(1<<SDO);
10
SDI_DDR|=(1<<SDI);
11
SCK_DDR|=(1<<SCK);
12
NSEL_DDR|=(1<<NSEL);
13
14
#ifdef SPCR
15
#if HARDWARE_SPI
16
// Activate and configure hardware SPI at F_CPU/4
17
SPCR|=(1<<SPE|1<<MSTR);
18
#endif
19
#endif
20
21
for(uint8_ti=0;i<20;i++){
22
_delay_ms(5);
23
24
rfm_cmd(0x0200,1);// FSK, Packet mode, No shaping
25
26
//Bitrate + corresponding settings (Receiver bandwidth, frequency deviation)
rfm_cmd(0x3C80,1);// Tx-Start-Condition: FIFO not empty
45
rfm_cmd(0x3D12,1);// Packet-Config2
46
47
// Präambel length 3 bytes
48
rfm_cmd(0x2C00,1);
49
rfm_cmd(0x2D03,1);
50
51
// Sync-Mode
52
rfm_cmd(0x2E88,1);// set FIFO mode
53
rfm_cmd(0x2F2D,1);// sync word MSB
54
rfm_cmd(0x30D4,1);// sync word LSB
55
56
// Receiver config
57
rfm_cmd(0x1800,1);// LNA: 50 Ohm Input Impedance, Automatic Gain Control
58
rfm_cmd(0x582D,1);// High sensitivity mode
59
rfm_cmd(0x6F30,1);// Improved DAGC
60
rfm_cmd(0x29DC,1);// RSSI mind. -110 dBm
61
rfm_cmd(0x1E2D,1);// Start AFC, Auto-On
62
while(!(rfm_cmd(0x1EFF,0)&(1<<4)))
63
;
64
variable_ausgeben(i,10,10);
65
66
67
rfm_cmd(0x1180+P_OUT,1);// Set Output Power
68
intu=20;
69
variable_ausgeben(u,20,20);
70
}
71
rfm_cmd(0x0A80,1);// Start RC-Oscillator
72
while(!(rfm_cmd(0x0A00,0)&(1<<6))&&--utimer)
73
;
74
into=21;
75
variable_ausgeben(o,30,30);// Wait for RC-Oscillator
76
77
rfm_rxon();
78
}
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 :
1
intmain(void)
2
{
3
charsensor[MAX_ARRAYSIZE+1];// gemessene Werte der Sensoren ins Array speichern
und beim empfänger habe ich folgenden text bei RFM69.H files wurden
angepasst und verglichen so das in beiden das selbe steht.
1
intmain(void)
2
{ks0108Init(0);
3
//set_RTC();
4
rfm_init();
5
//adc_init();
6
//lol=(int)PT100(7,8,100);
7
/*while(1){
8
9
read_RTC();
10
*/
11
while(1)
12
{
13
intausgabe=124;
14
variable_ausgeben(ausgabe,40,40);
15
/*if (rfm_receiving())
16
{rfm_receive(sensor,&rx_lenght);
17
18
zwischenwert1 = sensor[0];
19
zwischenwert2 = sensor[1];
20
zwischenwert3 = sensor[2];
21
variable_ausgeben(rfm_receiving(),30,30);
22
variable_ausgeben(zwischenwert2,20,20);
23
variable_ausgeben(zwischenwert3,10,10);
24
}
25
*/
26
}
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
ich nochmal update zum obrigen eintrag,
durch das verschiedene anzeigen lassen wo ich bin konnte ich verstellen
das nach der
1
while(!(rfm_cmd(0x1EFF,0)&(1<<4)))
2
;
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.
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.
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.
1
while(1)
2
{
3
4
variable_ausgeben(rfm_receiving(),50,50);
5
for(i=0;i<100;i++)
6
{
7
if(rfm_receiving())
8
{rfm_receive(sensor,&rx_lenght);
9
10
zwischenwert1=sensor[0];
11
zwischenwert2=sensor[1];
12
zwischenwert3=sensor[2];
13
variable_ausgeben(rfm_receiving(),30,30);
14
variable_ausgeben(zwischenwert2,20,20);
15
variable_ausgeben(zwischenwert3,10,10);
16
}
17
18
}
19
20
}
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
1
while(1){
2
3
sensor[0]=5;
4
sensor[1]=3;
5
sensor[2]=2;
6
7
/*if(rfm_receiving()){
8
9
rfm_receive(sensor,&rx_length);
10
tx_length=rx_length;
11
rfm_transmit(sensor,tx_length);
12
13
_delay_ms(5000);
14
lcd_setcursor(0,2);
15
lcd_data('5');
16
lcd_data('3');
17
lcd_data('2');
18
19
}
20
return(0);
21
}
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.
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.
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.
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
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
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??
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
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?
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?
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.
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 :-(
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.
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.
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#Viertelwellenstrahlerhttp://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.
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.
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
;-)
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!
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.
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.
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.
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.
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.
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 :-)
[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
1
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
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?
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.
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?
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?
Hi,
die Tage war mal wieder etwas Zeit für ein paar Tests.
Mit
1
rfm_cmd(0x1E00,1);
2
rfm_cmd(0x2A00,1);
klappt es jetzt. Auch musste ich die Sendeleistung mit
1
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
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
1
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.
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?
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.
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 :-)
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...
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.
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.
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
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.
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.
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:
1
/* Carrierfrequenz in Hz */
2
3
#define FREQUENCY 433920000LL
4
5
/* Bitrate in bps (1200 ... 300000) and shall it be calculated as for RFM12
6
* in order to get equal bitrate for RFM12 and RFM69 if used together? */
7
#define BITRATE 19200L
8
#define RFM12COMP 1
9
10
/* Output power in dBm (-18...13) */
11
#define P_OUT_DBM 8 // Output power in dBm
12
13
/* Pin assignment */
14
#define NSELPORT B
15
#define NSEL 2
16
#define SDIPORT B
17
#define SDI 3
18
#define SDOPORT B
19
#define SDO 4
20
#define SCKPORT B
21
#define SCK 5
22
23
/* Use Hardware-SPI if available? */
24
#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
> 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.
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.
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?
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
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
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.
1
while(1)
2
{
3
counter++;
4
if(rfm_receiving())
5
{
6
LED_RX_TOG;
7
rfm_receive(array,&rx_length);
8
uart_send_text(array);
9
uart_send_text("\r\n");
10
}
11
if(counter>=10000)
12
{
13
LED_TX_TOG;
14
counter=0;
15
}
16
}
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.
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.
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.
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.
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.
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
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.
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")
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
1
rfm_cmd(3788,1);
in
1
rfm_cmd(3708,1);
Damit wechselst du auf feste Länge und die
1
rfm_cmd(3800+MAX_ARRAYSIZE,1);
in
1
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?
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.
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>
1
rfm_cmd(3788,1);
in
1
rfm_cmd(3708,1);
Damit wechselst du
> auf feste Länge und die>
1
rfm_cmd(3800+MAX_ARRAYSIZE,1);
in
1
rfm_cmd(3811,
2
>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.
Felix P. schrieb:> Wenn du "Hallo Welt" sendest, dann muss die Länge logischerweise 10> Bytes betragen, der Befehl also>
1
>rfm_cmd(0x380A,1);
2
>
> lauten.>> Sehe gerade, dass ich oben das 0x vergessen habe vor den Hex-Werten. Da> kommt dann natürlich nur Unsinn raus.>> Also:>
1
>rfm_cmd(0x3708,1);
2
>rfm_cmd(0x380A,1);
3
>
>> 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?
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:
1
// Read data bytes
2
else{
3
// Read-access register 0
4
rfm_spi(0);
5
6
// Get length
7
// data[0] = rfm_spi(0xFF); // Diese Zeile muss auskommentiert sein
8
9
// Make sure there's no array-overflow
10
// if (data[0] > MAX_ARRAYSIZE) data[0] = MAX_ARRAYSIZE; // Die hier braucht man dann auch nicht
11
12
// Get data
13
for(uint8_ti=1;i<=10;i++){// Hier muss i<=10 gesetzt werden
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?
@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.
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
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:
1
uint8_trfm_receiving(void)
2
{
3
uint16_tstatus;
4
status=rfm_status();
5
6
// No Payload and RSSI-Rx-Timeout -> Rx-Restart
7
if((!(status&(1<<2)))&&(status&(1<<10)))
8
{
9
rfm_cmd((rfm_cmd(0x3DFF,0)|0x3D04),1);
10
}
11
12
// Check if PayloadReady is set AND unused bit is not set (if bit 0 is set, module is not plugged in)
13
return((status&(1<<2))&&!(status&(1<<0)));
14
}
Wenn ich folgende Zeile auskommentiere, gehen keine Packete verloren
dafür wird nach einer gewissen Zeit gar nichts mehr empfangen.
1
rfm_cmd((rfm_cmd(0x3DFF,0)|0x3D04),1);
Was hat es mit diesem RX-Restart auf sich? Was geht hier schief?
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.
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.
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
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?
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
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
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>>
1
>// Transfer length
2
>rfm_spi(16);
3
>
>> muss raus.
Das war es. Nach dem auskommentieren der Zeile ging es.
Vielen Dank Felix.
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...
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
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
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()).
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 ?
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.
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...
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.
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!
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.
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.
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.
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
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 :-)
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.
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.
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
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 ?
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?
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschalten