-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement batch transmission #479
base: develop
Are you sure you want to change the base?
Conversation
For future testing and development
Device still reports 3K RAM free
Saves 750 bytes of flash as the buffer can be placed in .bss to be zero-initialized instead of .data.
Use cleaner interface and common functions that avoid repeated snprintf and strlen usage to save ~2.5KB of flash and dozens of lines of code. Removes extra \r\n from HTTP requests as a side effect, which were against spec and caused spurious 400 Bad Request status messages from servers.
For testing the server component
Serialize timestamps and variable values to the data buffer, then unserialize and format into JSON arrays. Offers considerable data and power savings.
Clean up and make maintenance easier
Avoids unnecessary time and power consumption when publishers just plan to buffer the data.
The modem might not be able to accept the data written to it if its transmit buffer is full. In that case, the portion not accepted needs to be retried later. If we retry too many times, give up so we don't get stuck in an infinite loop.
Send the first few data points logged after initialization immediately instead of buffering them until the programmed interval elapses. Allows verification of functionality during deployment.
Avoid repeatedly retrying if the server is down, while still retrying a couple times in case the connection is unreliable.
Allows easy field verification of functionality as opposed to previous testing function which only served a purpose when attached to a computer (and consumed lots of flash).
Allows immediate transmission of data in buffer without loss before powering off and decomissioning a deployed datalogger.
Signed-off-by: Sara Damiano <[email protected]>
Signed-off-by: Sara Damiano <[email protected]>
Signed-off-by: Sara Damiano <[email protected]>
Signed-off-by: Sara Damiano <[email protected]>
Signed-off-by: Sara Damiano <[email protected]>
Signed-off-by: Sara Damiano <[email protected]>
Signed-off-by: Sara Damiano <[email protected]>
Signed-off-by: Sara Damiano <[email protected]>
Signed-off-by: Sara Damiano <[email protected]>
I am excited to see this moving forward, but I'm confused by the state of this PR. What was wrong with #453 ? It appears to be based on a prototype version of my code (instead of my PR), and misses several important things like the fix for crashing the modem, improvements to the transmission logic, and proper integration of the testing code. I am concerned by the re-addition of the testing mode. We had discussed together over Zoom as I recall and created the new testing method proposed in my PR. In particular, I am concerned that flushing won't work properly anymore and users will lose data. I'm also confused by the partial addition of FIFO support, shouldn't that be in a followup PR? |
Re-created from modifications to: