end of lap telemetry

[ElsmoortelG]

In the race series where we are competing we can not have telemetry. It is forbidden to watch the cars data continuously. So end of lap is not continuously and is a gap in the reglementation.
But for that we need a radio modem and that is also not allowed.
Currently we a system which gives us a warning when the car is within 300 meter reach of our pit box/wall. So we know when we have to show the time panel etc...
It is an RF-signal (like a remote control). We want to try adding data to that signal and therfore we are going to rebuild this unit with a can-interface. With the purpose to use the data from the ADL2 and ECU and sent it to the pitwall.
So I need to knows the data-structure of the different channels the ADL2 and M600 uses.
My personal knowledge of the CAN-bus protocol is for the moment very basic but I am prepared to study.
Somebody can provide me some material which can help ?
Or is there even a more simple solution with existing material which I have no knowledge of ?

[ChrisN]

Hi ElsmoortelG,

MoTeC do not encourage the breaking of regulations, so it is up to you decide what is legal or not in your race series. It would depend on the wording of the regulations though - if "telemetry" is forbidden, then this would prohibit any kind of wireless data transmission from the car to the pits, regardless of any comments about continuously monitoring data.

In order to receive data on the pitwall in Telemetry Monitor, you would need to send the data from the ADL2 RS232 output, and receive into the serial port of the pitwall computer.

You can send data from your ADL2 to a third-party CAN device, so could set up a Transmit Message CAN template in the Dash Manager software to send a combination of ECU and ADL2 channels. This would allow you to select the channels you wished to send, and then only send them on a few message IDs, or combine them into compound messaging format sending on only one CAN ID if the receiving device can accept this. For more information on the CAN settings in the ADL2, please see Tech Note TNAU0031 attached.

[ElsmoortelG]

There is something not clear to me in the document.

Data frame of CAN 2.0A
Start of frame : 1bit
Arbitration field : 12 bits (Identifier : 11 bits and RTR bit : 1 bit)
Control Field :6 bits (Data length : 4 bits and reserve : 2 bits)
Data Field : 0 to 8 bytes
CRC Field : calculated
ACK Field : 2 bits
End of Frame : 7 bits

What I understood is that the base adress refers to the identifier and holds the name of the module which sends the data. 1 base adress can contain 8 bytes of data. except compound messages.
A channel takes 2 bytes. So I would think an M600 can send 4 channels.

But if I look into the configuration of our own system. Then I have message type single with 24 channels selected to be sent and if I take the last channel this has an offset of 48.

So with this I understand that the data-frame should be 48 bytes ?
And what is also not in line is that the data lenght field can normally communicate 16 as max value.

Would you be so nice to explain this a bit more in detail ?

[ChrisN]

Yes, in a standard CAN message there is a message identifier and then 8 bytes of data, so from a MoTeC device working with 16-bit channels this allows us to send 4 channels per identifier. However there are a couple of different ways of sending the data to allow more information to be sent on one identifier.

We can also send compound messages, where the first data byte is the compound identifier which is an incrementing counter, so we then have 7 data bytes for each value of the counter, and hence can fit 3 channels into each compound identifier.

The method used to send the default datastreams from our M400/600/800 ECUs is known as CRC32 format, which is not that common, but effectively mimics an RS232 datastream format featuring a checksum, and allows us to send a large number of channels on a single identifier.

I hope that helps

[ElsmoortelG]

Thanks Chris, it is clear now.