Disable node ACK

[mihai.aldea]

I'm currently testing some RFM69 sensors.
I added a few lines of codes to count the temperature conversion + TX time, just to see the impact of various settings over the awake cycle and to properly adjust them for battery usage.
One of the test nodes is a battery powered Adafruit Feather which I left in the same room with the gateway that I hooked up to an 18650 Li-Ion battery and used the Feather's internal charge controller and battery protection circuit for these experiments.
After a couple of days, the battery was at a constant 85%. Then I moved it to the other end of my apartment with 4 brick walls between the node and the gateway. I also added a visual "probe" to the sketch, that's keeping the board's led lit while performing the loop tasks. I noticed that in the distant corner of my apartment the led was lit for a lot more time than in the same room with the gateway.
Needless to say that with these very long duty cycles the battery drained within 2 days. It's taking the node about 250ms to send the data to the gateway when in the same room and 750-1000ms to send it while being in the distant room.
I haven't found any accurate information on whether the ACK can be enabled or disabled, if so then what's the default setting. And does it serve any special purpose like RSSI reporting which if used it automatically enables the ACK?
The thing is that RSSI = Received Signal Strength Indicator and if the sensor node can read this value, it's obvious that it's reporting a received signal strength. And what else can the sensor receive from the gateway on a regular basis if not an ACK?

[mfalkvidd]

@mihai.aldea as you know, rssi support was added very recently. So everything works the way it works because rssi was not available before. That should not be surprising.

However, if rssi can be used reliably, maybe it can be used as an indicator for reliable delivery.

I think the relevant code is at
https://github.com/mysensors/MySensors/blob/dd9dff77ed1948db2b348bbdb82d0d3daa9e8e3a/drivers/RFM69/RFM69.h#L125

and
https://github.com/mysensors/MySensors/blob/dd9dff77ed1948db2b348bbdb82d0d3daa9e8e3a/drivers/RFM69/RFM69.cpp#L239

I don't have any rfm69 radios but the code looks really flexible. You should be able to experiment and adjust and find out which solutions are good.

From what I can see in the code (and according to https://forum.mysensors.org/topic/5679/radio-network-questions/3 ) the rfm69 does not retry messages. So maybe the node is doing something else?

[mihai.aldea]

I am using stoltz's fork it it looks that the references above are not availble. Anyway, the RSSI should be implemented at the gateway level. Else, a node may read this value but only in response to an incoming packet and that implies a longer duty cycle.

[scalz]

in future rfm69 driver, you'll be able to get :

• rssi of a received packet, so on receiving node side.
• rssi of a response, at the sending side.

but for the moment, sure, you need to use the simple rssi from old driver. still nice
For your tests, and regarding ack, you can do :

• send(msg.set(payload), bool ack) eg. send(mymsg, false) for no ack

[mihai.aldea]

It doesn't appear to work. Here's what I did:

send(msgTemp.set(temp,2),false);
send(msgRh.set(rh,2),false);
send(msgRSSI.set(rssiStr),false);
send(msgTime.set(txTime/1000),false);
sendBatteryLevel(battPcnt,false);

Here's a regular cycle:

4141 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:27.58
4200 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=OK:44.00
4241 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=28,pt=0,l=9,sg=0,ft=0,st=OK:rssi: 52%
4280 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=48,pt=5,l=4,sg=0,ft=0,st=OK:244
4315 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:100
Time awake: 244ms

and here's one that's taking way too long

4419 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:27.58
4601 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=OK:43.98
5007 !TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=28,pt=0,l=9,sg=0,ft=0,st=NACK:rssi: 52%
5044 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=48,pt=5,l=4,sg=0,ft=1,st=OK:760
5079 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:100
Time awake: 760ms

Notice the NACK?

EDIT: The result above is from after I applied the suggested mods.

[Fabien]

Wich gateway you use ? It seems like node doens't recieve harware ACK from gateway.
You have hardware ACK if i remember and 5 tries. So it's longer because of retries.
You loose 1 packet because all retries fails.
I suppose power supply on gateway radio is not sufficient. I have same problem with UNO and NodeMCU gateway with internal regulator.

[mihai.aldea]

@Fabien said:

Wich gateway you use ?

I'm using the serial gateway, nothing special about it.

It seems like node doens't recieve harware ACK from gateway.

Hence the reason of opening this discussion. Is this ACK really needed? If not, can it be disabled?

You have hardware ACK if i remember and 5 tries. So it's longer because of retries.

That's something I never heard of so far. But if I didn't hear it, it doesn't mean you're right. Are you absolutely sure that the RFM69 has embedded ACK capabilities? I haven't found this info in the datasheet.

You loose 1 packet because all retries fails.
I suppose power supply on gateway radio is not sufficient. I have same problem with UNO and NodeMCU gateway with internal regulator.

I must admit that I'm not using the greatest power supply on the gateway radio, but if there weren't no ACK's requested from the sensor node and it would just send the data "blindly" into the open, the gateway's power supply wouldn't be an issue. And the sensor node power supply is defintely not the culprit since it's powered by a bulky 18650 fully charged Li-Ion battery.

This all behaviour only means that each sensor node report also requests an ACK from the gateway. And my question is: how do I disable this, if possible? Installing a better antenna or a better power supply on the gateway will not cut it. Because there will always be some sensor nodes at the edge of the coverage area and if they'll ask for an ACK each time they send a reading, they will drain their batteries a whole lot faster than the nodes closer to the gateway.

[mihai.aldea]

@scalz said:

in future rfm69 driver, you'll be able to get :

• rssi of a received packet, so on receiving node side.

Just to make it clear, the "receiving node" is the gateway, right?

• rssi of a response, at the sending side.

This is pretty much what happens now, the sensor node couldn't report the RSSI for anything else than the ACK that the gateway sends back to it.

There must be good reason for which MySensors relies on these ACK packets but in my opinion this feature should only be used when needed, eg.: arming a motion sensor, turning off the heating or a switch a relay. But let's face it, is it really necessary for a temperature sensor node to make sure that its message was properly received by the gateway? There are lots of frontends who report an offline node if a flat graph line isn't enough.

[Fabien]

I'm not agree with you. It will be better to user proper power supply on you gateway (not only 230V power supply but Arduino board with good 3.3V IC regulator (not from ali, ebay ...)
But to answer your question I think you can change this line : https://github.com/mysensors/MySensors/blob/8fabae979a5af48254f2c43351eb311bf0ef4133/core/MyTransportRFM69.cpp#L57
with return _radio.send(to,data,len);
I'm not expert in Mysensors internal and someone who works on core can confirm.

[mihai.aldea]

@Fabien said:

I'm not agree with you. It will be better to user proper power supply on you gateway (not only 230V power supply but Arduino board with good 3.3V IC regulator (not from ali, ebay ...)

I won't argue about the quality of the components. However, as I mentioned before, using a good quality power supply will still not address the fact that MySensors is stubborn at exchanging ACK's and while this may not be an issue for battery powered nodes well within the gateway's range, the ones installed at the edge of the gateway coverage area (however optimized that would be) will still exhibit long awake cycles.
It's like an old local joke I heard a couple of years ago:
An very old lady living in the rural areas all her life had to travel by train. As this was the first train ride for her she was quite frightened and worried for her safety. She asked the train steward what is the most unsafe carriage of all. The guy said that he doesn't know, but she insisted. Just to get rid of her he said: OK, OK, the last carriage is the most unsafe. And she said: They why don't you remove it?
That may be a stupid joke, especially in translation, but it illustrates my problem. No matter what hardware I use, what awesome power supplies and antennas I use and how many square miles I cover with the RFM69 modules, the edge nodes will die way faster.

I will try your suggestion. Looks very promising.

[mihai.aldea]

No joy, it pops this error

/Documents/Arduino/libraries/Mysensors/core/MyTransportRFM69.cpp: In function 'bool transportSend(uint8_t, const void*, uint8_t)':
/Documents/Arduino/libraries/Mysensors/core/MyTransportRFM69.cpp:51:33: error: too few arguments to function 'bool RFM69_send(uint8_t, uint8_t*, uint8_t, rfm69_controlFlags_t, bool)'
  return RFM69_send(to, data, len);

[mihai.aldea]

Hey, it turns out that the fix is:

return RFM69_send(to, data, len, 0, 0);

Now I have a steady TX time, but the strange thing is that I'm still getting the RSSI reports. Anyway, since the RSSI is really voodoo right now, I will let it rest.
Thanks for your hint, it did the trick

[Fabien]

Ok I just see you are using @scalz new driver. I can't help you more on this driver but it still in dev.

[mihai.aldea]

Thank you, but right now everything's working as expected. My only concern is that the tweak you told me about should not be so obscure but way more visible and easy to toggle.
I'd like to have the input of a senior developer of MySensors because I may be mistaking but if not I don't know why no one considered this yet.