RFM69 range issues

[mihai.aldea]

@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.

[scalz]

@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 time ;)

About promiscuous mode, you can think about it as a sniffer mode.

Great to hear you finally found your answer :)

[mihai.aldea]

@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 time ;)

About 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.

[scalz]

@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 see

I hope you'll get your thing running as you want ;)

[mihai.aldea]

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.

[scalz]

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.

[mihai.aldea]

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 :grin:
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 100

The 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.

[scalz]

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 :)

[DavidZH]

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.

[mihai.aldea]

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 :yum:

[mfalkvidd]

@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.

[mihai.aldea]

@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.

[mfalkvidd]

@mihai.aldea great!

[maman]

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_CS

For 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_CS

But, 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:PDT

Is there any hint to do ?

[Yeitso]

@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.

[maman]

@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

[manutremo]

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!

[Chester]

@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.

[manutremo]

@Chester

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.