CAN map in zombie (and OI?) For newbs

[Jacobsmess]

I've never really messed with canbus and my van, being from 1993 has no idea about canbus either, however, as I progress with my conversion I'm finding the need to understand it to make thing customised, affordable and also diagnosable.

My first plan is to make a little TFT LCD gauge for use as a Speedo using a wemos mini, to do so, I need speed data from the zombie to be mapped to a canbus network so that the little campus transceiver I bought can pass the information onto the Wemos, who can then crunch numbers depending on the gear I'm in and tell me just how fast I'm going.... Or at least that's what I want to do, I've no idea how to do it. There is code for the Wemos and can mapping for the zombie to be done first.

Despite having read a few online articles, watching a few online videos and hounding BigPie far more than they probably appreciate, I'm still not entirely sure what I'm doing.

To begin with, I need the zombie to send out can data on mg2 rpm. For this, Zombie needs to give it a Can ID, a position, some bits and gain.

Any advice on the above, and why would be immeasurably useful and perhaps helpful to a host of others whom are also Can-challenged.

[Bigpie]

https://openinverter.org/wiki/CAN_communication wiki has information that's also relevant to zombie mapping.

[Jacobsmess]

https://openinverter.org/wiki/CAN_communication wiki has information that's also relevant to zombie mapping.

Yes I've read through it all, and despite it being very useful and comprehensive it is written from the perspective of someone who knows what canIDs and other things are. As I've found most online videos and articles are. I get its 11 bits, but I can't just write 11111111111, or can I? what about other functions already on the can, will I clash with other can messages?

Once I get somewhere with this I'll try and document it as a CanBusgauge for dummies writeup

[uhi22]

Perfect, you put the right questions
The first task is to find a free CAN ID. Because, as you said, clashing with existing functionalities is a bad idea. For this task you need a CAN log of your bus, or somebody who knows which IDs are used and which are free.
To create a log you can use SavvyCAN (Freeware), and a simple interface e.g. "wifican" on my GitHub.

The 11 bit IDs are often written as hexadecimal numbers in range 0x0 to 0x7FF, or decimal 0 to 2047.

[Jacobsmess]

Thanks that's useful. Does a list of standard mapping of the zombie exist? I've not changed anything and so I'd have thought everything at present is 'stock'.
This would be useful information on the wiki.
So following this, how does one formulate a CanID, are there any other rules other than just using available IDs to avoid clashes?

[Bigpie]

There is no standard list, it's entirely configurable and nothing happens by default (excluding messages for specifically selected hardware/integrations). Someone did start a table trying to standardise OI can messages https://openinverter.org/wiki/CAN_table_CAN_STD

One thing though that might be useful in your case, as the car has no existing can bus is the CAN ODB2 integration https://github.com/damienmaguire/Stm32- ... n_OBD2.cpp I think this allows the use of a bluetooth ODB2 connected to the can with the torque app.

[uhi22]

A little bit of background first:
- The CAN protocol allows two different types of CAN-IDs. They call it standard-ID, which is the 11-bit-ID, and there are extended IDs, which are 29 bit. Let's assume, the project only use standard 11 bit IDs.
- The ID is used to decide about the priority of the message. This is important for the case, that two nodes (participants on the bus) are trying to start talking at the same point in time. In other protocols this would lead to garbage data, but CAN uses a clever trick to avoid destruction. Both nodes are sending the ID bit-by-bit on the CAN, and are listening to each of the bits. If two are sending the same (because the upper bits of the ID are identical), they just continue. As soon as they sending a different bit (because the IDs are different), the sender of the dominant level wins, and continues, and the sender of the recessive level sees the collision and stops sending. So the message is not disturbed. The node which was the loser during the arbitration, just tries again as soon as the message is finished.
The rule is: The lower the CAN-ID, the higher the priority. Usually, there are some ranges for orientation:
0x0: Highest priority
0x1 to 0x200: High priority data, which needs to be fast, e.g. engine control, ESP, ABS
0x200 to 0x400: Medium priority data, e.g. light control
0x400 to 0x600: Low priority data, e.g. status messages
0x600 to 0x7FF: Lowest prio data, e.g. diagnostic tester communication (OBD), flashing over CAN, Web-interface
(This is only an example, to give orientation.)
Basically if you need data for gauges and status indication, this is typically in the range 0x400 to 0x600. The OI web interface uses decimal CAN ID (if I remember correctly), so you are good in the area of 1280 (= 0x500).

[Jacobsmess]

Thanks a lot, things are starting to make sense.
I would expect that the zombie (and OI?) Comes from Damian with some sort of default can mapping no? As in, it will have default IDs setup for its existing map. And given no other can stuff has been added this would be considered standard? But perhaps I'm wrong.....

ODB dongle sounds useful, I'll look into that.

[Jacobsmess]

So moving forward, the Zombie requires CanID, Position, Bits and Gain as well as to be told if it's transferring or receiving.
For this example, I'll be transferring.

For a Speedo gauge, say we use CANid 0x500. The position I presume is the position in the 11 or 29 bits that the information will be sent on and this will be required by the device that is receiving or listening to know what is useful and what is not.

The bits, I'm unsure of, what would this usually need to be or what guidance can you provide on this?

And finally gain, or how loud/big it is right? There doesn't seem to be any guidance on this as well.

[uhi22]

The "position" is not related to the 11 or 29 bit ID. The ID is a fix number, which you just select, like the 0x500 in your example.
After the ID (and some control information, which we can ignore in the discussion), there are the real data bits. A CAN message can hold between zero and 8 data bytes. In https://en.wikipedia.org/wiki/CAN_bus#Base_frame_format they call it "Data field". The "position" in the CAN mapping let you select, at which position of the 64 data bits (8 data bytes) your value will be located. So just assume, you have a plenty of space (64 bits), and you have two signals you want to transfer, lets say a lamp for "foreward" and a lamp for "backward". Each of this is a single bit information (the lamp can be on or off, nothing else). So we can chosse that the forewared lamp shall bit on bit 0, and the backward lamp on bit 63 (just as an example, more likely would be choose bit 0 and bit 1
The receiver needs the same information: "There is a CAN frame with ID 0x500 and on bit position 63 of this message you will find the bit which shall control the backwards lamp."
For values that are more than "on/off", both, the sender and the receiver need to be aligned about the scaling of value. Lets say, accu voltage. In can be 1 volt resolution, or in 0.1V resolution, or anything else. So you need to define, what is the intended scaling of the signal on CAN. Lets say, on CAN we want a scaling of 0.1V, and in the control unit the variable has a scaling of 1V. So the CAN mapping needs to multiply the internal value by factor 10, to have the intended scaling on CAN. Also the number of bits need to be configured, so that both, the sender and receiver are aware how many bits to write or read.
Example with a 20-bit-signal, which fills bits 0 to 19 (orange), a one-bit-signal (which is at bit 20), and empty space in bits 21 to 63.

[Edit] The CAN mapping parameters and how they work are explained here: https://openinverter.org/wiki/CAN_commu ... N_messages

[Jacobsmess]

Thanks Uhi that was really comprehensive and helpful.
So going back to my use case of wanting to send RPM data.
I choose a CANid of 1280 (or 0x500 in hexidecimal), given I need a wide range for rpm I would start the data at position 0, and if I want to devote the entire CANid to rpm only, I set the 'bits' field to 32 (16 if I want the CANid to only use half of its capacity on rpm?), and lastly gain would be set depending on my ESP8266 that is taking the CAN data and scaling it (I'm stil not 100% on how this would be setup).
Hopefully I got at least some of that right....

I pm'd you but to make this potentially helpful to someone going forward, can I use your WIFICAN https://github.com/uhi22/wifican with an ESP8266 with Wifi (as I have a spare)?

and BigPie, so I understand correctly, re: the Can_OBD2.cpp what is it exactly this achieves? I'm not sure I actually understand what you are suggesting, although I'm sure it'd be useful.

[royhen99]

RPM can easily fit in 16 bits and as the resolution is only 1 rpm it needs no scaling. This can be set on the tabs on the web interface or by typing in on the command line. This should be is all that is needed, can tx speed 1280 0 16 1. speed is the parameter name, can id 1280, 0 offset , 16 bit length, gain 1.
save to save all can maps, can clear to clear all maps and can del speed just to clear the speed can map. This is all explained in detail on the wiki page.

The ESP8266 does not have a can interface. If you just want to add a can transceiver then you need an ESP32.

[uhi22]

Yes, this is the short answer. It tells "how", and now let's explain "why".

given I need a wide range for rpm I would start the data at position 0, and if I want to devote the entire CANid to rpm only, I set the 'bits' field to 32 (16 if I want the CANid to only use half of its capacity on rpm?), and lastly gain would be set depending on my ESP8266 that is taking the CAN data and scaling it (I'm stil not 100% on how this would be setup).

You are on a good way, but still some steps to go. The "wide range for rpm" needs clarification. The questions behind is: How many bits do we need to cover all possible values of the RPM? Example: If RPM would only need four values, lets say zero, 1000RPM, 2000RPM, 3000RPM, we would need only two bits (because with two bits we are able to distinguish four values: 00, 01, 10, 11). We could define the interpretation as "physicalvalue = 1000RPM * canvalue", and we are done. But wait, just four different values for RPM is quite steppy. Yes, we do not want this. But which step size would be better? And which minimum and maximum values need to be covered?
For RPM, there is a "natural" answer: The minimum zero, the step size (resolution) 1 RPM, and the maximum, well, as you need, lets say 20000 RPM.
How many bits do we need for this? We have to cover the values 0 to 20000. Does this fit into one byte (8 bits)? No, because a byte can only transfer 256 different values (0 to 255). So a "natural" answer could be "lets take 2 bytes (16 bits), this covers the range 0 to 65535". An other answer could be, "15 bits are sufficient", this is especially helpful if many things are to be transmitted and fight for each single bit starts. In your case, if anyway only 2 of 8 data bytes in the CAN message are used, just take the 2 bytes (16 bits) as royhen99 proposed.

The RPM example is a simple case, because RPM has a nice "natural" scaling with resolution 1 and no offset. More complicated is e.g. a temperature. Let's say you want at least a resolution of 0.5K, and you want to cover negative and positive temperatures, let's say for a coolant temperature at least -30°C to +150°C. This would require a more complex scaling: We need 180K with 0.5K resolution, these are 360 different values. Which need at least 9 bits. And we need an offset of -30°C, because the numbers in the CAN messages are interpreted as positive numbers, but we need a negative physical values. One solution would be physicalvalue = -30°C + 0.5*canvalue. So the offset need to be set to -30°C (or plus, I do not know how it is treated in the OI can mapper), and the scaling 0.5 (or 2, I do not know in which direction it calculates).

[Jacobsmess]

"You are on a good way, but still some steps to go." Will be the motor of my project.... And many other projects!
This is all very very useful and helpful and I'm dangerously close to understanding some of it.
Now is the time to let it sink in, then come back and read it again, and again, and probably one last time.

[johu]

or plus, I do not know how it is treated in the OI can mapper

Yes you can specify an offset from -128 to 127 (stingy on memory). For temperatures a possible specifier would be

Code: Select all

can tx tmphs 1280 16 8 2 80

on the transmit side. Internal calculation is canval = (physicalvalue * gain) + offset. So e.g. -15°C would be -15*2+80=50

If the receiving side were also OI (which I understand it isn't, but just as an exercise) you'd go

Code: Select all

can rx tmphs 1280 16 8 0.5 -80

Internal calculation is physicalval = (canval + offset) * gain . So (50-80)*0.5=-15