MQTTClientGateway broken after upgrade - signature failure

[tomkxy]

@Anticimex I am still digging.... Now I figured the following:

The moment I disable MY_SIGNING_REQUEST_SIGNATURES on the sensor node while still having it on the gateway enabled sensor data is received and properly processed on gateway.

I am now a bit puzzled. Am I right assuming that if MY_SIGNING_REQUEST_SIGNATURES is enabled on gateway that sensors nodes need to sign messages to the gateway?

[Anticimex]

@tomkxy no. GW will only require signatures from nodes that require signatures. Else it would require it from every node.

[tomkxy]

@Anticimex @Hek I hacked now my sketches and tested the following scenarios:

1. sending a full payload from the sensor to the gateway in form of a nonce response
   -> it was received by the gateway and dropped -> ok
2. doing the same as above but from the gateway to a node (the node was in a _process() loop) -> transmission failure

So it seems that the sending side from the gateway to the sensor makes trouble, or the other way round receiving on the sensor node. I have not enough know regarding RF communication but this kind of asymetry seems to be strange.
Any idea what I can try or who might be able to help?

[Anticimex]

@tomkxy it is not totally strange that TX and RX performance differ. You could try to move your node around a bit and see if it is affected by location. Fiddling a bit with the transmission strength could also be a thing to try.

[tomkxy]

@Anticimex I expanded on my previous experiment. I do not require full payload. If I just transmit one byte, most of the transmissions fail.

So I need to investigate the sending node which is a Arduino Mega with an Ethernet shield...

[hek]

If you're using the 3v3 line on the mega, think again. When I tried that, I got very much transmission failures. It's crap. Use a regulator from the 5V rail.

[tomkxy]

@Anticimex @Hek thanks a lot for your support. This is very much appreciated.

I did now the following:

• solder a 4.7uf directly on the radio
• changed to the 5v power rail from the Mega, utilizing a regulator
• moved both nodes farer away

Results are much better but still not as reliable as I would need. One node acting as repeater does not get any response to its "parent" broadcasts (need to investigate this).

After some research I read that the Mega is probably not the best combination due to its current supply.
What would be a suitable alternative to the Mega (>32kb memory) which provides more reliably power?

[tomkxy]

Finally, I have everything working again. Again a big thanks to @hek and @Anticimex .

As lessons learnt, I did the following:

• Solder 4.7uf directly on the radio
• Changed to the 5v power rail from the Mega, utilizing a regulator
• Put a 100 uf between 5v and gnd on the Mega
• Moved both nodes farer away (when I was testing I had same lying side by side which obviously created interferences)
• Switched the RF24 channel utilizing a channel which was not so polluted by all the Wifis around me

[Anticimex]

Great news!

[noelgeorgi]

@tomkxy there's an android app named wifi analyser and use that to check the crowded wifi channels and set the rf24 channel to the least crowded one.... wish i had an SDR for more hacking and learning:disappointed_relieved: