Sensebender Micro
-
@hek said:
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)
@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)
-
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:85I am going to try different channels now with signing
-
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:85I am going to try different channels now with signing
@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 feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@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.
-
@Anticimex just a noob question: do you have an idea of the performance penalty of (software) signing? Any benchmark figures?
@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.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@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.
-
@Anticimex But is it significantly slower than without any signing?
@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 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.
@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 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?
@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.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@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.
@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. -
I'm seeing the same failed signings when the device powers up, but it doesn't fail after those.
-
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.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
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.
-
@Anticimex Interesting observation - another node with the same rf24l01+ radio from the sensebender with the same GW and signing works without st=fail. This is now clear that this is not a rf24l01+ hardware issue.
@alexsh1 Indeed. And also that it is not a signing issue since I take it you use the same FW?
I still think it is a HW issue. You have a new node, right? So the radio has a new power source?Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@alexsh1 Indeed. And also that it is not a signing issue since I take it you use the same FW?
I still think it is a HW issue. You have a new node, right? So the radio has a new power source?@Anticimex said:
@alexsh1 Indeed. And also that it is not a signing issue since I take it you use the same FW?
I still think it is a HW issue. You have a new node, right? So the radio has a new power source?Yes, I tried to compare apples with apples:
- it is the same distance / FW
- the code is different to the expend that the sensebender has got Si7021/ATSHA204a and the other sensor did not. I may try to upload a simplified code to the sensebender just to test it to make it a more equal comparison.
- the power source is the same - 5V 500mA via AMS1117 + cap
-
@Anticimex said:
@alexsh1 Indeed. And also that it is not a signing issue since I take it you use the same FW?
I still think it is a HW issue. You have a new node, right? So the radio has a new power source?Yes, I tried to compare apples with apples:
- it is the same distance / FW
- the code is different to the expend that the sensebender has got Si7021/ATSHA204a and the other sensor did not. I may try to upload a simplified code to the sensebender just to test it to make it a more equal comparison.
- the power source is the same - 5V 500mA via AMS1117 + cap
@alexsh1 You could also try soft signing on the sensebender and see if that makes a difference. Perhaps the atsha device interferes with the radio (this depends on routing and such things). I have no sensebender myself and I have not noticed the behavior you describe with nrf24 and atsha204a.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@alexsh1 You could also try soft signing on the sensebender and see if that makes a difference. Perhaps the atsha device interferes with the radio (this depends on routing and such things). I have no sensebender myself and I have not noticed the behavior you describe with nrf24 and atsha204a.
@Anticimex I tried the sensebender with soft singing - still the same st=fail
-
@Anticimex I tried the sensebender with soft singing - still the same st=fail
@alexsh1 Ok. I guess that is "good news for me" as it rules out signing related hardware as well. I guess so far, the only conclusion is that rf performance is to some extent degraded on the sensebender.
