0

I'm looking to fetch recorded data using LogBook in a custom Movesense firmware. How do I get the correct byte stream offset for the next GET call when receiving HTTP_CONTINUE?

I'm trying to implement these steps as described in DataStorage.md:

### /Logbook usage ###

To get recording from the Movesense sensors EEPROM storage, you need to:

1. Do **GET** on  */Logbook/Entries*. This returns a list of LogEntry objects. If the status was HTTP_OK, the list is complete. If the result code is HTTP_CONTINUE, you must GET again with the parameter StartAfterId set to the Id of the last entry you received and you'll get the next entries.

2. Choose the Log that you are interested in and notice the Id of it.

3. Fetch the descriptors with **GET** to */Logbook/byId/<Id>/Descriptors*. This returns a bytestream with the similar HTTP_CONTINUE handling as above. However you **must** keep re-requesting the **GET** until you get error or HTTP_OK, or the Logbook service will stay "in the middle of the stream" (we hope to remove this limitation in the future).

4. Fetch the data with **GET** to */Logbook/byId/<Id>/Data*. This returns also a bytestream (just like the */Logbook/Descriptors* above). 

5. Convert the data using the converter tools or classes. (To Be Continued...)

The problem is basically the same for step 3 and 4. I receive a whiteboard::ByteStream object in the onGetResult callback function but I don't know how to get the correct offset information from it.

I've found a number of different methods seemingly concerning different aspects of number of bytes in ByteStream.h (length, fullSize, transmitted, payloadSize and serializationLength) but I just can't get it working properly.

Basically I would like to do something like this in onGetResult:

if (resultCode == whiteboard::HTTP_CODE_CONTINUE) {
    const whiteboard::ByteStream &byteStream = rResultData.convertTo<const whiteboard::ByteStream &>();

    currentEntryOffset += byteStream.length();

    asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(), AsyncRequestOptions::Empty, currentEntryIdToFetch, currentEntryOffset);
    return;
}
sisyphus
  • 1
  • 2

1 Answers1

0

The basic idea is to do the same call again. So if you do:

asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(),AsyncRequestOptions::Empty, currentEntryIdToFetch);

and get the response HTTP_CONTINUE, do:

asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(),AsyncRequestOptions::Empty, currentEntryIdToFetch);

Until you get HTTP_CONTINUE or an error.

If the result code is HTTP_CONTINUE, you must GET again with the parameter StartAfterId set to the Id of the last entry you received and you'll get the next entries.

Might be a bit cryptic but do another asyncGet to the exact same resource until you get HTTP_OK or an http error code.

Also, note that you need to decode the data, a python script can be found here in this answer

Morten
  • 112
  • 2
  • 8
  • Definitely cryptic but since that's the way it's done in the mobile lib I had in fact already tried this. I tried it again now but the result is still basically the same as with my other attempts, the module on the sensor crashes. I think it's due to stack overflow 'cause when I slow down the execution using a timer it seems like it's stuck in an endless cycle. It does occasionally receive HTTP_OK but then continues receiving HTTP_CONTINUE and so on. Assuming your answer is correct I guess I'm not handling the flow of asyncGet calls correctly. Have you managed to get something similar working? – sisyphus May 02 '19 at 09:05
  • I had it working but migrated away from this solution since I did not need the encoded data on the sensor. I opted for the decoded data on the mobile device instead. Did you increase "currentEntryIdToFetch" when you got the HTTP_CODE_OK? if not you will receive the same data again and again. If this is the case you will again receive HTTP_CODE_CONTINUE until the entry is completely read. – Morten May 07 '19 at 11:23