Packet size issues (MetaMotionRL)
One of the header files (MetaWear-SDK-Cpp/src/metawear/core/cpp/constant.h) states that the maximum size of the attribute value (ATT payload) is 20 bytes.
When creating a packer processor, the code checks that the amount of packed data does not exceed the maximum allowed size. However, when using the fuser processor, the code does not perform that check.
In fact, when you fuse 2+ values (eg 3), the beginning of the ATT value sent by the board correctly sates that 3 values are being fused (0x090303, that last "03" means that 3 signals are being fused), however, only 8 FP16 numbers are correctly (completely) returned, instead of 9.
When inspecting the data, you see that the last byte was either smashed, or not written. The following ATT data was captured when using a fuser to fuse 3 times the same signal:
0903 03 a9 0061 01f3 0fa9 0061 01f3 0fa9 0061 01f3
- That packet sates that a 3 value array is sent: 0903 03
- The 3 value signal is: 0fa9 0061 01f3
- The last value is incomplete: a9 (he first a9 may overlap with the first 03).
- That payload is 20 bytes long, as stated by BLE_PACKET_SIZE (constant.h)
For the MMS board, you state that data is sent in "pages that are 512 entries large", so I guess that you have already implemented firmware for the nRF52840 SoC that can send ATT payloads larger than 20 bytes.
Why wouldn't you enable ATT payloads larger than 20 bytes for the MMRL?
Or better yet, why don't you open source your firmware?
Thanks!
Comments
Clarifications:
@stbnps
All MetaWear radio communications work with maximum 20 byte payloads including the MMS and MMRL. Historically, this has the most consistent performance and compatibility across all client platforms. Any comments about 512 entries on the MMS are related to the data logger and the NAND Flash memory.
It looks like we missed the bounds check on the fuser processor as you have noted.
The third byte is actually the processor id or index used to identify the particular processor instance. It is just a coincidence in this case that it ended up as number three.
The three header bytes "090303" are part of the payload, which leaves only 17bytes for data. 9 16-bit integers would unfortunately require 18 bytes, which is why your data is being truncated.
Just to clarify.
Even if you state that "When data is retrieved, it is retrieved in page sized chunks", you are not referring to the actual bluetooth comunication itself?
By using page sized chunks for retrieving data, I would understand that you are actually retrieving page sized ATT payloads. That sentence in the docs may lead to confusion!
hey @stbnps,
I will clear that up in the tutorials. Sorry for the confusion.