I'm using (right now) an Argon running OS4.2.0. I'm using it in the BLE Central Role and have connected to a peripheral. I'm polling it for data. The peripheral reports it will send 297 bytes of data via the UUID characteristic. This of course causes packet fragmentation.
I then read the peripheral for data. I get 244 bytes on the first read and by review I see the data is intact. I get 52 bytes on the second read which is 1 byte short of 297. By review, it loses the first byte of the second message. I have verified that using Linux box to effect the same BLE coms.
Sorry for confusion. No, these aren't related. This one is real. I have verified it on several OS versions (including 5.6.0, 4.2.0, 4.0.1 and 4.0.2). It drops the first byte on the second packet. Easy to reproduce.
I read through your code and while I don't directly see problem, I do see that you are doing a lot of String operations with substrings based on the found indices of various characters. so my question is:
Can you reproduce this without all the String work and just dump the raw data to a log? Maybe even just dump it in hex if you have to. That would make it a lot easier to figure out what in the BLE layers is going wrong.
Thanks for looking at this. I get what you’re saying - potential memory leaks. The code I placed on GitHub was made much after I found the this issue. I spent time first just getting the BLE exchanges going and that’s when I discovered a byte was being dropped. Fortunately the byte doesn’t contain relevant data for me so I just powered on coding.
The first Log message of 4 bytes long says (for example) that 259 bytes are coming (this is the Shelly device sending that info) and then in the next read Log displays 258 bytes received.
I compare the rx’ed message byte for byte with a PC running a python program and there is a byte missing and it’s the 245th one in the message (ie first byte of the second packet/fragment).
