MicroHacker Forum

I have been reading the logic behind the code released for the reverse camera line adapter and trying to use it to learn CANBUS manipulation.

A couple of things have me a bit stumped though!

First - the reading of CANBUS data into arrays. because of the way the data is read in byte D0 is actually stored in array location 7 etc - which caused me confusion when i wrote the ignition sense code because D3 was stored in array location 5! is there a way to make it more logical or just adjust my thinking lol

Secondly - and more confusing - is the logic behind the wheel angles and storage in bytes D1 & D0

The description mentions that the angle is stored to one decimal place and the signing is stored in the MSB of D1 - understood. but it also says that the angle can be obtained by dividing the angle value by 10 - but this gives me unexpected results!

If we work on the conversion from HS > MS as a constant:

Clockwise full lock = 0xAC20 (Dec 44,064). subtract 0x8000 > 2C20 (Dec 11,296) > /10 = 112.96'
C/Clockwise full lock = 0xAC20 (Dec 44,064) > /10 = 440.64'

Clearly I am wrong somewhere here! Can anyone make sense of this for me? I think the problem is my lack of understanding of manipulation of the data bytes

finally, the way the steering angle is being determined - shifting the registers. is there a reason it is done like this instead of a simple if statement?

Let's see if i can help you understand.
The "array" we are talking about is the internal representation of the received CAN payload (data only).
As you know the "Standard CAN Message" can have 1 to 8 Bytes of payload. If you send a message having DLC (data length) of 3 bytes and data is for example "0x11 0x22 0x33" (this is only a textual representation of the binary byte values), the receiver needs to store those bytes somewhere to process it. In our case, the Arduino receives the bytes from the MCPs internal buffer.

In C an array is nothing more than a list of variables of the same type. So instead of having 8 variables defined like this: and assign each byte received to one of those variables, you can simply say: Now, to access a single byte (an "unsigned char" IS a byte) you use an index. This index is zero-based, so it starts counting from 0. So to get the FIRST value stored in the array, you do and to get the LAST (8th) byte: Got it? Yes, you dimension the array to 8 memory locations, but the first location is number 0 and therefore the last one is 7.

Now, we need a way to name the order of bytes in a CAN message payload.
The "natural" order is the one you know from files. Regardless of how large they are, all beginn with the first byte. If you imagine a file as an array, the first byte is on index 0, the next byte on 1, and so forth. So if you receive CAN data, just do the same. The first, leftmost, byte is index 0. Now, i thought it was a good plan to not name it "1. byte" or "byte[0]" or "0", but call it "D0" (D for "data") upwards. So the natural order is
D0 D1 D2 D3 D4 D5 D6 D7
If you add some bytes in this order, e.g.
0x30 0x02 x0A 0x55 0xAC 0x00 0x10, 0xBF
and the byte with the value 0x55 is the one of interest, i would call it D3. If you number the bytes from right to left, it would be D4.

bigi wrote: ↑26 Apr 2019, 08:37 Secondly - and more confusing - is the logic behind the wheel angles and storage in bytes D1 & D0

In D0+D1 on HS-CAN ID 0x076 is only the angle from 0x8000 (unturned) up to 0xAC** (full turn). The direction is given by Byte D7 in the same message. Is the value smaller than 0x40 you turn clockwise, otherwise counter clockwise.
The reason a bitshift is used in code is just that it can be done this way also, but i would agree that it might be easier to read with and IF/ELSE condition.

thanks for the explainations @Go4IT - makes sense. what I still cannot work out is the angle information - it mentions /10 on D0+D1 gives the angle - but i don't seem to get that? angle should be at going upto approx 440' on each lock?

I know irt's not important but I really want to understand the logic - i'm pedantic at times

sorry to bump an old thread

I've been running this code in my arduino box for quite a while now and it largely works fine - but i find that randomly when i get in the car and engage revers, the arduino seems to have frozen and i need to reset the board and it starts working again. I thought it might have been because it was left connected to the OBD perm power, but it's now connected to the accessories live which powers off after 15 mins or so. This has largely cured the problem - but if i stop and go somewhere for 5-10 mins and get back ion the care it randomly still does it.

I can't see any reason why it would crash - especially as I have a CM gateway attached as well and this doesn't experience such problems. both are using the same suppliers nano and CAN shields, and both using decent shunt regulators (not eh cheap fixed voltage ones).

Anyone any suggestions?

Add a LED to arduino and in the same code where you read and decode CAN data add a function to make this LED blink.
This way at least you will have an idea if it's a CAN problem (LED still blinks) or a hardware problem (LED on of off).