I’ve been using a reduced SEGMENT_DELAY in my rust-version of the notecard driver (GitHub - gauteh/notecard-rs: Rust driver for the Blues.io Notecard (https://blues.io/products/notecard/)). I’m sending 50Hz of 3x float16 continuously back home, and it takes about 20 seconds to accumulate 1024 sample-triplets. If I use the default SEGMENT_DELAY and CHUNK_DELAY from note-c sending a message takes about 15-16 seconds, almost the same time as it takes to send the data. So if I need to do anything else in series with this I’m basically at the limit.
Is there any way to increase the transfer speed (either SEGMENT_DELAY) or maybe increase the I2C speed? If there could be some backpressure from the notecard on whether it is ready for the next chunk/segment that could maybe also improve things.
Usually the SEGMENT_DELAY of 100ms works fine in the lab, but once I have the notecard moving around I start getting spurious errors related to communication with the notecard: I have a theory about this being related to the GPS, but it is very difficult to pin it down. I have observed these for months, but without being able to determine exactly what the issue is. I will check if I get the same error with the standard SEGMENT_DELAY as well.
Those delays exist to prevent overrunning the Notecard with a large volume of requests while it is performing other computational-intensive tasks. It’s wise to consider the Notecard as a microcontroller itself and the fact that it is doing many things concurrently.
Both serial and I2C are implemented with no flow control - neither positive nor negative - hence the need for the delays. We have no plans to implement serial flow control (either hardware or software) but we will think about what might be doable on I2C.
In the meantime, we have a few questions related to how you are transferring data to the service:
Are you operating in periodic mode and using binary payloads on templated notes? If so, how large is the binary payload you transfer on a single note?
Or, are you operating in continuous and using payloads on web.* requests? If so, how large is the binary payload you transfer on a single web.put/web.post?
Or, are you doing something else? If so, what, and what is the specific nature of what you are transferring to/through the Notecard?
How are you using GPS, specifically? Internal (on the Notecard) or an external GPS module? Continuous or periodic mode, and at what interval? Are you using it to just update the Notecard’s location so Notes get tagged, or are you using a card.track mode to create notes in _track.qo at some interval?
Great! Something like the read-protocol where you ask for available bytes + delay would also work.
Yes, periodic. Templates + payload: The binary payload (encode to base64) is 1024 * 3 bytes long, or calculated to be a maximum of: { 1024 * 3 * 2 } * 4 / 3 + 4 base64 encoded.
No.
No.
Internal notecard GPS: I have it set up periodic + heartbeat. Every 10 minutes, heartbeat set to 1 (hour). It’s logging to _track.qo, and I also use it in my data (taking the position at the start of a data-series).
With v 3.4 of the firmware the reduced delays works fine!
I have some errors that start happening in I2C comms when I start moving the device (which is why I suspect this happens when the accelerometer triggers the GPS):
'cannot interpret JSON: unrecognized base64 at offset 2076 {io}'
'cannot interpret JSON: '}' expected near 'req' {io}'
cannot interpret JSON: '}' expected near 'req' {io}'
'cannot interpret JSON: unrecognized base64 at offset 4926 {io}'
It requires some movement, so its difficult to reproduce this with the notecard hooked up with FTDI or USB cable for a trace.