CAN receiving and broadcasting ideas

[jsmcortina]

I'm looking to see what interest there is in extending the existing CAN receiving and broadcasting features in MS3.

Presently we have:
- 500k bit
- able to receive arbitrary 11bit messages into a subset of variables.
- able to broadcast 'dash broadcast', "realtime data broadcast' and some hardcoded messages using 11bit message.

Possible thoughts I have (that may or may not get implemented)
- allow baud rate to be changed
- allow disabling of 29bit Megasquirt-CAN
- allow receiving of 29bit messages
- allow data to be received to other variables
- allow custom broadcast messages to be built 11bit and 29bit

There may be memory and processing constraints that prevent these from being done as well as prioritisation of development effort. Note that any changes to baud rate or 29bit CAN would break compatability with any existing Megasquirt-CAN devices.

I'd like to see what, if any, interest there is in these or other ideas and why you think they would be beneficial.

James

[Raymond_B]

The custom messages sounds very cool. You could use these to trigger events on whatever device is listening or maybe identification of what device sent the data? I wonder how you could implement these in TS? Would you choose from existing items or be able to build conditions or thresholds?

[winstonusmc]

I would like to see the ability to assign any variable within Megasquirt to any header value. This would allow compatibility with any gauge or other CAN controlled device. In my case, the Nissan IPDM under the hood receives a message from the ECU to activate the cooling fan and the A/C clutch. I have an arduino right now translating it for me and it works well, but I wish it controlled it directly. Not really sure of an easy menu for this. Maybe the first option is the data header -> then each variable assigned to a Byte, either a value or a bit flag.

[krisr]

Would these changes enable a user to hook up something like a CAN enabled PDM?

[racingmini_mtl]

It would be interesting to extend CAN receiving to have all the datax1 variables be visible through 11bit messages. This could be done through a single base ID or through many base IDs for each group of data.

Jean

[xrattiracer]

changing baud would be an easy and useful one. there are people without other MS CAN devices but do have stuff like the holset HE351 turbo that could benefit from this.
custom message formats would be very nice for people to hack in support for new devices, if you can figure out a way to make that possible.

[fpvmustang]

something to note on the holset he351ve I believe the ford ones are 500kbs. All I know for sure is they won't talk to dodge on 250kbs. Still trying to find one of these rare actuators.
Can broadcasting to EPS (electric power steering) would be a nice feature to develop. Think I have enough info for rav4 or prius. http://www.msextra.com/forums/viewtopic ... 23&t=61706
Alot of new cars are running EPS with CAN BUS control. I looked at several fords they were all can bus.
I have a saturn vue eps coming with controller. For a 65 Ranchero.

[thokes82]

Why not obsoleting the proprietary protocol completely and go to standard messages for everything. This would finally allow to use all hardware to configure or change variables. I would like to be able to use my Race Dash Display to send can messages to change RPM limit or other values. There can still be a protocol-logic behind but this strange masking of the ID is something really weird and can give strange conflicts when other hardware with 29bit is in use. I also do not think that there is any added value that MS knows from which device the new data comes.
All in all it would help to stratify the CAN Network with CANdb++ and dbc files and "professionalize" MS further.

[racingmini_mtl]

Why not obsoleting the proprietary protocol completely and go to standard messages for everything.

Because there are a lot of devices out there that use the protocol and you would obsolete them all. Having the option to turn it off is one thing but removing it completely would not be a good thing.

When the next MS ECU version comes out, you could have more than one CAN bus on the ECU and keep the proprietary protocol on just one. But for now, it is true that any 29-bit traffic on the bus has to use the MS protocol otherwise there is a potential for conflict. This has been mentioned on the forum but it should be made very in clear in the documentation. And device that generate extended CAN messages not using the MS protocol should not be connected to the MS CAN bus.

Jean

[sfrederick]

I would say go for it... Its something that I am sure alot of people would be interested in that feature.

[MWPau]

Why not obsoleting the proprietary protocol completely and go to standard messages for everything. This would finally allow to use all hardware to configure or change variables. I would like to be able to use my Race Dash Display to send can messages to change RPM limit or other values. There can still be a protocol-logic behind but this strange masking of the ID is something really weird and can give strange conflicts when other hardware with 29bit is in use. I also do not think that there is any added value that MS knows from which device the new data comes.
All in all it would help to stratify the CAN Network with CANdb++ and dbc files and "professionalize" MS further.

^ yup, agreed 100%.

And possibly test it in 1.5, then backport it to 1.4 so it could get out there quicker.
Its obviously a feature that a lot of people want.

[jsmcortina]

Totally dispensing with the proprietary "Megasquirt-CAN" has a number of challenges. Existing Megasquirt-compatible devices would need changing too.

Live data exchange using regular 11bit broadcast messages is already something I've started to work towards (e.g. the Microsquirt IO-box firmware works that way) and isn't too challenging.

However, for "CAN passthrough" tuning a new protocol would need to be written to sit on top of 11bit of 29bit identifiers instead of encoding the data into the identifier. Whatever is determined would need to be supported by all connected devices. It will inherently be somewhat slower than the proprietary protocol - despite its many issues, it is bandwidth efficient for passthrough tuning and is also efficient in processor usage.

It is very unlikely that these changes would be backported to MS3 1.4 as that is now in the stable phase. It is also unlikely to be supported on MS2 at all due to memory and processor constraints.

Please continue to post up discussion on this or other areas.

James

[Raymond_B]

James, you had mentioned possible performance impacts. I had wondered about this when turning on all fields in Advanced Real-Time Data broadcast. I imagine once there's two way communication the load on the Megasquirt is quite a bit higher. I come from a server background, but would this CAN communication be analogous to setting something as a lower priority background process? Meaning could one actually impact the operation of the vehicle with too much CAN stuff, or are the vital processes protected?

Anyway, after working with the touch screen displays I could see it being really handy for certain items. Such as a condition being set via touch screen. Something like track, street, or economy mode buttons or acknowledging an error (CEL tripped for example) and changing a parameter etc.

[jsmcortina]

Broadcasting isn't too bad, receiving is worse due to a linear scan during the ID matching process. I've added new code in 1.5 to set the hardware filters that may help reduce the processor loading on a busy CAN bus. With a limited number of messages at moderate rates, the impact shouldn't be great at all. If the bus was fully loaded with packets that pass through the hardware filters, then the processor will spend a chunk of time attempting to decode them.

Critical items like crank/cam inputs are handled in interrupt code and the fuel and spark outputs are on the XGATE co-processor. What would be affected by heavy loading would be how quickly the fuel and spark calculations (lookups etc.) are performed, so in a worst case scenario it may be a few rotations of the engine between fresh updates.

James

[racingmini_mtl]

Totally dispensing with the proprietary "Megasquirt-CAN" has a number of challenges. Existing Megasquirt-compatible devices would need changing too.

Live data exchange using regular 11bit broadcast messages is already something I've started to work towards (e.g. the Microsquirt IO-box firmware works that way) and isn't too challenging.

However, for "CAN passthrough" tuning a new protocol would need to be written to sit on top of 11bit of 29bit identifiers instead of encoding the data into the identifier. Whatever is determined would need to be supported by all connected devices. It will inherently be somewhat slower than the proprietary protocol - despite its many issues, it is bandwidth efficient for passthrough tuning and is also efficient in processor usage.

Unfortunately, CAN passthrough is not just used for tuning but, in the case of all my CAN devices, it is also used for CAN firmware upgrade. And that means that this is not a field upgradable thing and that the amount of memory for the code is very limited. And not all boards have a serial port.

So all this talk of obsoleting and/or replacing the MS CAN protocol makes me very uneasy. It would also potentially affect hundreds of current users in one way or another.

Jean

[thokes82]

I was aware that it will mean a significant change for people like jbperf. I assume that such feature would have an adequate announcement time and some sort of parallel support.
We are carrying this proprietary protocol with us since B&G times and I think it is really a question of how many developers you want to get to support MS products. To be able to change configuration via standard CAN is of course requiring a lot of development. It requires to put a protocol on top of the standard as James rightly said but this way you make it really easier to most external developers. You do not need a lot of explanation to get a CAN developer up to speed for example.
Anyways. I can understand the difficulty with this.

[jsmcortina]

I'm not planning on removing the "Megasquirt-CAN" however a mid term goal is to make it non-preferred and support passthrough tuning some other way.

I don't consider giving 3rd party developers access to tuning Megasquirt over standardised CAN to be a high priority, that's surely a real minority interest and the Megasquirt-CAN is documented.

However, giving easy access in and out of realtime data using standard methods is important and should benefit many customers.

James

[racingmini_mtl]

I'm just trying to see how that affects current users who might have new hurdles to use their CAN devices, what that means supporting both the MS3 and the MS2 with the same device and code (including the serial monitor that is not field upgradable) and what it means for current partners co-developing new products.

But that's outside the scope of this thread although it is very much related to whatever comes out of it.

Coming back to what is within the scope of this thread, I think that having custom messages containing any combination of output channels would be useful (similar to the unused or underused outmsg messages). However to be truly useful, to keep user intervention minimal and to not require the user to understand all the inner data structure, it would be necessary to be able to define the content of these messages from a remote CAN device using some CAN commands.

Jean

[stevevp]

James,
if you are long term planning for CAN changes it is also worth looking at the CCP/XCP protocols for standardisation. Primarily a calibration protocol designed around self addressable multiple networked units but does provide a stable and lightweight framework for broadcast/receipt and firmware updates as well. CCP is the simpler of the two and should be sufficient.

[jsmcortina]

Thanks for the reminder, I looked at them a while ago but didn't get any further.

James