Notify packet size/timeout #8
-
|
I'm trying my hand at directly talking to a BLE device. This is a battery BMS (JK), and I think I have it 'sort of' working. The thing is that when I write data, I expect a response that could be either 300 or 320 bytes in the notification. However I get multiple notifications of different lengths (128, 22, 128, 22, 20). I can create a sort of "packet assembler" looking for the start of a packet and putting them all together (then fire my own notification event), but I have no idea if I should be waiting for 300 or 320 bytes. Am I missing something? It would be nice if there was a "start notification" and "end notification" indicator in the event args. At the very least an "end notification" could be sent if no new data was to be sent after a timeout. Roy |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
I ended up just appending all bytes received from the notification to a buffer and then writing a packet assembler to look for the packet header .. then decoding form there to determine how many bytes I needed. Once I found the right "full packet" I removed that data from the start of the buffer and fired a separate event handler withe just the full packet bytes. Took me a bit to figure out the ins-outs of the library, but now that I have, I have a working system that reads/writes data to the device. Working around everything being "async" with out a way to pass a cancellationToken is a pain, but for the long running things I've got a pattern working. That is until DBus or BlueZ locks up. |
Beta Was this translation helpful? Give feedback.
-
|
@RoySalisbury I'm happy to hear you were able to get around the issue. I know what you mean about DBus locking up. Though rare, I too have run into this scenario. In my case, it was DBus itself, where the Linux Distro being used had an older version of DBus installed. |
Beta Was this translation helpful? Give feedback.
-
|
I ended up running it as a system service and using the linux watchdog functionality to kill and restart the process if the device notifier stops receiving data. Not a perfect solution, but its all I have found so far. |
Beta Was this translation helpful? Give feedback.
I ended up just appending all bytes received from the notification to a buffer and then writing a packet assembler to look for the packet header .. then decoding form there to determine how many bytes I needed. Once I found the right "full packet" I removed that data from the start of the buffer and fired a separate event handler withe just the full packet bytes.
Took me a bit to figure out the ins-outs of the library, but now that I have, I have a working system that reads/writes data to the device.
Working around everything being "async" with out a way to pass a cancellationToken is a pain, but for the long running things I've got a pattern working. That is until DBus or BlueZ locks up.