search

NordicPlayground / nRF51-ble-bcast-mesh

Other
323 stars 121 forks source link

Multi-part messages #139

Open mrquincle opened 7 years ago

mrquincle commented 7 years ago

We use the mesh to send multi-part messages. This requires a few adaptations. Shall we issue a pull request?

trond-snekvik commented 7 years ago

That sounds very interesting :smiley:

What's the nature of the adaptations, do they change core behavior, or add to it?

We'd be happy to take the PR :)

mrquincle commented 7 years ago

It doesn't change core behavior and only extends it.

eggerdo commented 7 years ago

Great to hear about the interest :) Just to be sure we are talking about the same thing, the multi part messages we introduced are over the BLE Gatt notifications, not the mesh itself. We use the normal packets with increased packets size over the mesh, but in order to get all the data synced to a phone we needed to change the Gatt notifications, which were limited to 16 bytes of data. The same framework could of course also be adapted to messages over mesh, but we haven't done that.

We have all the code committed in a branch here, if you are interested to preview it. It's based on the Nrf52 & SDK 11 PR which is still open, so I thought of waiting with creating a new PR, but there is otherwise nothing keeping it.

In short the modifications are:

  1. Made package size configurable through defines
  2. Introduced additional mesh_gatt_evt_opcode_t for multi part notification messages
  3. Added buffer to store messages to send as notifications, together with offset of how much has been sent already
  4. Adjusted mesh_gatt_value_set to use multi part notification messages
thedjnK commented 7 years ago

@eggerdo Just a note on your code: you should call nb_clear() during the GATT init function too otherwise the buffer isn't correctly initialized and the latest message received by the node isn't displayed until another message comes in, then another message needs to come in to get that message out over BLE.

eggerdo commented 7 years ago

Thanks that is indeed a good thing to do. We have used it for the time being for lossy channels where data is streamed to a phone. Thus haven't noticed that the first message could be lost. Thanks again!

On Sat, Feb 11, 2017 at 3:15 PM, thedjnK notifications@github.com wrote:

@eggerdo https://github.com/eggerdo Just a note on your code: you should call nb_clear() during the GATT init function too otherwise the buffer isn't correctly initialized and the latest message received by the node isn't displayed until another message comes in, then another message needs to come in to get that message out over BLE.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NordicSemiconductor/nRF51-ble-bcast-mesh/issues/139#issuecomment-279146375, or mute the thread https://github.com/notifications/unsubscribe-auth/ACD7szxQzd-6V3npgJNr-Ft7T3xWoPxcks5rbcKJgaJpZM4Kb2zT .