Sensebender Micro

[Anticimex]

@alexsh1 like I said, signing is not in itself the problem. The problem is that big messages are failing. You can just try by generating big messages yourself and you will get the same problem. I know this by looking on what generates st=fail and it is the transport layer. Signing generates the data to be transmitted, and this data is printed and shown to be correct. Bigger messages require more reliable communications. Shorter messages has a better chance of being transmitted correctly. It is that simple. Many have reported the sake issue and have solved it by improving radio power decoupling, rearranging the sensor placement or improve the power supplies.

[alexsh1]

@Anticimex said:
Many have reported the sake issue and have solved it by improving radio power decoupling, rearranging the sensor placement or improve the power supplies.

I tried

1. powering GW/Sensobender from a different source (battery, USB, PSU - 12V in case of GW, 5v in case of sensebender via LDO)

2. swapped a few radios. Most of these are from working nodes with caps soldered. Maybe I should try completely different ones from a different batch? I mixed up three batches with no improvement.

3. Tried to place GW and the sensebender 1m/5m/10m apart

4. GW radio is powered via the AMS1117 3.3v

So far it is the same result. Not sure I can come up with anything obvious unless you can suggest

[Anticimex]

@alexsh1 sorry, I have not much else to suggest except experimenting with delays to see if the issue with failed transmissions at node startup can be avoided. I am no specialist on the radio. I'm the security guy and I see no wrong with the behaviour of those parts so I am short of any more useful suggestions I am afraid.

[hek]

@alexsh1

When did you last update the library (on the gw)? @Yveaux recently added a irq-based de-queuing from the radios FIFO. It could help on improving things.

Otherwise the only advice I have is to skip any amplified radio on gateway (if you have) and tweak powering of radio power on gw.

[alexsh1]

@Anticimex Well, at least we are fine on the security part :-)
I'll experiment more on the radio part when I have time - why there are only 24h in a day? (rhetorical question)

[alexsh1]

@hek said:

@alexsh1

When did you last update the library (on the gw)? @Yveaux recently added a irq-based de-queuing from the radios FIFO. It could help on improving things.

Otherwise the only advice I have is to skip any amplified radio on gateway (if you have) and tweak powering of radio power on gw.

@hek
I downloaded the dev on 26/05 so it is very recent.
I have normal radios both ends, but the idea is to have amplified one on the GW as well and change rf24_pa_max. Additionally, I'll try to mix as many radios as I can have. Who knows?

To be honest, things were working OKish before as I took it seriously decoupling radios etc. This voodoo dance around radios really irritates me. Life is too short to waist it - I am now thinking seriously switching to RMF69W or probably to RFM95* (Lora)

[Anticimex]

@alexsh1 yesh i have bashed my head on rf24 stability myself and have decided to base my network on rfm69:s instead. Too much chatter @2.4ghz. I hope the 69:s have better range and they also have the bonus of AES encryption in hw if you want to obfuscate the communication some. Signing adds netter security, but the paranoid can combine signing with encryption :) (yes rf24 can use AES encryption in software, but that cost memory and some overhead instead)

[alexsh1]

Whatever I did, did not help to solve st=fail

When I disable signing I have got the following (not a signle st=fail):

Starting sensor (RNONA-, 2.0.0-beta)
Radio init successful.
Sensebender Micro FW 1.5 - Online!
send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=17,sg=0,st=ok:Sensebender Micro
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.5
send: 3-3-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=2,c=0,t=7,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=3,c=0,t=13,pt=0,l=0,sg=0,st=ok:
isMetric: 1
TempDiff :125.61
HumDiff  :150.00
T: 25.61
H: 50
send: 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:25.6
send: 3-3-0-0 s=2,c=1,t=1,pt=2,l=2,sg=0,st=ok:50
send: 3-3-0-0 s=3,c=1,t=38,pt=7,l=5,sg=0,st=ok:3.09
send: 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:85

I am going to try different channels now with signing

[Anticimex]

@alexsh1 yes, without signing your messages are significantly shorter, and thus have a better chance of getting through. You can try experimenting with amplification as well.

[Yveaux]

@Anticimex just a noob question: do you have an idea of the performance penalty of (software) signing? Any benchmark figures?

[Anticimex]

@Yveaux no, sorry have not got around to compare them. But software signing is actually quicker due to the single write bit banging for the atsha204a. One way to see the difference is measuring the delay for an ACK to come back from a node that require signed messages. I have no figures, but a node with software signing responds slightly faster.

[Yveaux]

@Anticimex But is it significantly slower than without any signing?

[Anticimex]

@Yveaux yes. But I know that significant improvements can be made in the nonce whitening. It incrementally calculates a hash which is which is far less efficient than calculate the hash of a buffer. So there are room for improvements. I just wish there were more time, and now my arduinos are packed down so I wont be able to test. But volunteers are welcome, I can still code :)

[alexsh1]

@Anticimex said:

@alexsh1 yes, without signing your messages are significantly shorter, and thus have a better chance of getting through. You can try experimenting with amplification as well.

Do you think a message size has anything to do with st=fail?

[Anticimex]

@alexsh1 yes, like I have said here and in other topics, signing often gets the blame for transmission problems because with signing the maximum message buffer is used, and larger messages are more difficult to transmit than short ones. So if you have a poor connection, odds are that a larger message will fail more often than a short one.

[alexsh1]

@Anticimex said:

@alexsh1 yes, like I have said here and in other topics, signing often gets the blame for transmission problems because with signing the maximum message buffer is used, and larger messages are more difficult to transmit than short ones. So if you have a poor connection, odds are that a larger message will fail more often than a short one.

I do not think its signing, but I think it is implementation of signing and sending.
I do not get st=fail after the initial 9 messages not even once. Something is just very-very odd.

[ximinez]

I'm seeing the same failed signings when the device powers up, but it doesn't fail after those.

[alexsh1]

@ximinez said:

I'm seeing the same failed signings when the device powers up, but it doesn't fail after those.

Did you manage to get it sorted?

[ximinez]

I just ignore the first fails. It works after that, and has done so for close to a month.

[Anticimex]

Well, if you think the signing implementation cause initial radio transmissions to fail I am afraid I will need your help in explaining how. Because I fail to see any connection between signing and radio behaviour. st=fail is a transmission problem, and signing implementation require flawless transmissions. I also suspect you both use nrf24 and I also suspect you will not see this if you use rfm69 although I use nrf24 myself for testing and I have not seen what you report. But I am sure you really experience this strange behaviour. But I maintain that it is due to some startup problems of the radio. I am afraid I cannot find anything I can change in the signing codebase to have an influence on st=ok or st=fail. But I am all ears to suggestions of course if you see something suspicious.