NRF Mesh Serial Protocol - adding some robustness

[emh203]

I am prototyping a mesh network with the PCA10056 (52840 DK).     I have one node programmed with the serial_nrf52830_xxAA project (from the Mesh 2.1.1 SDK) that implements a serial interface into a the mesh network.    I have things generally working but noticed that the protocol to send/recieve serial packets could benefit from some additional robustness.    Based upon the source code and the documentation here:

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v2.0.1%2Findex.html

I noticed that there is no framing / synchronization bytes to mark the start of a packet.     It is very easy to "break" the interactive python shell or the the firmware with unexpected bytes.    Once the embedded serial application or the host software lose synchronization,  it is nearly impossible to gracefully recover as each packet starts with a length and opcode.   

I will be modifying the serial example to include a simple synchronization pattern (i.e. 4 known bytes such as 0xDEADBEEF) so the decoders on either end can synchronize if there is an error.    I have 2 questions:

1.)  I studied the serial_nrf52830_xxAA project and found several places where I could modifiy the packet format to include a synchronization header.        I want to make sure that I am not introducing any potential problems in the core mesh stack.   

a.)  It looks like I can insert some bytes at the beginning of a packet by modifiying the "do_transmit()" function in serial_bearer.c

b.)   On the receive side, I could modify the the char_rx_simple function to strip off the synchronization header

2.)  I believe there are other tools for DFU, etc that use the serial firmware interface.   If I modify the code, I would also need to modify the tools.    I see there are macros for "SERIAL_SLIP_ENCODING".       Is this supported by nrf_util?

I trying to add a bit more robustness to the protocol and do not want to add any issues into the mesh stack.    Are there any other options that I may not have considered?

 

[tesc]

Hi,

I am afraid that for both questions I need to consult our Mesh team in order to provide proper answers. Unfortunately they are quite busy these days, but I expect them to be available next week and I will get back to you then. For now, here are my initial remarks:

1) I think your suggestions sounds reasonable, but I must check with our Mesh team to be sure. I think they might have some suggestions or alternative options as well. In any case there should be no issues with the stack itself, as this is only how the commands are framed over serial. The only thing to look out for would be added overhead (i.e. latency and throughput considerations.)

2) Yes, other tools using the serial interface might have to be updated. For instance DFU uses the same serial packet format.

Regards,
Terje

[emh203]

Ok, thanks for the reply.   I will look more into the SLIP functionality as well.

[emh203]

Just an update.   I did compile the serial example in the SDK with "SERIAL_SLIP_ENCODING" as well as updated the python example code.  It seems to be working much more reliably.   I will be looking at the DFU utilities, etc to get them updated as well.

[tesc]

Hi,

Thanks for the updates. It seems you are well on your way on your own and nothing is better than that!

I have not used SLIP before, but we are using it for serial DFU in the base nRF5 SDK which means we do have a SLIP library and so it sounds like a good choice to me.

Regards,
Terje

[tesc]

Hi,

Another update.

I got a recommendation from the Mesh team, that you should use SLIP. So it seems you are on the right track!

Regards,
Terje