Again; Thanks so much for your help with this. Peter: Hugo’s test code was configured for 1200, our system is running at 9600.
You are correct, the problem with the 500mS was the onidle code I was running would put it back to sleep before data was received. We then went to 1 mS, and then 5mS. (see email above)
If the delay between pin1 going high and transmission of data starting is 11mS will that
a) be enough time for the impee to boot, configure the uart, and get ready to read, and
b) not enough time to retrigger an onidle
?
Hugo sorry about not posting all the code. I actually took it out of the above post because I thought it was redundant. Here is the code as I was running it above.
`// This code wakes on pin 1 and then waits for up to 1s for serial data to
// start being received. When data starts to flow, the code will keep receiving
// data until there’s a break of 0.5s.
//
// It will then log the serial data and sleep again. Note that the WiFi link
// does not come up until the device is about to sleep (it is in a shallow wake
// mode until the server.log).
s <-"";
sleeptimer <- null;
now <- hardware.millis();
// Empty buffer, accumulate it
function EMBData() {
s += EMB.readstring();
// If we have anything in there, then reset sleep timer to trigger
// after 0.5s with no serial data received
if (s != “”) {
if (sleeptimer != null) imp.cancelwakeup(sleeptimer);
sleeptimer = imp.wakeup(0.5, sleepnow)
}
}
function sleepnow() {
imp.onidle(function() {
now = hardware.millis() - now;
server.log(“awake for “+now+“ms, got string '”+s.len()+”’, going to sleep”);
server.log (s);
server.sleepfor(200);
});
}
// UART config
hardware.pin1.configure(DIGITAL_IN_WAKEUP);
EMB <- hardware.uart1289;
EMB.configure(9600, 8, PARITY_NONE, 1, NO_CTSRTS, EMBData);
// Set an initial timeout of 1s for data
sleeptimer = imp.wakeup(1.0, sleepnow);`
And here is the response from the run this morning.
2015-03-30 09:25:38 UTC-5 [Status] Device connected; 2.61% program storage used 2015-03-30 09:25:38 UTC-5 [Device] awake for 529ms, got string '23', going to sleep 2015-03-30 09:25:38 UTC-5 [Device] binary: 4c a9 62 82 ba ca 72 82 62 82 ba c2 72 aa 62 8a 82 82 72 82 6a 0a 00 2015-03-30 09:25:38 UTC-5 [Device] sleeping until 1427725738000 2015-03-30 09:27:24 UTC-5 [Status] Device disconnected 2015-03-30 09:28:43 UTC-5 [Status] Device disconnected 2015-03-30 09:28:43 UTC-5 [Status] Device connected; 2.61% program storage used 2015-03-30 09:28:43 UTC-5 [Device] awake for 529ms, got string '23', going to sleep 2015-03-30 09:28:43 UTC-5 [Device] binary: 72 aa 62 82 ba ca 72 82 62 82 ba c2 72 aa 62 8a 82 82 72 82 6a 0a 00 2015-03-30 09:28:43 UTC-5 [Device] sleeping until 1427725923000 2015-03-30 09:31:48 UTC-5 [Status] Device disconnected 2015-03-30 09:31:48 UTC-5 [Status] Device connected; 2.61% program storage used 2015-03-30 09:31:48 UTC-5 [Device] awake for 529ms, got string '23', going to sleep 2015-03-30 09:31:48 UTC-5 [Device] binary: 72 aa 62 82 ba ca 72 82 62 82 ba c2 72 aa 62 8a 82 82 72 82 6a 0a 00 2015-03-30 09:31:48 UTC-5 [Device] sleeping until 1427726108000
If you think the s.len() and the second server log is affecting performance please let me know and I will run it again. I made this change because, when s is filled with junk that entire server.log gets shown as “binary: hex hex hex hex hex…” and I wanted to see the millisecond timing without having to convert it manually every time. It was easiest to change it to show s.len(). And then show s in the second server.log.