Call me back | My basket | Checkout | Add to email list

     You are here: Website » Knowledge base

« back to website

DataAndConfigurationMessages / 108GeneralConfiguration

General Configuration and Reflash message #108


Data 0 - Header Byte for DL1 Reflash (108 0x6C)
Data 1 - Channel length
Data 2 - Hardware type

All hardware = 0
DL1 = 0x1
DASH2 = 0x2
DASH3 = 0x3
VIDEO4 = 0x4
DL2 = 0x5
SPEEDBOX = 0x6
DASH4PRO = 0x7
DL1 SPORT = 0x8
ANALOG8 = 0x9
Power Pack 6 = 0xA
THERMO12 = 0xB
ANALOG16 = 0xC
RTLive = 0xD (original 3G version)
GPS2 = 0xE
VIDEO4HD = 0xF
GPS2 Base = 0x10 – not used
SPEEDSENSOR10 = 0x11
GPS/GSM correction unit = 0x12 – not used
DASH5 = 0x13
RTLiveV2 = 0x14 (2022 LTE version)
GNSS2 = 0x15
Basestation = 0x16
RTK Connect = 0x17
RTSS = 0x18 (embedded LTE board)
RTSS Lite = 0x19
EMCC=0x1A
RT COMMS BACKUP=0x1B
TM RECEIVER=0x1C
SPEED100=0x1D
DASH2 PRO = 0x21
DASH4PRO FD=0x22
DL1 EVO=0x23

For hardware type #0: This is a special case which is used to get a list of all hardware in the system.

Reflash/Reconfiguration procedure starts when Master sends a special message called Hardware zero message to the bus. This Hardware zero message contains Master’s Hardware ID and Serial Number.

Format of Master’s Hardware zero message.

Msg[0] = Hardware ID (108)
Msg[1] = Length (4)
Msg[2] = 0 ( Represent the Hardware Zero message)
Msg[3] = Master Hardware ID
Msg[4] = Master Serial Number LSB
Msg[5] = Master Serial Number MSB
Msg[6] = Checksum

(For the PC, Hardware ID = 200, Serial Number = 6789)

When this message is received the device checks to see if it already contains its own device type and serial number. If it doesn’t:

  • it adds on it’s own device type and serial number, updates the message length and recalculates it’s checksum then retransmits it. There can be a maximum of 16 devices inter-connected on a loop.
  • if it is already included then the message is discarded

The message will be built up in the format:

Header length 0 hardware1 serial LSB 1 serial MSB 1 hardware2 serial LSB 2 serial MSB 2 hardware3 serial LSB 3 serial MSB 3 ........ checksum

For all other hardware types:

Data 3 - Device Serial Number LSB
Data 4 - Device Serial Number MSB
The serial number is calculated using (data4) x 256 + (data3)

When any hardware sees a “general configuration message type 108”, then it decodes it and checks the hardware type against itself, and then the serial number against itself. If both match then it uses the information and makes a suitable response. In the case the device and/or serial number do not match then the serial message is re-transmitted.

Wait command

Message 0 with no content is treated as a Wait command on reception. This is sent by any unit which receives a Message 0 but has other ports which need time to be queried. An example would be a SPEEDBOX which receives Message 0 on Port 1. It will reply with the Wait command on Port 1 and then query Port 2 before sending the result back on Port 1.

Any unit which sees a Wait message should forward it on the same serial port.
When a unit which has sound out a request for IDs gets back a Wait command it should extend the discovery timeout for 2.5s.
Note that serial message “0” is a special case and should match any serial number.

 

Data 5 – message type
request read bytes = 0
request write bytes = 1
read/write response= 2
initialize write sequence = 3
acknowledge initial write = 4
end write sequence / end read = 5
acknowledge end write = 6
not used = 7
reset device = 8
acknowledge read fail = 9
request & acknowledge analogue data = 10
request & acknowledge accelerometer data = 11
request & acknowledge gyroscope data = 12
request gyroscope disconnect = 13
request to run board test = 14
internal use = 15
end of reflashing = 16
acknowledge write fail = 17
request active user = 18
request to change user = 19
acknowledge user messages = 20
flash sector read = 21
flash sector write = 22
flash sector read reply = 23
flash sector write reply = 24

 

Typical read procedure (not sectors):

  • Reads can happen at any time, so just
  • Request read bytes (#0), and unit should respond with the bytes that are read (#2)
 

Typical write procedure (not sectors):

  • We send a message to initialize writes (#3)
  • System acknowledges as okay (#4)
  • We send writes message (#1)
  • System responds and these are checked against the request (#2)

(the above 2 are repeated as required)

  • When complete, or a buffer flush is required, complete the write sequence (#5)
  • Wait for acknowledge (#6)

Typical read procedure (sectors):

  • Reads can happen at any time, so just
  • Request read bytes (#21)
  • Unit replies with message #23, four messages per sector, for as many sectors as are requested

Typical write procedure (sectors):

  • We send a message to initialize writes (#3)
  • System acknowledges as okay (#4)
  • We send write message (#22) for ‘offset in sector’ 0
  • System responds with ‘offset in sector’ 0 acknowledge (#24)
  • Repeat write message and acknowledge for ‘offset in sector’ 1,2,3
(the above 2 are repeated as required)

The receiving system will store internally the data which makes up a complete sector.

After each section for offset 0,1,2 is received and the checksum is checked it will send an acknowledge

The acknowledge for offset in sector 3 is only sent after the data has been written to the memory card and checked.

When writing all the sectors has been finished, a write sequence message should be sent (#5). This won’t actually write anything to the card, but it will take the unit out of the writing mode.

When the unit is in the writing mode other functions on the unit will not work, such as serial ports, CAN, data logging, etc. This is to reduce the chances of problems with multiple access to the memory card.

Page last modified on July 29, 2024, at 11:59 AM