Repository navigation
BLE publishes: no lost packets, no per-packet copy, a byte limit on the queue - #12
Merged
Merged
Conversation
…byte limit - A null buffer from ble_hs_mbuf_from_flat() (NimBLE's pool used up, which notifications sent faster than the link takes them do) was passed on: NimBLE takes a null buffer to mean "send the characteristic's value", which is empty, and reports success, so the packet was lost from the message and its HDLC CRC failed at the central. It is now sent again later, and counted (txNoBuf in the stats). This was the loss seen with notifications of messages of 4 KB or more. - Each packet sent copied the whole message out of the queue (and held the queue locked meanwhile) - over 1.5 MB of copying for a 28 KB camera frame, and loops of 10-15 ms. The packet is now copied out with peekWith, and messages are moved into the queue rather than copied again. - The publish queue also has a byte limit (pubQMaxBytes, default 32 KB): limited only by count, large messages piled up for many seconds of link time. - The position in the message being sent is 32 bits (16 bits broke messages of 64 KB or more). - Publishes refused while the queue is full are counted once each time it fills, and the warning is limited to one a second (a publisher asks again each loop, which logged hundreds of lines a second). Needs RaftCore's const ProtocolRawMsg::getBuf()/getBufLen(). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A message whose buffer may be taken (RaftCore's CommsChannelMsg::isBufTakeable(), set on a RICREST message just encoded for sending) is queued without copying - one less copy of each camera frame published. Other messages are copied as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Live camera frames over BLE never arrived in the dashboard ("Waiting for frames..."), and the main loop was held for 30-40 ms while frames were published.
Changes
ble_hs_mbuf_from_flat()returned null and that was passed toble_gatts_notify_custom(). NimBLE takes a null buffer to mean "send the characteristic's value" (empty here) and reports success, so the packet was silently lost and the message failed its HDLC CRC at the central. It is now sent again later and counted (txNoBufin the BLEMan stats). This is the cause of the earlier finding that notifications of 4 KB or more lost a packet.peekWith, and messages are moved into the queue. A message just encoded for sending (RaftCore'sisBufTakeable()) has its buffer taken rather than copied.pubQMaxBytes(default 32768). One message may go over it, so a larger message is still sent when the queue is empty.pubDrpOp) is now counted once each time the queue fills, and the warning ("PUBLISH QUEUE FULL") is limited to one a second, with the number of refusals.Depends on robdobsn/RaftCore#31 (const
ProtocolRawMsg::getBuf()/getBufLen(),takeBuffer()andCommsChannelMsg::isBufTakeable()).Tested
Plant growth board (ESP32-S3, OV2640), raftjs dashboard live view over BLE from Windows:
txNoBufcounted 30-75 a second: each of those packets would have been lost before.🤖 Generated with Claude Code