Sleep/Wake/TXRx Cycle
-
@Yveaux said:
@hek I had a quick look at the Sensor.cpp code and all sends seem to boil down to Sensor::sendWrite.
And what's in there? "WAIT FOR ACK" which can take 50ms???This is the old inter-node ack mechanism used in 1.3 (long story why we had to do it like this). This should not be mixed up with full route ack messages used from source to final destination.
This code has been replaced by the NRF build-in ack/retransmission functionality in 1.4.
-
@Yveaux said:
@hek I had a quick look at the Sensor.cpp code and all sends seem to boil down to Sensor::sendWrite.
And what's in there? "WAIT FOR ACK" which can take 50ms???This is the old inter-node ack mechanism used in 1.3 (long story why we had to do it like this). This should not be mixed up with full route ack messages used from source to final destination.
This code has been replaced by the NRF build-in ack/retransmission functionality in 1.4.
-
Hi guys,
I checked again, with another scope (1 GHz Tektronix) and I get 1.44s total time. It must be hardware or software related, not measurement related. Any other ideas to fix? I need to run the node without a gateway, because the measurement must be made off-site from vera and the gateway.
-
@therik said:
No modification: current from battery: 2.24 mA, current to pro-mini: 1.63 mA
Remove LED: current form battery: 144 µA, current to pro-mini: 104 µA
Remove LED and regulator: current from battery: 48 µA, current to pro-mini: 23 µAThis refers to removing a power-on LED from the APM, right? (The LED from the china booster already being removed).
And you were feeding power to the APM's VCC (ie: output of it's onboard linear regulator) until the third measurement, where you removed the unused regulator as well from the APM?
That's excellent low power for a cheap booster!
Did you remove the LED and reg with a simple soldering iron?
Only thing is, that bottom trace looks kinda choppy. No problems with powering the radio directly from the booster?
(All this leaving aside the slow timing. I understand that 1.3's timeouts were 50ms and it probably did a bunch of them because there was nobody to respond, but why would the lower current first part - presumably doing sensor measurements - take so long?).
-
Hi guys,
I checked again, with another scope (1 GHz Tektronix) and I get 1.44s total time. It must be hardware or software related, not measurement related. Any other ideas to fix? I need to run the node without a gateway, because the measurement must be made off-site from vera and the gateway.
-
Okay, did the toggle test using the delayMicroseconds() method. I tested 96 µs, 1000 µs, and 10 ms and all were very close to the set delay, pins 6, 5, and 4 respectively. (@ 8 MHz the delay is a multiple of 8 µs).
It must be the fact that I'm trying the MySensors temperature sketch 'gatewayless'. I wonder if I can modify the sketch to not wait for an ACK. Of course, when I get a scope at home the 'gatewayless' operation will not be needed.
-
Okay, did the toggle test using the delayMicroseconds() method. I tested 96 µs, 1000 µs, and 10 ms and all were very close to the set delay, pins 6, 5, and 4 respectively. (@ 8 MHz the delay is a multiple of 8 µs).
It must be the fact that I'm trying the MySensors temperature sketch 'gatewayless'. I wonder if I can modify the sketch to not wait for an ACK. Of course, when I get a scope at home the 'gatewayless' operation will not be needed.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login