I am trying to write some code to limit the number of unsync’d .qo notes in the event of a long term loss of signal. My idea was to use note.changes, with max = 1 and delete = true to delete the oldest note.
However the documentation does not say that this is guaranteed to return the oldest note, so I wanted to check.
It sounds like you may be designing your firmware to circumvent one of the core advantages of the Notecard! There is a lot of flash storage available on all models of the Notecard (at least 800KB), so especially when you use templated Notefiles (which you should always do!) you can store a considerable amount of data between syncs with Notehub.
True it does sound like that, but that’s not my intent! If I’m not mistaken the only mechanism built in to the notecard is to stop adding notes if the notefile has reached it’s maximum size. This behaviour means old notes are kept and new notes are dropped, which is the opposite of what I want. This is really fail safe operation in times when a unit might be without reception for an extended time.
I am not using JSON as it doesn’t really suit my data, I’m currently adding binary data as a payload. Can a template still help? If I had a template with a max payload set to say 256 bytes, would it send 256 bytes every time, even if the actual payload is much smaller? Or would the compression reduce this to roughly the bytes actually added.
I did have another side question, the docs say max payload is 256 bytes for a note, is this 256 after encoding to base64 or before?
If I’m not mistaken the only mechanism built in to the notecard is to stop adding notes if the notefile has reached it’s maximum size. This behaviour means old notes are kept and new notes are dropped, which is the opposite of what I want. This is really fail safe operation in times when a unit might be without reception for an extended time.
Got it. The trick is that this is the antithesis of what the Notecard was designed around (i.e. storing all your data, allowing for low-power, occasionally connected products). Templates can still help because they lift the 100 Note max per Notefile…and storage wise I just ran the following test of adding 256 byte payloads on a Notecard WBNAN and was able to add 2842 Notes until it stopped allowing additional ones:
The user-addressable flash storage on each Notecard model can vary a little, so if you tell me which one(s) you are using I’d be happy to re-run this test.
If I had a template with a max payload set to say 256 bytes, would it send 256 bytes every time, even if the actual payload is much smaller?
No, you’ll only transfer the bytes in the Note (nothing more aside from some small overhead).
the docs say max payload is 256 bytes for a note, is this 256 after encoding to base64 or before?
OK, thanks for the information it’s really useful. It sounds like there are still some advantages to using an empty template, even though I’m only using the payload. Did you have any information on my original question? Would this request return and delete the oldest note?
So as I understand it, there has to be a sort of a stateful storage tracking on firmware side?
I suppose we could use some subset of notecard API to approximate the Notecard capacity?
You can always check the available Notecard storage by issuing a card.status request and looking at the storage response. This shows the percentage of Notecard flash that is in use. Just note that the user-accessible portion of Notecard’s flash storage is 80% of the total available.