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
DASH2 PRO = 0x21
DASH4PRO = 0x7
DL1 SPORT = 0x8
ANALOG8 = 0x9
Power Pack 6 = 0xA
THERMO12 = 0xB
ANALOG16 = 0xC
RTLive = 0xD
GPS2 = 0xE
VIDEO4HD = 0xF

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 initialize 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

 

For message type #0 “request read bytes”
Data 6 -Flash Address LSB
Data 7 -Flash Address
Data 8 -Flash Address
Data 9 -Flash Address MSB
Data 10 -Number of bytes requested (1 byte)

 

For message type #1 or #2 “request write bytes” or “read/write response”
Data 6 -Flash Address LSB
Data 7 -Flash Address
Data 8 -Flash Address
Data 9 -Flash Address MSB
Data 10 onward - Message Data Bytes ( Max 64 bytes)
Note that the number of bytes that are included can be calculated from the message length. In the case of a request to write bytes, then the data is the data to be written to the unit. In the case of a read response, then the data is the data read back from the unit’s memory, in the case that the memory is inaccessible, then no bytes should be returned in the payload.

 

For message type #3 “initialize write sequence”

Reconfiguration Initialization sequences:

DL1 SD 0x2,0x15,0x86,0x77,0x21,0xFF
DASH2 0x9E 0x01 0x24 0xF5 0xCC 0x11
DASH3 0xA4,0x35,0x24,0x13,0x42,0x8E
VIDEO4  
DL2  
SPEEDBOX 0xDD,0xB0,0x0B,0xBA,0xBE,0x69
DASH2 PRO 0x2,0x15,0x86,0x77,0x21,0xFF
DASH4PRO 0x13 0x26 0x78 0xAE 0xBC 0x64
DL1 SPORT 0x5A 0x9A 0x10 0xDD 0x4A 0xDE
ANALOG8 0x2, 0x6, 0x9, 0x97, 0x27, 0xCF
Power Pack 6 0xF1,0x74,0x78,0x90,0xD1,0x11
GPS2 0x88 0x64 0x21 0x12 0x46 0x88
THERMO12 0xA2, 0x15, 0x25, 0x10, 0x68, 0x42
ANALOG16 0x72, 0xD7, 0x85, 0x24, 0x96, 0x52
VIDEO4HD 0xCB, 0x88, 0x79, 0x14, 0x41, 0x72


Reflashing initialization sequences:

DL1 0xFF,0x21,0x77,0x86,0x15,0x2
DASH2 0x4F,0xB5,0xC9,0x71,0x69,0xB2
DASH3 0x8E,0x42,0x13,0x24,0x35,0xA4
DASH4PRO 0x64,0xBC,0xAE,0x78,0x26,0x13
SPEEDBOX 0xBA, 0xDA, 0x55, 0xBA, 0xBE, 0x69
DASH2 PRO 0xFF,0x21,0x77,0x86,0x15,0x2
GPS2 0xCA, 0x86, 0x42, 0x13, 0x57, 0x9B
THERMO12 0xB5, 0x81, 0x15, 0x58, 0x26, 0x16
ANALOG16 0xA6, 0x75, 0x45, 0xB3, 0x36, 0x16
VIDEO4HD 0xCB, 0x88, 0x79, 0x14, 0x43, 0x74

This is a random sequence of bytes that tell the system to prepare itself to be configured, this is in case the target system needs to prepare itself for a reflash and also as a security measure to ensure that the system is being intentionally written to.


Disk access initialization sequences
(this applies only for devices with inbuilt disk)
Data 6-11 = 0x02, 0x15, 0x86, 0x98, 0x42, 0xFE

For message type #4 “acknowledge initialize write”
Data6 = acknowledge status
Okay = 1
General failure = 2
(more failure types might be added in the future)

For message type #5 “end write sequence”
Data 6-11 = 0x45, 0x65, 0x12, 0x11, 0x81, 0xAA
This random sequence of bytes tells the system to transfer the data from it’s buffer (if any) and move them to the final location if required. Typically this will mean that the bytes are moved from RAM to FLASH.

If the message is received with no data bytes then it is an End Read message.

 

For message type #6 “acknowledge end write”
Data6 = acknowledge status
Okay = 1
Unable to write to flash = 2
Error in flash validation = 3

 

For message type #8 “reset device”
This message is used to forcefully reset the target device.
No reply to this message.

 

For message type #9 “acknowledge read fail”
Data6 = acknowledge status

Device not yet calibrated = 4
Invalid flash address = 5
No valid configuration = 6
No common user configuration found = 7
Different user active in device = 10
 

For message type #10 “request analogue data”
This message is used to request analogue data for calibration.

Data6 = analogue channel id
 

For message type #10 “acknowledge analogue data”

Data6, 7 = analogue data
 

For message type #11 “request accelerometer data”
This message is used to request accelerometer data for calibration.


For message type #11 “acknowledge accelerometer data”

Data6, 7 = longitude acceleration
Data8, 9 = latitude acceleration
Data10, 11 = vertical acceleration
 

For message type #12 “request gyroscope data”
Data6 = request type

Offset = 0
Gain = 1
Temp = 2
 

For message type #12 “acknowledge gyroscope data”

Data6 - 9 = data
 

For message type #13 “request gyroscope disconnect”
This message is used to disconnect gyroscope for calibration purposes

 

For message type #14 “request to run board test”
This message forces the device to restart the unit and run board test programme.
No reply to this message.

 

For message type #16 “end of reflashing”
This finalises reflashing of the device.
No reply to this message.

 

For message type #17 “acknowledge write fail”
->Data6 = acknowledge status

General failure = 2
Invalid flash address = 5
Different user active in device = 10


For message type #18 “request active user”
This message is used to call active user from the device.

 

For message type #19 “request to change user”
This message is used to change the current user of the device.

Data6 = user id from 0 to 8
 

For message type #20 “acknowledge user messages”

If request is #18
Data6 = current user id (from 0 to 8)
If request is #19
Data6 = acknowledge status
No valid configuration for this user = 6
Same user found = 8
User changed = 9
 

For message type #21 “flash sector read”
Data 6 –Drive number
Data 7 -Flash Sector LSB
Data 8 -Flash Sector
Data 9 -Flash Sector
Data 10 -Flash Sector MSB
Data 11 -Number of sectors requested (1 byte)

 

For message type #22 “flash sector write”
Data 6 –Drive number
Data 7 -Flash Sector LSB
Data 8 -Flash Sector
Data 9 -Flash Sector
Data 10 -Flash Sector MSB
Data 11 –Offset in sector (this is 0,1,2,3) for which 128 byte section of the sector is being written)
Data 12-139 - 128 bytes of sector data
Data 140-141 - two byte data only checksum

 

For message type #23 “flash sector read reply”
Data 6 –Drive number
Data 7 -Flash Sector LSB
Data 8 -Flash Sector
Data 9 -Flash Sector
Data 10 -Flash Sector MSB
Data 11 –Offset in sector (this is 0,1,2,3) for which 128 byte section of the sector is being written)
Data 12-139 - 128 bytes of sector data
Data 140-141 - two byte data only checksum

 

For message type #24 “flash sector write reply”
Data 6 –Drive number
Data 7 -Flash Sector LSB
Data 8 -Flash Sector
Data 9 -Flash Sector
Data 10 -Flash Sector MSB
Data 11 –Offset in sector
Data 12 – acknowledge status
-->Okay = 1

Unable to write to flash = 2
Error in flash validation = 3
 

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 August 15, 2017, at 04:48 PM