Discrete CAN mapping capabilities

[ryandoherty]

The ability to map CAN data values to a channel, as a more user friendly mapping capability before having to use Lua scripting. Lua Scripting would be reserved for more elaborate mappings requiring custom logic.

Each Mapping has the following configuration:

• A standard ChannelConfig:
• Name
• Units
• min
• max
• logging precision
• CAN Mapping
• Source data type(unsigned, signed, IEEE754)
• Endian
• CAN channel
• CAN ID
• Bit offset within CAN message
• bit width
• Value multiplier (float)
• Value offset (float)

A maximum of 100 mapping can be stored in the config (# TBD)

Upon the receipt of each CAN message, the ID is checked against a known mapping.

If a CAN ID is matched, the value is computed from the bit offset, then adjusted using the multiplier and offset Then, the channel value is set, presented in the telemetry stream.

[stieg]

@brentpicasso I believe you are working on this so assigning this to you.

[kosenko-max]

That would be wonderful if that will come together with some bitwise math option (with access to current values of channels) and https://en.wikipedia.org/wiki/ISO_15765-2 support. Otherwise in a majority of cases that I have in Evo X CAN it won't really work. I can't say how widespread that standard is, but it is a mandatory standard pretty much, so I assume that "a lot".

I suggest to consider that many CAN messages contain a lot of data (I have some that bring 20 channels in one multipart message), so it would be great not to do same request 20 times.

It's also would be extremely helpful if possible to define priority of CAN channels. So that some CAN requests made only 1 out of X times to give more bandwidth for high speed sensors, but be able to collect a lot of slow moving data as well.

[brentpicasso]

Related: https://www.autosportlabs.com/next-generation-can-bus-mapping/

The new CAN mapping mechanism should handle 90% of broadcast style CAN data seen typically from aftermarket ECUs and some OEMS (like seen on the BMW E46), alleviating the requirement of performing the mapping only in Lua.

OBD-II style request / reply transactions will be handled separately by an enhancement of the OBD-II subsystem, which will catch OEM specific PID requests (mode 23 et.al.) Lua will remain as a fallback for other types of mapping. The goal is to iterate on this feature and catch additional schemes / standards, but always have Lua based mapping as the ultimate fall-back.

On Thu, Feb 11, 2016 at 9:58 AM, kosenko-max notifications@github.com wrote:

That would be wonderful if that will come together with some bitwise math option (with access to current values of channels) and https://en.wikipedia.org/wiki/ISO_15765-2 support. Otherwise in a majority of cases that I have in Evo X CAN it won't really work. I can't say how widespread that standard is, but it is a mandatory standard pretty much, so I assume that "a lot".

I suggest to consider that many CAN messages contain a lot of data (I have some that bring 20 channels in one multipart message), so it would be great not to do same request 20 times.

It's also would be extremely helpful if possible to define priority of CAN channels. So that some CAN requests made only 1 out of X times to give more bandwidth for high speed sensors, but be able to collect a lot of slow moving data as well.

— Reply to this email directly or view it on GitHub https://github.com/autosportlabs/RaceCapture-Pro_firmware/issues/172#issuecomment-182979857 .

Brent Picasso Autosport Labs http://www.autosportlabs.com Technology for Race and Street

[kosenko-max]

Thanks, I will stick with Lua for now. I didn't yet explored how fast it is and if I would have to fall back to the custom firmware once you will upgrade limit of Virtual Channels and release port extender (somehow I need to bring in suspension and tires data). But I hope I won't need that.

In theory CAN mapping is not that different from OBD (well technically OBD is on top of CAN, I know). Are you sure you want to keep them separated? The only difference is that you need to ask for that data in order to get it. So I can see how interface can be extended where Address and ID is not what you're listening to, but merely what you're requesting for and whatever you get back is your answer.

[stieg]

In theory CAN mapping is not that different from OBD (well technically OBD is on top of CAN, I know). Are you sure you want to keep them separated?

Under the hood (as in on the RCP unit itself) we (very) probably will not. But in the UI layer we probably will in order to make things easier for less experienced users.

[kosenko-max]

I'd like to ask you to consider again proposal about request-based CAN mapping. This script https://gist.github.com/kosenko-max/c5cb086292c287e45004 successfully reads Mode21 and Mode23 single-part and multi-part messages based on a standards.

But now I can't fit channels definition into memory for script to load. I probably could change now definitions storage to string variable or even try to use files to make it work. But Lua is not made for that - it should be in a separate thread and it should be part of a standard CAN mapping just a request based.

If you take a look at my implementation - it uses same information as your CAN mapping, but keeps channels in a request groups with priorities. Lua should be left free for complex channels...

[brentpicasso]

Yes, this is already planned, it is being tracked by this issue. https://github.com/autosportlabs/RaceCapture-Pro_firmware/issues/167

[meikeric]

I'd like to throw two things in the mix.

1. Bitmasks on the CAN Address. E.g. Bitmask = 0xF, CANAddress = 1 Reasoning: J1939 breaks the CAN Address into different parts. With a Bitmask option, it would be trivial to split up the CAN address.
2. Bitmasks on Data Bytes.

These two features would help to match feature parity with advanced systems like Motec.

[brentpicasso]

Thanks, @meikeric . We'll take a look at that. Do you have an example of a J1939 message that breaks it down with a mask, to add some context?

[meikeric]

Please checkout PR: https://github.com/autosportlabs/RaceCapture-Pro_firmware/pull/894 I'd appreciate your feedback. I'd like to help accelerate the development of CAN message handling outside of Lua.

[brentpicasso]

Thanks for the contribution. We'll do what we can to incorporate your work into the larger effort.