RFM69 range issues
-
I recently started experimenting with MySensors 2.0 library and RFM69 modules. I have a couple of RFM69W 868MHz and RFM69HW 433MHz modules. Since I already had the MySensors 1.5 library installed, I tried using that one but found it to be really complicated to use with the RFM69 modules since there is little to no info on how to properly switch from the default RF24 radios to RFM69. And the only bits and pieces I found were also not consistent.
So I moved on to 2.0. The syntax is simpler than 1.5 and I found a little bit more info about using RFM69. I uploaded the sketches and bam!, the sensor was pushing updates to the serial gateway. Then I moved the sensor node to another room. But no RX packets were hitting the gateway. After much trial and error I learned that they only talk to eachother if they're a meter or so.
What I alread did- Switched the high-power 433MHz RFM69HW with 868MHz RFM69W.
- Used a separate 3.3V power supply to power the radios.
- Used 4.7uF and 47uF capacitors across the radio's power pins on both the gateway and the sensor node.
- Used correct length both wire and helical antennas for both modules types.
No matter what I did, at least with the 2.0 library they hear eachother at 1m or so. Now I'm rolling back the 1.5 library and sketches and get back with the update.
I wanted to know if anyone experienced similar issues with the RFM69 modules with the 2.0 library because although I am perfectly happy with the RF24 modules, I'd like the lower fooprint, longer range, RSSI reporting and the encryption of the RFM69 radios.
-
@mihai.aldea
Could you please post your sketch?Have you set
#define MY_IS_RFM69HWaccording to your module type?
-
Do you mix 433MHz and 868MHz modules?
Sensor and gateway need to have the same type of modul.
-
hmm, looks weird, what is your power supply? do you use dupont cable?
on my side, i already quickly tested 40m with one brickwall, outdoor rfm69cw (same as w) to my indoor rfm69hw GW, with mysensors 2 beta.
-
@FotoFieber said:
@mihai.aldea
Could you please post your sketch?Have you set
#define MY_IS_RFM69HWaccording to your module type?
No, I haven't. I just changed:
#define MY_RADIO_NRF24 //#define MY_RADIO_RFM69to
//#define MY_RADIO_NRF24 #define MY_RADIO_RFM69At some point I did try with:
#define MY_IS_RFM69HWbut no change.
I used the standard sketch, only modifying those two rows.
-
@gloob said:
Do you mix 433MHz and 868MHz modules?
Sensor and gateway need to have the same type of modul.Of course I did not mix them, how dumb can I be?
I just happened to have another set which luckily were on a different frequency, as well as being the normal power types (without the "H") to rule out a possible signal saturation.
-
@scalz said:
hmm, looks weird, what is your power supply? do you use dupont cable?
on my side, i already quickly tested 40m with one brickwall, outdoor rfm69cw (same as w) to my indoor rfm69hw GW, with mysensors 2 beta.Initially I powered them from the Arduino Pro Mini onboard 3.3V voltage regulator which is supposed to handle up to 200mA. I also added capacitors. Then moved the setup to a larger breaboard powered by one of those breadboard power supplies. I powered the radios directly from the breadboard's 3.3V power rail. Also added capacitors.
Please note that each test was performed identically on both sensor node and serial gateway.The modules are connected to the Arduinos using short dupont cables. It's easier to prototype them by cutting a dupont cable set in two, solder the strip cable ends to the radio boards and connect the dupont pins on the breadboard. One thing worth mentioning is that the 868MHz modules are facing the chip side upwards and the 433MHz down.
Maybe the only thing that's not done 100% by the book is that I chose to connect the radios ground using the farmost GND pin instead of the one opposite the ANT pin. After I soldered them I found some schematics showing a dipole antenna setup using that pin as counterpoise for the antenna. But I assume that all GND pins are connected to the ground plane, so it really doesn't matter.
-
I haven't heard of countefeit RFM69 modules, but anyway, here are the exact modules, purchased from this exact supplier:
http://www.tme.eu/en/details/rfm69hw-433s2/rf-communication-modules/hope-microelectronics/
http://www.tme.eu/en/details/rfm69w-868s2/rf-communication-modules/hope-microelectronics/
-
I do not know if this will help but you could add the following to your sketch to make sure the radios are using the correct frequenzy:
#define MY_RFM69_FREQUENCY RF69_433MHZI think the default value if not defined is "RF69_868MHZ"
-
@korttoma: Instead of inserting the #define in the sketch I modified the same entry in MyConfig.h. That's basically the same thing.
Anyway I must confess that at start, it took me some time to realize that
That's because there's very little info on the RFM69 setups, almost all documentation revolves around RF24 and ESP8266 and the library and examples are pre-configured for RF24 
-
These defines are mentioned here but some of then are missing the default value and a comment describing what they do.
-
side note: i've just update the docs for rfm69
about this issue, hmm..what if you directly connect a 82mm monopole wire directly on the radio ant pad? and powered from batt, like 2xAA/AAA.. looks weird!
-
@scalz Many thanks for updating the docs.
I was thinking about testing them with a battery as well but even if the remote sensors may be just fine with battery power, I still need the gateway radio to be fed with a constant 3.3V voltage from either the Arduino's 3.3V rail, or using a an external regulator. And so far neither worked.
I feel like there's something wrong with the radio modules. What ar the odds of those particular modules not to work with MySensors 2.0?
-
@scalz said:
what if you directly connect a 82mm monopole wire directly on the radio ant pad?
I used a 17cm random wire for the 433MHz modules and 9cm wire for the 868MHz ones. Then coiled up the 17cm wires into a diy helical with 6-7 turns (not sure exctly)
-
for testing, perhaps better test with straight wire.
For 868Mhz, it's 82mm or it detune the radio. Also coil is nice for compact thing in box, but it decrease the range.
I hope you'll get it working, i've never got bad radio modules on my side, not yet!
With logs we could see if you get lot of fail, too, meaning bad range
-
Some guides mention 87mm, others 82mm. As for the helical I will have to test and see. PCB antennas are also an option, but I'd hate to have my nice boxed sensors with wires hanging out.
As for the bad radio modules, that's one other reason I am focusing on the RFM69. I started experimenting with the cheap eBay NRF24L01+ modules, the black ones, only to later find out that about 1 out of 10 fails after sometime and doesn't enter the deep sleep mode, using about 2mA instead of about 60uA, obviously killing the battery after a day or so. I read about one guy who ordered 2000 or so and most of them had the exact same problem.
And since I am using rather expensive CR123 or 14250 batteries I don't want take that chance.
The green NRF24L01+ modules however, worked flawlessly so far but they're a bit too bulky for my projects.
-
oki. i know for the 86mm, it also depends on the calc if i remember, that's why you can find both. but you said 9cm
for your test, you should use straigth wire to be sure.
No stranded wire. Only one core inside.It's good to know, as rfm69 need an external ant, it requires more care for the anntenna sensitivity, for noise etc.. its emplacement, orientation, shape also matter etc.. so then it's sure it's compromise between acceptable range and compact devices.
Near a computer can also increase noise etc..
If everything is ok for ant, ok with defines in Mysensors, then it's probably on your HW. In this case, you may see some errors in your logs when you try. packet ack failed etc.. some logs ??
-
So... more tests performed:
I assumed that my moronic rush fried the modules power amps. I didn't carefully read the guide and hooked their I/O pins to a 5V Arduino pins (but connected the VCC pin to the 3.3V rail). So I pulled the last two factory sealed RFM69HW 433MHz I had stashed, soldered them with dupont cables and proper antenna (0.8mm copper single core 17cm long) and hooked one module to a 3.3V Arduino (the gateway to be) and the other one on a breadboard ATmega328 (the basic remote sensor architecture) powered by a 14250 battery.
The exact same thing
The LowPowerLab works for ranges up to 1m, the Radiohead library doesn't report anything on the serial interface and leds I used for basic debug shows that the sensor node sends packets but the gateway doesn't receive them.
So I got to a point where I'm very frustrated because there must be something I'm missing. I am using two module types at different frequency and power output, purchased from a trusted source, six months apart.
However, some further reading lead me to this page:
https://www.andrehessling.de/2015/02/07/figuring-out-the-power-level-settings-of-hoperfs-rfm69-hwhcw-modules/
This guy compiled a very thorough review of the modules in which he's playing with settings by enabling/disabling the radios power amps using writing registers. But I am totally clueless on how can this be done, if the MySensors has the proper settings preconfigured or if they're accessible and if so then where. It's not clear to me either if these registers are persistent across various sketches involving various libraries or if the used library has to have support for them and they need to be declared in every sketch or inside the library. This registry thing is pretty much where my expertise hits a wall
It's really strange that this 1m range is very consistend across a lot of setups I made. Maybe the power amps are disabled and they "hear" eachother while being very close, maybe by some sort of harmonics.
-
regarding the power level registers, they are set at full power when doing
#define MY_IS_RFM69HW
In the upcoming release, there will be autoadjustements of the power level.Like i said above, i'm running a local beta version with the new driver, but the one included actually gave me good results with rfm69hcw (same as HW) and my nodes are using rfm69cw (same as W).
Lowpowerlab lib works ok with mine. I'm not sure if i tried radiohead with them, but it was ok with rfm95..So that doesn't come from the lib. Unfortunately, it's consistent with your hardware&environment..that's not cool, i agree.
Also, i always noted that using wire between radio and breadboard, give more ack failed (using custom pcb, i don't notice this). because it can acts as sort of "ant" and add noise. But you should get more than 1m..What if you put them, says, 5meters apart, and plug power. Does it work?
So i would bet on lot of missed packets if you can't get more than 1m.- Do you have logs to see if you get some ack failed?
- Could you show a pic of your stuff, perhaps with two pair of eyes could help..
I'm missing ideas
-
Exactly, I've exhausted all my ideas as well. It must definitely be the hardware. As for your questions, I'm not sure they can even talk at a full 1m distance, more like 0.5m.
I have the custom PCB design ready for production but I don't want to submit it until I do some thorough testing. I looked for alternatives on the local market but I can only find breakout boards and besides their unfeasable cost, they're too bulky to fit inside my sensor cases.
I found that Anarduino sells custom modules with integrated RFM69(H)W (http://www.anarduino.com/miniwireless/) that look exactly like the one I have and the one depicted the guide here: https://www.mysensors.org/build/connect_radio
Adafruit's Feather, as well as the Sparkfun's breakout board are using a different looking module (the same found on eBay or Aliexpress)
Anarduino has an old RFM69 library but I'm struggling with Arduino IDE versions since the latest version throws a bunch of errors when compiling while 1.6.5 works just fine. But the funny thing is that even they recommend using the RadioHead libraryAnyway, here's a bunch of pictures but I'm not sure if they're of any help.
http://imgur.com/a/yICkw
-
I have had the same issues as you with the RFM69 modules.
First ones that I bought were marked as RFM69HCW 433mhz, and when I put them together as required, I couldn't get range of more than around 40cm. After that, the reception dropped off a cliff. One thing I did note was that the modules looked different from all the images I could see on this site, which led me to ponder whether I just had crummy modules or not. Also, given the size of the antenna, I was a bit loath to continue with 433mhz radios.
so I decided to up and pick up a new batch of radios, and change over to the RFM69HW (without the C), 868mhz. These ones, when I soldered them up, give me range of around 30m through the entire length of the house, through every wall.
So the only thing I could put my effort down to was that I just had a crummy radio module batch first, and a proper set later, so not sure I can put too much more knowledge into things here.
-
@Chester said:
I have had the same issues as you with the RFM69 modules.
First ones that I bought were marked as RFM69HCW 433mhz, and when I put them together as required, I couldn't get range of more than around 40cm. After that, the reception dropped off a cliff. One thing I did note was that the modules looked different from all the images I could see on this site, which led me to ponder whether I just had crummy modules or not. Also, given the size of the antenna, I was a bit loath to continue with 433mhz radios.
so I decided to up and pick up a new batch of radios, and change over to the RFM69HW (without the C), 868mhz. These ones, when I soldered them up, give me range of around 30m through the entire length of the house, through every wall.
So the only thing I could put my effort down to was that I just had a crummy radio module batch first, and a proper set later, so not sure I can put too much more knowledge into things here.
What you're saying makes perfect sense, crappy batches can hit the market sometimes. But what doesn't make any sense in my situation is that I first puchased 5x 868MHz RFM69W modules but as I had other ongoing projects they stayed on shelf for about half an year. Then I considered tinkering with 433MHz RFM69HW to test the longest possible range of RFM69x line.
Anyway, I absolutely need to use bare modules for my sensors so I will order a few from eBay and hopefully those ones will work.
-
@mihai-aldea I've bought the same modules from the same supplier.
Initially I had the same problems you mention.
My advice: start with the simple lowpowerlab library and their sender/receiver sketches. Use some form of ground plane directly under the module, I've ended up with small pieces of metal sheet under the modules, otherwise I had no reception. Or use a diploe as pictured earlier.
By the way try touching the antenna at different points maybe you will get reception. The antenna length must be tuned to the circuit, I ended up with 96mm for one particular 868Mhz module, either the tuning circuit is flawed or my circuit messes up the antenna tuning.
You can also check the interrupt gets triggered or simply use polling by calling the interrupt handler function inside the receiveDone() function to be sure you don't miss received packages (I work with Mega2560 which are not configured correctly in the library for pin2/int4).
And please use some level shifters
-
I don't have the skill level of an RF engineer, but being also a licensed ham radio operator, I know a thing or two about RF signals and atennas.
I believe your statements, yet here I am testing a prototype using a radio module that's supposed to beat the RF24 by a mile, but for this to happen I need use dipoles, ground planes, and who knows, maybe design, build and tune some magnetic loop antenna or some antenna tuning circuit for the RFM69 modules to work at 20-30 meters. For God sake, even with an improper length random wire antenna they should be able to work at 20-30m.
There are people reporting good signal at distances of 13km with a bitrate of 55.5kbps. The LowPowerLab sets the default bitrate at 4kbps. That may take the distance to over 20km. But all I managed to squeeze out of my 433MHz HW modules is 3 meters. That can't be right.
I contacted HopeRF and asked them about clarifications. First I need to know if their RFM69HW-V1.3.pdf is compatible with the RFM69HW REV 2.0 board (as depicted on the back of the module). I also contacted the supplier asking if they received any other complaints for those modules.
What kills me is that while everything points to faulty modules, they were bought 6 months apart from the same supplier, they have different frequencies and power output and they behave the same
As for the register levels, luckily I had some 3.3V Arduino Pro Mini to which I hooked a pair of factory sealed modules (to rule out any malfunction due to the improper usage with 5V I/O).
Thanks to Felix's excellent library I was able to pull the complete list of registries:1 - 10 - 10000 2 - 0 - 0 3 - 2 - 10 4 - 40 - 1000000 5 - 3 - 11 6 - 33 - 110011 7 - 6C - 1101100 8 - 40 - 1000000 9 - 0 - 0 A - 41 - 1000001 B - 40 - 1000000 C - 2 - 10 D - 92 - 10010010 E - F5 - 11110101 F - 20 - 100000 10 - 24 - 100100 11 - 7F - 1111111 12 - 9 - 1001 13 - F - 1111 14 - 40 - 1000000 15 - B0 - 10110000 16 - 7B - 1111011 17 - 9B - 10011011 18 - 8 - 1000 19 - 42 - 1000010 1A - 8A - 10001010 1B - 40 - 1000000 1C - 80 - 10000000 1D - 6 - 110 1E - 10 - 10000 1F - 0 - 0 20 - 0 - 0 21 - 0 - 0 22 - 0 - 0 23 - 0 - 0 24 - D3 - 11010011 25 - 40 - 1000000 26 - 7 - 111 27 - D8 - 11011000 28 - 0 - 0 29 - DC - 11011100 2A - 0 - 0 2B - 0 - 0 2C - 0 - 0 2D - 3 - 11 2E - 88 - 10001000 2F - 2D - 101101 30 - 64 - 1100100 31 - 0 - 0 32 - 0 - 0 33 - 0 - 0 34 - 0 - 0 35 - 0 - 0 36 - 0 - 0 37 - 90 - 10010000 38 - 42 - 1000010 39 - 0 - 0 3A - 0 - 0 3B - 0 - 0 3C - 8F - 10001111 3D - 13 - 10011 3E - 73 - 1110011 3F - 61 - 1100001 40 - 6D - 1101101 41 - 70 - 1110000 42 - 6C - 1101100 43 - 65 - 1100101 44 - 45 - 1000101 45 - 6E - 1101110 46 - 63 - 1100011 47 - 72 - 1110010 48 - 79 - 1111001 49 - 70 - 1110000 4A - 74 - 1110100 4B - 4B - 1001011 4C - 65 - 1100101 4D - 79 - 1111001 4E - 1 - 1 4F - 0 - 0 50 - 13 - 10011 51 - 45 - 1000101 52 - 88 - 10001000 53 - 8 - 1000 54 - 0 - 0 55 - 0 - 0 56 - 1 - 1 57 - 0 - 0 58 - 1B - 11011 59 - 9 - 1001 5A - 55 - 1010101 5B - 80 - 10000000 5C - 70 - 1110000 5D - 33 - 110011 5E - CA - 11001010 5F - 8 - 1000 60 - 0 - 0 61 - F - 1111 62 - 0 - 0 63 - 0 - 0 64 - 0 - 0 65 - F - 1111 66 - 70 - 1110000 67 - 0 - 0 68 - 12 - 10010 69 - 16 - 10110 6A - 19 - 11001 6B - 1C - 11100 6C - 0 - 0 6D - 4 - 100 6E - C - 1100 6F - 30 - 110000 70 - 18 - 11000 71 - 0 - 0 72 - 0 - 0 73 - 0 - 0 74 - 0 - 0 75 - 0 - 0 76 - 0 - 0 77 - 0 - 0 78 - 0 - 0 79 - 0 - 0 7A - 0 - 0 7B - 0 - 0 7C - 0 - 0 7D - 0 - 0 7E - 0 - 0 7F - 0 - 0 80 - D - 1101I had to use a minor tweak to extend the limit of registries pulled out above the initial limit of 0x4F. They are test registers and internal test registers. Not sure if they're of any help.
-
Well, here's some new developments. I used the Struct_send and Send_receive examples from LPL RFM69 lib.
Struct_send
#define RF_PALEVEL_PA0_OFF #define RF_PALEVEL_PA1_ON #define RF_PALEVEL_PA2_OFF #include <RFM69.h> #include <SPI.h> #include <SPIFlash.h> #define NODEID 99 #define NETWORKID 100 #define GATEWAYID 1 #define FREQUENCY RF69_433MHZ //Match this with the version of your Moteino! (others: RF69_433MHZ, RF69_868MHZ) #define KEY "sampleEncryptKey" //has to be same 16 characters/bytes on all nodes, not more not less! #define LED 13 #define SERIAL_BAUD 115200 #define ACK_TIME 30 // # of ms to wait for an ack int TRANSMITPERIOD = 1000; //transmit a packet to gateway so often (in ms) byte sendSize=0; boolean requestACK = true; SPIFlash flash(8, 0xEF30); //EF40 for 16mbit windbond chip RFM69 radio; typedef struct { int nodeId; //store this nodeId unsigned long uptime; //uptime in ms float temp; //temperature maybe? } Payload; Payload theData; void setup() { Serial.begin(SERIAL_BAUD); radio.initialize(FREQUENCY,NODEID,NETWORKID); //radio.setHighPower(); //uncomment only for RFM69HW! radio.encrypt(KEY); char buff[50]; sprintf(buff, "\nTransmitting at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915); Serial.println(buff); if (flash.initialize()) Serial.println("SPI Flash Init OK!"); else Serial.println("SPI Flash Init FAIL! (is chip present?)"); } long lastPeriod = -1; void loop() { //process any serial input if (Serial.available() > 0) { char input = Serial.read(); if (input >= 48 && input <= 57) //[0,9] { TRANSMITPERIOD = 100 * (input-48); if (TRANSMITPERIOD == 0) TRANSMITPERIOD = 1000; Serial.print("\nChanging delay to "); Serial.print(TRANSMITPERIOD); Serial.println("ms\n"); } if (input == 'r') //d=dump register values radio.readAllRegs(); //if (input == 'E') //E=enable encryption // radio.encrypt(KEY); //if (input == 'e') //e=disable encryption // radio.encrypt(null); if (input == 'd') //d=dump flash area { Serial.println("Flash content:"); int counter = 0; while(counter<=256){ Serial.print(flash.readByte(counter++), HEX); Serial.print('.'); } while(flash.busy()); Serial.println(); } if (input == 'e') { Serial.print("Erasing Flash chip ... "); flash.chipErase(); while(flash.busy()); Serial.println("DONE"); } if (input == 'i') { Serial.print("DeviceID: "); word jedecid = flash.readDeviceId(); Serial.println(jedecid, HEX); } } //check for any received packets if (radio.receiveDone()) { Serial.print('[');Serial.print(radio.SENDERID, DEC);Serial.print("] "); for (byte i = 0; i < radio.DATALEN; i++) Serial.print((char)radio.DATA[i]); Serial.print(" [RX_RSSI:");Serial.print(radio.readRSSI());Serial.print("]"); if (radio.ACKRequested()) { radio.sendACK(); Serial.print(" - ACK sent"); delay(10); } Blink(LED,5); Serial.println(); } int currPeriod = millis()/TRANSMITPERIOD; if (currPeriod != lastPeriod) { //fill in the struct with new values theData.nodeId = NODEID; theData.uptime = millis(); theData.temp = 91.23; //it's hot! Serial.print("Sending struct ("); Serial.print(sizeof(theData)); Serial.print(" bytes) ... "); if (radio.sendWithRetry(GATEWAYID, (const void*)(&theData), sizeof(theData))) Serial.print(" ok!"); else Serial.print(" nothing..."); Serial.println(); Blink(LED,3); lastPeriod=currPeriod; } } void Blink(byte PIN, int DELAY_MS) { pinMode(PIN, OUTPUT); digitalWrite(PIN,HIGH); delay(DELAY_MS); digitalWrite(PIN,LOW); }Struct_receive
#define RF_PALEVEL_PA0_OFF #define RF_PALEVEL_PA1_ON #define RF_PALEVEL_PA2_OFF #include <RFM69.h> #include <SPI.h> #include <SPIFlash.h> #define NODEID 1 #define NETWORKID 100 #define FREQUENCY RF69_433MHZ //Match this with the version of your Moteino! (others: RF69_433MHZ, RF69_868MHZ) #define KEY "thisIsEncryptKey" //has to be same 16 characters/bytes on all nodes, not more not less! #define LED 13 #define SERIAL_BAUD 115200 #define ACK_TIME 30 // # of ms to wait for an ack RFM69 radio; SPIFlash flash(8, 0xEF30); //EF40 for 16mbit windbond chip bool promiscuousMode = true; //set to 'true' to sniff all packets on the same network typedef struct { int nodeId; //store this nodeId unsigned long uptime; //uptime in ms float temp; //temperature maybe? } Payload; Payload theData; void setup() { Serial.begin(SERIAL_BAUD); delay(10); radio.initialize(FREQUENCY,NODEID,NETWORKID); //radio.setHighPower(); //uncomment only for RFM69HW! radio.encrypt(KEY); radio.promiscuous(promiscuousMode); char buff[50]; sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915); Serial.println(buff); if (flash.initialize()) Serial.println("SPI Flash Init OK!"); else Serial.println("SPI Flash Init FAIL! (is chip present?)"); } byte ackCount=0; void loop() { //process any serial input if (Serial.available() > 0) { char input = Serial.read(); if (input == 'r') //d=dump all register values radio.readAllRegs(); if (input == 'E') //E=enable encryption radio.encrypt(KEY); if (input == 'e') //e=disable encryption radio.encrypt(null); if (input == 'p') { promiscuousMode = !promiscuousMode; radio.promiscuous(promiscuousMode); Serial.print("Promiscuous mode ");Serial.println(promiscuousMode ? "on" : "off"); } if (input == 'd') //d=dump flash area { Serial.println("Flash content:"); int counter = 0; while(counter<=256){ Serial.print(flash.readByte(counter++), HEX); Serial.print('.'); } while(flash.busy()); Serial.println(); } if (input == 'D') { Serial.print("Deleting Flash chip content... "); flash.chipErase(); while(flash.busy()); Serial.println("DONE"); } if (input == 'i') { Serial.print("DeviceID: "); word jedecid = flash.readDeviceId(); Serial.println(jedecid, HEX); } } if (radio.receiveDone()) { Serial.print('[');Serial.print(radio.SENDERID, DEC);Serial.print("] "); Serial.print(" [RX_RSSI:");Serial.print(radio.readRSSI());Serial.print("]"); if (promiscuousMode) { Serial.print("to [");Serial.print(radio.TARGETID, DEC);Serial.print("] "); } if (radio.DATALEN != sizeof(Payload)) Serial.print("Invalid payload received, not matching Payload struct!"); else { theData = *(Payload*)radio.DATA; //assume radio.DATA actually contains our struct and not something else Serial.print(" nodeId="); Serial.print(theData.nodeId); Serial.print(" uptime="); Serial.print(theData.uptime); Serial.print(" temp="); Serial.print(theData.temp); } if (radio.ACKRequested()) { byte theNodeID = radio.SENDERID; radio.sendACK(); Serial.print(" - ACK sent."); // When a node requests an ACK, respond to the ACK // and also send a packet requesting an ACK (every 3rd one only) // This way both TX/RX NODE functions are tested on 1 end at the GATEWAY if (ackCount++%3==0) { Serial.print(" Pinging node "); Serial.print(theNodeID); Serial.print(" - ACK..."); delay(3); //need this when sending right after reception .. ? if (radio.sendWithRetry(theNodeID, "ACK TEST", 8, 0, 50)) // 0 = only 1 attempt, no retries; wait up to 50mS Serial.print("ok!"); else Serial.print("nothing"); } } Serial.println(); Blink(LED,3); } } void Blink(byte PIN, int DELAY_MS) { pinMode(PIN, OUTPUT); digitalWrite(PIN,HIGH); delay(DELAY_MS); digitalWrite(PIN,LOW); }As you noticed both sketches start with
#define RF_PALEVEL_PA0_OFF #define RF_PALEVEL_PA1_ON #define RF_PALEVEL_PA2_OFFso I can play with the PA's.
Also the//radio.setHighPower(); //uncomment only for RFM69HW!is commented out because they appear to hear eachother fine. Well, almost fine.
Here's the Struct_send output:
Transmitting at 433 Mhz... SPI Flash Init FAIL! (is chip present?) Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... Sending struct (10 bytes) ... nothing... ...........But here's the most interesting output after I changed bool promiscuousMode = false; to bool promiscuousMode = true; I was suddenly able to make them talk to each other even with both PA's disabled and the radio.setHighPower(); commented out.
Here's the Struct_receive output:Listening at 433 Mhz... SPI Flash Init FAIL! (is chip present?) [212] [RX_RSSI:-68]to [189] nodeId=10767 uptime=3895142702 temp=ovf [212] [RX_RSSI:-66]to [189] nodeId=10767 uptime=3895142702 temp=ovf [212] [RX_RSSI:-66]to [189] nodeId=10767 uptime=3895142702 temp=ovf [138] [RX_RSSI:-66]to [69] nodeId=25167 uptime=755652493 temp=10.40 [138] [RX_RSSI:-66]to [69] nodeId=25167 uptime=755652493 temp=10.40 [138] [RX_RSSI:-66]to [69] nodeId=25167 uptime=755652493 temp=10.40 [6] [RX_RSSI:-66]to [95] nodeId=28423 uptime=3186857133 temp=-0.00 - ACK sent. Pinging node 6 - ACK...nothing [6] [RX_RSSI:-66]to [95] nodeId=28423 uptime=3186857133 temp=-0.00 - ACK sent. [211] [RX_RSSI:-67]to [113] nodeId=-15141 uptime=657118850 temp=28713.76 - ACK sent. [211] [RX_RSSI:-68]to [113] nodeId=-15141 uptime=657118850 temp=28713.76 - ACK sent. Pinging node 211 - ACK...nothing [18] [RX_RSSI:-68]to [211] nodeId=14750 uptime=987840321 temp=-0.00 [18] [RX_RSSI:-66]to [211] nodeId=14750 uptime=987840321 temp=-0.00 [18] [RX_RSSI:-67]to [211] nodeId=14750 uptime=987840321 temp=-0.00 [133] [RX_RSSI:-66]to [167] nodeId=-16647 uptime=1764550266 temp=ovf [133] [RX_RSSI:-67]to [167] nodeId=-16647 uptime=1764550266 temp=ovf [133] [RX_RSSI:-66]to [167] nodeId=-16647 uptime=1764550266 temp=ovf [50] [RX_RSSI:-66]to [109] nodeId=19370 uptime=3957555244 temp=0.00 [50] [RX_RSSI:-66]to [109] nodeId=19370 uptime=3957555244 temp=0.00 [50] [RX_RSSI:-66]to [109] nodeId=19370 uptime=3957555244 temp=0.00 [131] [RX_RSSI:-66]to [229] nodeId=12568 uptime=2848342087 temp=ovf [131] [RX_RSSI:-66]to [229] nodeId=12568 uptime=2848342087 temp=ovf [131] [RX_RSSI:-66]to [229] nodeId=12568 uptime=2848342087 temp=ovf [255] [RX_RSSI:-66]to [168] nodeId=7355 uptime=659277296 temp=0.00 [255] [RX_RSSI:-66]to [168] nodeId=7355 uptime=659277296 temp=0.00 [255] [RX_RSSI:-67]to [168] nodeId=7355 uptime=659277296 temp=0.00 [186] [RX_RSSI:-67]to [20] nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent. [186] [RX_RSSI:-68]to [20] nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent. [186] [RX_RSSI:-68]to [20] nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent. Pinging node 186 - ACK...nothing [26] [RX_RSSI:-68]to [43] nodeId=2128 uptime=2142532543 temp=ovf [26] [RX_RSSI:-67]to [43] nodeId=2128 uptime=2142532543 temp=ovf [26] [RX_RSSI:-67]to [43] nodeId=2128 uptime=2142532543 temp=ovf [193] [RX_RSSI:-67]to [152] nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent. [193] [RX_RSSI:-68]to [152] nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent. [193] [RX_RSSI:-67]to [152] nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent. Pinging node 193 - ACK...nothing [128] [RX_RSSI:-68]to [153] nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent. [128] [RX_RSSI:-67]to [153] nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent. [128] [RX_RSSI:-68]to [153] nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent. Pinging node 128 - ACK...nothingDo you noticed the to column? And how the ack destination node is never the same? So it seems to me that the packets are corrupted either at source or at destination. I'm not sure if the sender is mangling it or if the receiver is parsing it wrong. But it's obvious that the one way communication works just fine. The problem is with the "full duplex" communication.
-
RFM69HW can not work with PA disabled, you must use radio.setHighPower(), otherwise unpredictable results may occur.
try spacing them at least 1 meter apart and use radio.setPowerLevel(0) instead.
-
@executivul said:
RFM69HW can not work with PA disabled, you must use radio.setHighPower(), otherwise unpredictable results may occur.
try spacing them at least 1 meter apart and use radio.setPowerLevel(0) instead.While RFM69W has only PA0 installed, RFM69HW doesn't have it but has PA1 and PA2. So I'm not sure if there's a problem with enablin PA0 on the HW version but I left it disabled anyway. After trying with the fresh new models, I was too far with my experiments, and drifted a lot from the standard libraries config. So obviously they weren't working. But with with a back to basics approach, I got them to work. I'm not sure what their range is because I haven't had time to make a field test, but the HW's work just fine with all PA's disabled and with a couple of brick walls between.
So guys, thank you very much for your support, but my conclusion is that the first modules weren't working because I was applying them with 5V logic. I will check them and see if they're damaged or work fine with the proper 3.3V.
Since I got them to work, I did found a couple of problems but that's another topic which I'll open as soon as I'll get a consistent conclusion and a replicable scenario.
-
@mihai-aldea
that's why it's always better to tell which hardware you're using, and logs. If i knew you were using 5v logic, i would have told you it couldn't work, and save timeAbout promiscuous mode, you can think about it as a sniffer mode.
Great to hear you finally found your answer
-
@scalz said:
@mihai-aldea
that's why it's always better to tell which hardware you're using, and logs. If i knew you were using 5v logic, i would have told you it couldn't work, and save timeAbout promiscuous mode, you can think about it as a sniffer mode.
Great to hear you finally found your answer
Yeah, I know I was a bit of a jackass for not reverting back whatever I was doing and provide you with logs from the MySensors lib. But I used lots of libs, some of them with various tweaks, the test setup was bit complicated and I knew that whatever logs I could see during the initial stages were not very helpful.
And speaking of helpful logs. I would've loved to see more verbose logs. Is there a way to increase the verbosity level?
As for the promisc mode, I know very well that that is, is just that it seemed strange how is it that the node ID's were all messed up.
-
@mihai-aldea
yeah i can understand, no problem, was just an humble remainder for future
the new rfm69 driver we are working on, will be better (i hope) with more verbose, for registers and state machine too. and you'll get atc feature which is cool. i'm not sure if i'll have time to finish listenmode though (for the moment it's very basic)..let's seeI hope you'll get your thing running as you want
-
Is the new driver a fork of some other or you're building it from scratch?
One suggestion though: If it's aiming to provide excellent support for the battery powered nodes, it would be great if you'd expose some of the advanced settings that allow faster TX times. I'm currently testing the awake cycle time aiming for the lowest possible values. For instance I chose the fast Si7021 instead of the slooooow DHT22. This one is supposed to have a total converesion time of 22.8ms but the fastest working library is Adafruit's which pulls the maximum resolution values within 50-55ms. But on top of that, the TX time takes another 70ms with the current driver. That means a total of ~125ms (with ack disabled).
125ms isn't bad. But maybe one would come to the conclusion that they'd want to trade range or bandwidth for TX speed (not bitrate). I'm not talking about the bulky 2xAA battery packs or large lithium cells users but the ones who'd put a CR2032 coin battery inside of a door sensor for instance and expect it to last at least a year.
-
mainly inspired from Lowpowerlab at the beginning.
But now it looks like other Mysensors radio drivers. for harmonization, and better support.
So, the base flow implementation for instance, is from tekka (structure, and spi handling).
It should be faster, and memory efficient compared to the old one (lowpowerlab version) which was c++ etc..
Compilation with all features (atc, listenmode) takes now less memory than with the previous lowpowerlab version. Even with some nice addition from tekka like a version number+sequence number in the header.
And, marceloagno is also checking the linux part.
etc..
Also, regarding tx times, we still use packetmode with automatic sequencer if this is what you're talking.
for a door contact switch, depending of its purpose, signing (and so ack) may be needed to have "security" and reliable delivery packet.
As it's rf, i'm trying to find a way to have this reliable delivery by adding a random delay (optional feature) before talking. the Listen Before Talk to avoid for instance to have two node waiting for free channel and startng to send at send time..not often implemented in libs though.
-
Souds great. I took a short pause because believe it or not, I was back to square one with the issues. A couple of days and one Adafruit Feather RFM69 plus one Sparkfun RFM69HCW breakout board later I still have no conclusion to what leads to the problems, at first I thought of bypassing the MySensor's directive and call the RFM69 drivers directly. It worked until it didn't, with no explanation whatsoever.
So I started from a couple of sketches I knew worked and slowly build up the correct configuration that's now working (partly but more on that in a separate topic). The most useful debug tool was an RTL-SDR stick so I could actually hear the nodes whisper
So, it appears that in order to use the 433/868/915 W/HW modules with MySensors, it's best to add theses at the top of your sketches:// Select the RFM69 radio type #define MY_RADIO_RFM69 // Enter your model's frequency #define MY_RFM69_FREQUENCY RF69_433MHZ // If you're using RFM69HW / RFM69HCW modules, they won't work until this is set. // Leave it commented for the normal power modules. #define MY_IS_RFM69HW // Your network ID #define MY_RFM69_NETWORKID 100The library is pretty much preconfigured for RF24 so using the RFM69 modules is possible but with a bit of trial and error until all things are set.
-
sure! you have to set all your defines for your node. before the mysensors include.
for the possible defines you can take a look at docs
https://www.mysensors.org/download/sensor_api_20
i also have an rtl-sdr. can be useful. cool
-
I find it very strange you experience these kind of problems. I have been using the RFM69 (both W and HW) since I started with MySensors a year ago.
The only time I had trouble with the range (or any transmission at all..) was when I used double sided perf-board to build my circuits on. Somehow the extra exposed copper reflects the RF energy in an unpredictable way so the radio will not send at all.Can you post a picture of your setup? Maybe we spot a tiny little thing that eff's up your testing.
-
I believe this one is on me. It wasn't clear to me that MySensors is actually wrapper of the original LowPowerLab's RFM69 lib and you can't mix #define's from MySensors and the embedded RFM69 driver.
MySensors is really plug&play if you're using the NRF24L01+ modules, follow the guides, upload the sketches and fire up the gateway, but if you want to use RFM69, I at least, needed some serious trial and error.
Maybe it's just my hectic style of trying new setups, or maybe because I found no concise guide on how to switch from RF24 to RFM69 or maybe something in between
-
@mihai.aldea great that you got it working. I believe many people would find such a guide useful. Would it be possible for you to summarize your experience? That summary could then be the base for a guide that we can add to the MySensors documentation.
-
@mfalkvidd I will definitely do that. I'll tinker with them for a while just to be confortable with stating the facts and I will compile such a guide. It'll take me no more than a couple of days.
-
@mihai.aldea great!
-
I configure the ESP8266 MQTT gateway using RFM69HW.
I define as follows
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RF69_433MHZ
#define MY_IS_RFM69HW
#define MY_RFM69_NETWORKID 100
#define RF69_IRQ_PIN 4
#define RF69_SPI_CS 15
#define MY_RF69_IRQ_PIN RF69_IRQ_PIN
#define MY_RF69_SPI_CS RF69_SPI_CSFor node side, I use Promini ATMEGA328
#define MY_NODE_ID 7
#define MY_PARENT_NODE_ID 0
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RF69_433MHZ
#define MY_IS_RFM69HW
#define MY_RFM69_NETWORKID 100
#define RF69_IRQ_PIN 2
#define RF69_SPI_CS 10
#define MY_RF69_IRQ_PIN RF69_IRQ_PIN
#define MY_RF69_SPI_CS RF69_SPI_CSBut, the node (Promini) can not communicate with the gateway
1487370 !TSM:FPAR:NO REPLY
1487372 TSM:FPAR
1487503 TSF:MSG:SEND,7-7-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
1489510 !TSM:FPAR:NO REPLY
1489512 TSM:FPAR
1489643 TSF:MSG:SEND,7-7-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
1491650 !TSM:FPAR:FAIL
1491652 TSM:FAIL:CNT=7
1491654 TSM:FAIL:PDTIs there any hint to do ?
-
@maman Try to downgrade to 2.0.0 if you are using any newer lib.
The newer libs over 2.0.0 does not work for my esp8266 mqtt gateway either.
-
@Yeitso Thanks, I will try to downgrade the mysensors library.
Can you share the #define script that working on ATMEGA328 and ESP8266 board ?
Thanks for your help.
Regards,
Maman
-
Hi @executivul ,
You mentioned in your post that the length of the antenna must be tuned to the circuit - would you mind sharing the process to do the tuning?
Thanks!
-
@manutremo said in RFM69 range issues:
Hi @executivul ,
You mentioned in your post that the length of the antenna must be tuned to the circuit - would you mind sharing the process to do the tuning?https://www.mysensors.org/build/connect_radio
Down near the bottom of the page is the lengths of antenna needed for the three primary frequencies used by the RFM board.
-
I've seen that page, thanks. If you read the post I'm referring to, @executivul used some specific procedure to tune the antenna further than just using the theoretical length.
