MQTTClientGateway broken after upgrade - signature failure

[tomkxy]

@hek Thanks!

After uploading to the Mega I receive intermittent the following error during initialization:

0;255;3;0;9;read register, reg=6, value=0
0;255;3;0;9;Sanity check failed: RF_SETUP register=0 instead of 39, check wiring, replace module or non-P version
0;255;3;0;9;Radio init failed. Check wiring.

Most of the time unplugging the Mega from power it goes away. This happens with two different modulesm one with external antenna and one without. Any idea?

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