CAN Data for New PE ECU

[B Lewis @ PE Engine Management]

Hello All,

We are in the process of finalizing some things on our new ECU design, the PE-ECU-3 and I had some questions for you FSAE teams out there regarding CAN data. Our new ECU has a full time CAN bus that we use for streaming data. The questions that I have for FSAE are the following:

1) Are you currently or do you plan to in the future use CAN data?
2) If so, what do you use the data for?
3) What devices (dash, datalogger, etc) do you use that require CAN data and what protocol do those devises use to read the CAN data?

Thanks for the feedback. We are trying to implement as much FSAE input into this new design as possible. Contact me offline (info@pe-ltd.com) if you would be willing to provide more general feedback on the system or if you would like a datasheet. I can also provide tuning software for review.

[B Lewis @ PE Engine Management]

Hello All,

We are in the process of finalizing some things on our new ECU design, the PE-ECU-3 and I had some questions for you FSAE teams out there regarding CAN data. Our new ECU has a full time CAN bus that we use for streaming data. The questions that I have for FSAE are the following:

1) Are you currently or do you plan to in the future use CAN data?
2) If so, what do you use the data for?
3) What devices (dash, datalogger, etc) do you use that require CAN data and what protocol do those devises use to read the CAN data?

Thanks for the feedback. We are trying to implement as much FSAE input into this new design as possible. Contact me offline (info@pe-ltd.com) if you would be willing to provide more general feedback on the system or if you would like a datasheet. I can also provide tuning software for review.

[sbrenaman]

What is the estimated release date of the new ECU?

[Tickers]

I tried to implement a self-built CAN based steering wheel display/control system but bought a useless CAN microprocessor which could only handle the simplest of tasks and couldn't send messages in the MoTeC format (separate messages aren't actually separate message IDs).

What would be nice would be an ECU which could transmit/receive messages which could be altered by the user. Default it to a normal message style but have it so the user can change the message format in some sort of simple way (graphical would be nice).

[B Lewis @ PE Engine Management]

Tickers - What messages would you want the ECU to receive and what would the ECU do with these?

Scott - The ECUs are available now.

Thanks.

[sbrenaman]

Sorry, I meant when is the release date of the ECU without the 'beta' tag?

[Tickers]

Brian,

I'd like the ECU to react in any way it could with any other input. Last year what I tried to build was a steering wheel/dash where everything that possibly could communicated over CAN. That would have included displays, gear shift/clutch levers and other rotaries/switches to control car functions such as brake bias and ECU map.

It fell apart when the microprocessor in the wheel couldn't handle the displays, and the MoTeC message format was non-standard in a way that our microprocessor couldn't manage.

It would be nice to be able to have pretty much everything on CAN, from sensors to controls and displays, and to have the ECU able to handle a large number of CAN messages and react to each message accordingly.

[SNasello]

Although I am not an engine guy and my team(s) have never used any of the PE products, I have some input based on what previous ECUs i have used have failed to do with CAN bus.

Tickers, your comments are still not very specific as to what you would like. The CAN bus standard is such that any CAN microprocessor should be able to receive any CAN message, and convert it to some physical value that you can then display on your screen/wheel or log to a data recorder.

I have of experience with the the Bosch CAN bus and it doesnt meet my liking in a few areas:

1. you cannot change the resolution of CAN messages (i can only get wheel speeds in 8bit, but I want them in 16bit on my data logger).
2. You cannot tell it to receive CAN messages from other components.

So the features to implement in the ECU end would be customizable CAN messages (ie. which signal on which message and the number of bytes on the message) and being able to receive CAN messages from other sources and use them in internal ECU functions.

Implementing the customizable messages would reduce the CAN bus load significantly, but be a little bit more difficult for the user to set up, unless the software is really easy to use. You could also have a template (CAN database file) that would allow you to just transmit everything/preconfigured messages with almost no setup time).

[Tickers]

The problem with the processor at the display end was software based. We'd gone with one that came with its own GUI based software, which was also advertised as being able to do a wide number of things (such as SPI communication). Turned out you could only do those things if you chose to write your own firmware, the GUI software could only handle basic switches and couldn't interface with a display driver. The compiler software was hundreds of pounds, so we were left with a bit of a paperweight.

I'm not sure how much more specific I can be when I'm saying I'd like to be able to send everything that is physically possible over CAN. One problem with the MoTeC ECUs is that while you can send data to the ECU over CAN, it takes the place of one of your standard inputs if you want to do anything with it.

[murpia]

Hi Brian,

I have extensive experience with motorsport CAN systems outside of FSAE so thought I could help.

Generally, if your ECU is just streaming data onto a CAN bus your job is easy. Just implement the capability to choose CAN ID and update rate for each packet, and allow the user to choose the packet content in terms of signed or unsigned 16bit values (4 per packet). Scale the packet content appropriately if needed (0.1x or 0.01x etc.) so if e.g. you are sending lambda = 0.96 it will encode as 96. Use Motorola big-endian format, it is pretty universal in embedded systems.

As long as you document the formats used any competent engineer will be able to configure a suitable logger or dash to decode them. For good examples of configurable CAN decoding look here:

h t t p://w w w.gems.co.uk/assets/Media/downloads/manuals/DA1/DA1%20Manual.pdf
h t t p://w w w.race-technology.com/wiki/index.php/Configuration/CANInterfaceConfiguration
h t t p://w w w.racelogic.co.uk/_downloads/vbox/Manuals/Input_Modules/RLVBCAN01_Manual.pdf

There are a number of ECU / logger / dash etc. suppliers out there who will try and 'lock' you into their hardware by not publishing their CAN specs. My advice is to avoid them, unless you are getting a good deal in some other area such as big discounts or free support.

Also, some suppliers use a single (or very few) CAN IDs with clever packet encoding. This not what CAN is about, and is usually a legacy of migrating from RS232 to CAN without thinking properly. Megasquirt has done exactly this, unfortunately.

Regards, Ian

[Geoffct]

I would recommend you download the Vector CAN DB tool, it should be included in a demo version of Canalyzer . This will provide a good way to organization to your data, and takes care of figuring out the scaling and variables, along with packing the most data into a message. Teams that use a CAN bus tool will appreciate it as the candb files will be created for them. Some daq companies will appreciate it too.

CAN is designed to handle multiple priority messages being sent at near the same time. This IMPLIES multiple modules on the bus. Most formula SAE cars have two (maybe three) modules on their can bus. This mostly negates the priority features. The biggest remaining advantage over serial is the inherent organization of messages regardless of timing on the bus.

Most teams will use the bus simply as a higher speed transmission of data to the daq system. (speed which they probably don't need if the variables are only from the engine) I have yet to see a team who's wiring mass appeared to be reduced from the use of a can bus.

Periodic message are usually used to send status.
Event messages are used to convey dynamic information.
Poll messages are used to ask status.
Response messages send a specific status.

Periodic message is the easiest and best way to communicate data, for example configure a message to be sent out every 40-100ms that contains RPM, oil pressure, status of outputs, spark advance, PW, wheel speeds, etc. Another periodic message of say 500ms could contain temperatures, and a periodic message every 5000ms could total fuel consumed. Keep messages organized on predicted rates of change and importance of timeliness. Resist the urge to simply create a 4 message dump of the system.

Some events however could change the required rates. In a slip condition, wheels speeds become far more important and will change much faster, in this case an event message could be triggered and wheel speeds could be sent every 10ms or faster. Also user inputs usually take this form, a periodic message is sent when a user presses a button and every 100ms while holding the button and on the release of the button.

Poll and response is the method typically used on a serial bus system and on the most basic CAN setups. It should NOT be the only form of communication, but it should still remain on the bus for testing and custom work. Ie a starter module could send constant polls of the ecu to see if the engine is still cranking.

The issue with poll and response is that there is a lot of wasted bus load, sending the request every x time and waiting for the response. Also there is the issue with CPU cycle loading, messages in take an interrupt and will force a few dead cycles while the data is collected, stored, transformed, and transmitted. This doesn't become too much of an issue until a user decides to setup the DAQ system with a 3ms polling rate. Some intermediate systems actually have a configuration message sent out which sets up periodic rates.

A can message is composed of 44bits or 64bits of overhead for 0-8bytes of data. The bus is usually clocked at 500kbaud or 1mbaud, and allows for about 30 or 60Kbytes/s respectively on an 80% bus load. Poorly organized buses should stay below 80% in order to maintain reasonably expected message timing. Maximum bus transfer is close to 3MB/minute at 1mbit/s, this will fill the top of the line MXL pro dash in roughly 6 minutes, other systems are running gig's of memory to allow for high data rates. Other issues are how the daq system stores the data, some systems simply take the data off the bus and place them into memory to be polled at a set rate, more advanced systems take the time stamp the message was received and store everything together, yielding more accurate data. A fixed rate polled daq system will sacrifice the advantage of event based messages.

I hope this helps or that I can be of some help. I appreciate how PE supports SAE teams.

I would also love to see what the Gen 3 spec sheet looks like.

Geoff

[TMichaels]

I would stay away from asynchronous messages on the CANbus. They make your system less predictable and you need more "spare" datarate to account for bursts. It may waste some datarate by sending asynchronous data periodically, but you end up with a total predictable system. Otherwise you need to test your system with too much different configurations or events.

Regards,

Tobias

[murpia]

<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Geoffct:
I would recommend you download the Vector CAN DB tool, it should be included in a demo version of Canalyzer . This will provide a good way to organization to your data, and takes care of figuring out the scaling and variables, along with packing the most data into a message. Teams that use a CAN bus tool will appreciate it as the candb files will be created for them. Some daq companies will appreciate it too.

...

Geoff </div></BLOCKQUOTE>
That's a very good suggestion. My only concern would be that it encourages over use of 'data packing' as it supports pretty much any combination of packet bit counts and start / stop bits.

Stick to big-endian signed or unsigned 16bit data encoding and you'll have much fewer frustrated customers.

Also I agree with Tobias, try not to use the 'response' / 'request' paradigm but just stick all your data on the bus at a suitable periodic rate. Give the faster data lower IDs for priority. Use 1Mbps if you need lots of bandwidth, it's reliable enough over the short loom lengths of a car and still tolerates a bit of abuse of the termination resistor specs.

Regards, Ian

[roepke44]

<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by B Lewis @ PE Engine
1) Are you currently or do you plan to in the future use CAN data?
2) If so, what do you use the data for?
3) What devices (dash, datalogger, etc) do you use that require CAN data and what protocol do those devises use to read the CAN data?

. </div></BLOCKQUOTE>

We use CAN data from the ECU for driver warning lights (low oil pressure, over temp, etc), and general display of RPM and other engine health indicators on the dash. We use a Motec system because the data logger, ECU and dash can all talk and work together. I can't remember the protocol it uses. I really like the ability to record almost any ECU parameter, measured or calculated (injector pulse width, temp compensation, lambda readings, etc) to aid in diagnosis of problems. I also like that I can run two separate CAN buses with our system if we get close to the bandwidth limits.

On a different note, we use to run a PE system. we switched because we wanted an external ignition "module" because we kept blowing the internal ECU circuit. I know the problem was operator error, but it became a problem as our coils were always close to the current limit. Also, the small trigger wheel selection was difficult to adapt to our wr450. we eventually figured it out but it was not reliable, and ate up time that we should have been tuning. I hope that these are things that might be addresses in the new ECU.

[B Lewis @ PE Engine Management]

Thanks for all of the great info. Now to answer a couple of questions that people have posted....

<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content"> Sorry, I meant when is the release date of the ECU without the 'beta' tag?

Scott Brenaman - Portland State - Viking Motorsports
</div></BLOCKQUOTE>

-The hardware is pretty stable and has been in use for over 6 months now. We will probably keep the "Beta" tag for another 3 months or so as we finish adding engine configurations and some of the final software features.



<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">On a different note, we use to run a PE system. we switched because we wanted an external ignition "module" because we kept blowing the internal ECU circuit. I know the problem was operator error, but it became a problem as our coils were always close to the current limit. Also, the small trigger wheel selection was difficult to adapt to our wr450. we eventually figured it out but it was not reliable, and ate up time that we should have been tuning. I hope that these are things that might be addresses in the new ECU.

J. Roepke
Cal Poly SLO Alum
Aero & Engine 07-10 </div></BLOCKQUOTE>

- That is great feedback, and we have addressed your concerns in the new ECU. The new ECU has over-current protection built in that shuts down the driver and sets an error before destroying anything. In addition, we have a higher current limit and much better dwell control that allows us to limit the heat build-up in the driver.

- We are also actively adding support for many more stock trigger wheels. We are trying to get all of the FSAE popular combinations added which will allow you to run the stock crank and cam configuration. We currently have in place the 600RR, F4I and Aprilia engines and we are willing to work with FSAE teams to get other configurations added. Actually, we have several pro riders using our system on Yamaha 450 quads so we may already have something for your engine.

[B Lewis @ PE Engine Management]

Thanks for all of the great info.

On another topic, we are in the process of adding a traction/launch control
module for the new ECU. I think that we have a good handle on what works on full size vehicles and on dirt but what methodologies have worked well for FSAE size cars in the past? Specifically....

- Number of speed measurements (# of wheels)
- Number of teeth
- Method of reducing power (retard timing, cut cyl or both)
- Any other experience getting traction control to work on small pavement vehicles?

Thanks again.

[Nicky]

We wanted to encorporate a telemetry link between the Motec M800 that we use and a display/datalogging system(ground station) rather than hooking up parallel lines to a telemetry unit. Moreover since our budgets are very low we intended to build the entire system ourself.

The motec came with a CAN interface which we used to communicate with the motec parent software on our computers.

The first problem we encountered was sending data to the motec in a way which it could understand from our system i.e. data identifiers which are specific to the motec.

We tried obtaining spec sheets for it. But from what we could gather, they are closely guarded and are common between the various data-loggers, dash consoles etc. of motec origin.

Now the question is that how do we link up our own systems to an ECU which has its data protocols already setup. Thus we in reality don't know what data to request from the ECU as a result of this.

We then thought of adding a radio link between the M800 CAN bus directly with a 1Mbps link and hook the other end up to our computer. But when we enquired with the motec engineers, they said that it'd be highly unlikely for the system to work as the tolerance level of the software on the system to data corruption levels inherently present on a radio-link is very low.

The only other option we were left with was to directly link up our sensors or use redundant sensors just for the telemetry.

Result: We chucked the idea for now till we can figure a way to accomodate this. For now its the inbuilt dataloggers.


Nikhil M J
Ashwa Racing
Bangalore