Disable node ACK

[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 :confused:

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

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