Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

Synchronization protocol & frame structure

Jump to bottom
Ivan edited this page Dec 25, 2018 · 1 revision

Synchronization protocol

The synchronization protocol is a token style protocol. Only who own the token can write on the medium, while all the devices can read at the same time without generating collisions. The token is initially owned by the master (hardcoded to the device with serial address 0) and the master is the entity who send the token to the slaves.

The first action the master take, is to send the token to the first available device. This device is now the owner of the token and can send up to N messages, then send back the token. The master, who is now again the owner of the token, sends it to the next slave available, repeating this behavior until every available slave is polled at least once. When the last available slave is polled, the maser restart the send token cycle from the first available slave.

This game can be better understood with this image (assuming slaves 1,...,n are available):

rs485_sync_protocol_diagram.png

Error handling

The protocol can handle 2 typer of errors:

  • Token lost: If the token goes lost, all the protocol hang up because noone have the token and all the devices are waiting for it. To avoid this, the master board have a 'token return timeout'. When the maser send a token a timeout is started. If the board owning the token stop working, the token won't get sent back and the timeout will trigger the generation of a new token.
  • Message corruption: If a message get corrupted, a crc8 control byte sent with the message will make the receiver to detect the corruption. A corrupted message will be discarded by the receiver. NOTE: there are no messages ACK on NACK, so a lost message is not retransmitted! Message corruption can affect even token messages, but this case is solved using the 'token return timeout'.

This image show how the system handle lost tokens:

rs485_sync_protocol_diagram_error_case.png

Serial frame specification

payload.png

Field descriptions:

  • Destination address: the destination address of the device who will receive the message. Valid values are 0-254
  • Source address: the source address of the device who generate the message. Valid values are 0-254
  • Type: the type of the message. Current valid values are: 0 (MessageStandard), 1 (MessageToken), 2(UnknownType). Other values for this field can be applied in the future.
  • Payload: 14 bytes for effective message payload.
  • Byte fix 1 and 2: supplementary bits to fix eventual values of 255 in the payload. See Fix bytes
  • CRC8: one byte for crc8 control check
  • Message terminator: a byte for message termination and emergency resync. His value is 255.

Fix bytes

The value 255 cannot be used in message bytes since is used as message terminator. But also, the user does not have to take care of what bytes are put in the payload. The fix bytes come here to silently avoid the 255 value in the payload.

It work by moving the less meaningful bit of each payload byte into a new location, and replacing the original one with 0. The new location is an appropriate bit of these fix bytes.

Example: Let's assume we create a new message. We want to insert in the payload the values(bytes) 255, 255, 255. Fix bytes are set to 0 by default.

We have (in term of bits)

Payload byte 1: 11111111

Payload byte 2: 11111111

Payload byte 3: 11111111

Fix byte 1: 00000000

Fix byte 2: 00000000

We can't insert these values in the payload, so we move the least meaningful bit for each byte in the fix bytes:

Payload byte 1: 11111110

Payload byte 2: 11111110

Payload byte 3: 11111110

Fix byte 1: 00000111

Fix byte 2: 00000000

With this trick we now have valid bytes to be inserted in the payload.

The receiver will take care of restore the original position of the moved bit, recomposing the original message.

Clone this wiki locally