Hello,

yes this is possible, here it is
https://www.mysensors.org/apidocs/group__RF24grp.html#gae6a732b8f49a8eb99ef65ae159c65e9c

and you may need to reinit transport layer at some point,
https://www.mysensors.org/apidocs/group__MyTransportgrp.html

https://www.mysensors.org/apidocs/index.html

@skywatch
no idea what you're trying to do, but maybe it would be better to use async/state machine.
why not doing something simple like this:

bool isFooEnabled= false;
loop() {
  if (!isFooEnabled) {
     doMain();
  }
  else {
   doFoo();
  }
}

receive() {
// on your msg, set isFooEnabled to true or false to start/stop doFoo
}

Like this nothing can block, your doFoo() doesn't need a while loop, you could just use if/then with states variables. Then on each arduino loop mysensors message will be processed and receive function called

Hi,

I also think in your case rfm95 or equivalent might be the solution.

About personal xp, I mostly use rfm69 in prod, 868mhz because 433mhz needs bigger antenna, and bigger gnd plane else you don't get the full range that 433 can provide. Note: available freq depends on where you live

I use ATC which sets emission power level from -18 to +13 (for rfm69cw) :

• gw is high power version (rfm69H or rfm95)
• homemade pcbs with optimizations for a good range, of course there are often compromises to do vs design
• rfm69cw (the low power version) and a short range of 10-12m, with 2x rock/concrete walls obstacles, I set ATC RSSI target= -87, and power level is autoadjusted to -11. So it can do a lot more than 10-12m at full power
• rfm69cw at 55m from the GW and it's ok, with many obstacles on the path (7x rock/concrete walls, a part of the roof is metallic, metallic doors etc)

As you can see, it's dependant of many factors as different people get different results.

answered here : https://forum.mysensors.org/topic/11404/rfm69hcw-beginning-of-a-newbie-with-atmega328p

Hi,

if you're new to mysensors and still don't have a network in prod, I would recommend to use the new driver.

example for rfm69cw

#define MY_RADIO_RFM69 
#define MY_RFM69_NEW_DRIVER
#define MY_RFM69_FREQUENCY			RFM69_868MHZ
 #define MY_SIGNAL_REPORT_ENABLED
#define MY_RFM69_ATC_TARGET_RSSI_DBM (-85)
//#define MY_RFM69_ENABLE_ENCRYPTION
//#define MY_DEBUG_VERBOSE_RFM69
//#define MY_RFM69_NETWORKID 110  
#define MY_RFM69_IRQ_PIN 2
#define MY_RFM69_CS_PIN 10

for rfm69H, add this too

#define MY_IS_RFM69HW

https://www.mysensors.org/apidocs/MyConfig_8h.html

you could also show your sketch, and logs so people can help you.

Hi.

I've some boards with TI mcus here (cc1310, cc135x). I started to take a look a few years ago for using MySensors protocol with it. But I miss time for this, and not sure if it's worth the effort to add more arch to MySensors.
Though, this mcu is not arduino compatible unless you use Energia project. It's easier to use with TI CCS ide. Great mcus, sure.

@mfalkvidd
yep I noticed that. I just provided a few feedbacks for his future sketches :)

@doodoovane
not sure if I get it, but the little sound could be generated by pwm freq.

Note, your last sketch is not ideal:

• don't send msg in receive(). it's better to update a variable, and check this variable in loop() for sending a msg, to avoid recursive call to receive()
• Same for your fading function, it's better to call it from loop(). Receive() should finish as fast as possible.
• don't use delay() in your fading function, it's a blocking function. It's better to do this async, in a non-blocking way, or use wait() as it can process received msg in background .

@KevinT
yes in general subghz radios have better range than 2.4ghz.
I might have farther nodes but for example, I have one rfm69cw at 55m from the GW and it's ok, with many obstacles on the path (7x rock walls, a part of the roof is metallic, metallic doors etc).
This depends on many factors of course

@KevinT
Indeed, that's not very good range.
As a rough comparison (because it can depend on others factors), with rfm69cw and a short range of 10-12m, with 2 bricks walls obstacles, I set ATC RSSI target= -87, and power level is autoadjusted to -11

So, regarding RFM69, for shorter ranges, RFM69W/CW can save power, and for others distances, RFM69H is better choice

I'm glad if I helped you :)

@KevinT
well, that's strange. Because lot of people experienced communication issues when missing the MY_IS_RFM69HW with RFM69H, very weak range or no comm. It's not about the library, it's about the module itself and its hardware implementation.

of course MY_RADIO_RFM69 is mandatory :)

do you get a usable range when using RFM69H as a RFM69W? As good as a RFM69W??

Here you can see PA0 is connected to RFIO pin which also handles the LNA, and PA1/2 to PA_BOOST pin

Here is how RFM69W works, it's just connected to RFIO, for PA0 and LNA

And, this is how RFM69H works. There is a RF Switch, which is controlled by the rxtx pin. So, in TX mode it uses PA_BOOST (PA1/2), and in RX mode it uses RFIO for LNA.

Note: all the tuning passives on both modules, on TX path, for tuning filtering etc.

So if you don't use the MY_IS_RFM69HW with a RFM69H, to only use PA0, then I doubt you can get same range as RFM69W.

Finally, I woud usually recommand to use MY_IS_RFM69HW if using RFM69HW/HCW and let ATC feature handles power level, or use a RFM69W/CW (with ATC too of course)

Here a few links which also explain this, but you can find more infos aboutthis on internet:
https://andrehessling.de/2015/02/07/figuring-out-the-power-level-settings-of-hoperfs-rfm69-hwhcw-modules/
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/standardise-mote-configuration-using-rfm69hw-only/

@KevinT
afaik you cannot use RFM69H without enabling MY_IS_RFM69HW, else there will be no rf output. So you can't use RFM69HW as a W module.

@Dirk_H

• old driver is based on an old lowpowerlab lib version
• new driver has been refactored and optimized. It's not compatible with old driver. Which means it should be deployed on gw and all nodes

About new driver:

• more features like : automatic power level control so it does not use more rf power than needed
• unified driver with Lora modules so they can communicate with rfm69 (rfm95<->rfm69 for example)
• handles SPI transaction so it should be compatible with HW SPI+W5100
• memory and speed optimizations
• etc

I don't know if it still works, but I tried (years ago) Nano gw + W5100 + RFM69 + HW SPI, and it was ok. No time for the moment to re-test it unfortunately (I don't use this setup in prod).

That said if you got it working with new driver, that's what I would use for sure

@NeverDie
I agree too. I don't think a Lora module is overkill, it has interesting features. it just depends on project criteria, there are also commercial products using rfm69.

A nice setup is using rfm95/Lora module on gw, then you can use rfm69 and rfm95/Lora modules for nodes depending on requirements.

I don't need to mention antenna tuning etc for diy nodes, but it's good to remember, software needs to be compliant too with regulations.
MySensors lets that freedom to users, so nothing prevents them to use too high power levels, or flood a rf band, break duty cycle, and become an outlaw..

Still, there are basic mechanisms in MySensors, available only for rfm69/95, like:

• listen before send, for free channel
• automatic power control for better battery lifetime, and greener communication which dials down TX power to very low levels. But it requires to use new rfm69/95 driver.

Enjoy :)

@keithJ
it sounds like you have a problem with IRQ mapping. If bad irq mapping, then no irq is triggered and it can't receive any reply.

it could be your RFM69_INT define, which is not a MySensors define afaik. So I guess it uses MySensors default mapping

Instead, try to use this define : MY_RFM69_IRQ_PIN

You don't need to handle rst pin in before(), as MySensors driver already does it when it's defined.

I use new rfm69 driver (different than lowpowerlab driver), and no problem, even when modules are close on same desk. In that case, TX power level will auto adjust to use as less power as possible.

yes, rf module directly connected to rpi is not ideal, as rpi doesn't provide a very clean RF power source.

@NeverDie
lora modules are more expensive. You can find rfm69 for 1.8€ shipping included which work great and they are widely available compared to some lora modules.
I think it depends on projects goals.
But I agree with your points of course :)

@BearWithBeard nice pic, could be added to the radio guide, sure

well, the thing to remember when you don't have any pic, is H (High power version) require more IC for RF because of the power amplifier whereas non-H (low power version) only has passives parts (res, capa etc).
And on non-C version (HW and W), there are pads close to the crystal.

@projectMarvin said in Second setup, choosing a radio:

I'm currently in China, 915 and 868 are not legal here :/

oki!

Yes there are some, but even on aliexpress when you look at the sales numbers you will see that basically no one are buying the rfm69w/hw and quite few are selling them.

Still it's available for ordering. I prefer using HCW and CW because they have a more compact footprint. but I ordered HW/W in the past on aliexpress too, no problem. works the same, only the pinout changes.

Really? How does this work? Do you reprogram them?
Considering they are different size, different number of pins and have the pins in different positions.

Nope. RFM69HCW and RFM95 have same size and mapping, you can take a look in datasheets. Note: only HCW variant is compatible.

Does is also work with rfm69 <-> rfm96 & rfm98? (96/98 are 433 MHz :) )
If so this would be really interesting solution.

Unfortunately, we test what we have in stock and use, so I've no idea about those 433mhz modules..maybe yes in theory, but I've never tried this setup.