-
Notifications
You must be signed in to change notification settings - Fork 50
Description
Subject of the issue
For long sample rates, it can be very hard to get into the console. It would be nice if for sample rates > maxUsBeforeSleep * 30 (60 seconds) there was a delay between printing out the line of logged data to the console and going back to sleep.
In our use case, we're logging every 30 minutes and have Bluetooth console access via the serial pins. It can be very hard to catch the console. We have ended up just sending a constant stream of characters to the OLA via BT until we get in the console. This is terribly inefficient on several levels. We'd prefer to just wait for some characters to come from the OLA, then try to connect to console.
Your workbench
OLA
BT module on serial pins (not required)
Steps to reproduce
Try to access console at slow sample rates as soon as you see serial log output.
Expected behavior
When characters are seen from the OLA, there should be a little time for the OLA to check incoming serial characters.
Actual behavior
OLA only checks for characters after waking up, but before getting and reporting new data. No check is done after, except on first sample.
Perhaps something like this at the end of loop()
if (checkIfItIsTimeToSleep())
{
uint32_t msToSleep = howLongToSleepFor();
if ( settings.usBetweenReadings >= (maxUsBeforeSleep * 30))
{
delay(consoleDelay_ms); // There are much better ways of doing this, but perhaps not simpler.
if ((Serial.available()) || ((settings.useTxRxPinsForTerminal == true) && (SerialLog.available())))
menuMain(); //Present user menu
else msToSleep -= consoleDelay_ms;
}
goToSleep(msToSleep);
}