CAN bus & ECU support plans
Moderators: JeffC, rdoherty, stieg, brentp
CAN bus & ECU support plans
What are the plans for CAN bus and ECU support?
It's my understanding that asides from implementing the general CAN bus protocol, you will also need ECU specific code to extract and interpret the data.
When is CAN bus support expected?
Will ECU specific configuration be posted?
Can the community help develop ECU profiles?
Thinking about pulling the trigger, but I need CAN bus support....
Thanks!
It's my understanding that asides from implementing the general CAN bus protocol, you will also need ECU specific code to extract and interpret the data.
When is CAN bus support expected?
Will ECU specific configuration be posted?
Can the community help develop ECU profiles?
Thinking about pulling the trigger, but I need CAN bus support....
Thanks!
-
- Posts: 43
- Joined: Tue Apr 30, 2013 10:35 am
There's lots of bike-engined cars out there running Hayabusa and other GSXR variants. I've got a K8 GSXR1000 in mine. The data stream from that is serial and there's a good bit of detail on it:
Hayabusa
GSXR1000
Source code
I'm most interested in gear position, rpm, throttle position and clutch. Admittedly, I could get all of that from the analogue inputs on my RCP (which is in the post) by tapping the appropriate sensors...
Hayabusa
GSXR1000
Source code
I'm most interested in gear position, rpm, throttle position and clutch. Admittedly, I could get all of that from the analogue inputs on my RCP (which is in the post) by tapping the appropriate sensors...
Sprinting an ADR Sport 2
www.endurancelay.co.uk
www.endurancelay.co.uk
Hi Brent, is it possible to share any of the interface specifications associated to the hardware expansion port? From the schematic it appears that it's implementing (or will in the future) an SPI inteface? If so, any insight into what that might look like from a speed, clock polarity/phase, typology etc.brentp wrote:Yes! The top two current projects are the bluetooth modue + android app, plus a CAN interface via the hardware expansion port. Watch for news on this within the next few weeks!
I'm looking to do a Honda OBD1 interface to pull data from the datalogging port on a chipped ecu. It's a fairly straightforward polling arrangement over a 38400/8-N-1 TTL level serial interface. Typically single command bytes are sent (there some multi-byte commands) and the ecu returns the appropriate parameters value. 16 bit data is retrieved by 2 separate command/responses to retrieve high and low bytes.brentp wrote:As far as ECU specific configuration, we'll need help from the community to collect and document specific codes. If you have any resources available now, please post them here!
So to implement this will require the RCP to be able to interface to a 38400/8-N-1 TTL signal. I'd expect that there will also need to be the ability to setup and log dynamic channels for the data that is retrieved.
Let's know if you have thoughts.
Cheers
Ian
Smig,
Correct; the expansion port is SPI. How it's implemented is up to the device being connected, within the capabilities of the processor. For example, with our OBD-2 interface, there will be a firmware addition to communicate with the SPI device.
You can also use the RS232 port normally used for the telemetry and/or bluetooth connectivity; this might be an easier integration at the cost of losing bluetooth and telemetry features.
Hope this helps,
Correct; the expansion port is SPI. How it's implemented is up to the device being connected, within the capabilities of the processor. For example, with our OBD-2 interface, there will be a firmware addition to communicate with the SPI device.
You can also use the RS232 port normally used for the telemetry and/or bluetooth connectivity; this might be an easier integration at the cost of losing bluetooth and telemetry features.
Hope this helps,
This sounds like the right approach to get things talking and proved out at this stage.brentp wrote: You can also use the RS232 port normally used for the telemetry and/or bluetooth connectivity; this might be an easier integration at the cost of losing bluetooth and telemetry features.
So I think I can get the data read in and converted/scaled with some lua scripting. What I don't see at this point is how I get the data to be logged to the SD. Is it possible to create "math" channels with the scripting as it exists in the latest firmware version or alternatively "set" an existing analog channel to the calculated value and have that be logged?
Thanks
Ian
Could something like this be used to allow use of the Expansion port with a CANbus interface?
http://www.avrcard.com/Documents/can/ca ... asheet.pdf
http://www.avrcard.com/Documents/can/ca ... asheet.pdf
Also posted in that other thread, but - yes our CANx module is very similar to what you linked.
https://github.com/autosportlabs/CANx
We're working on the firmware right now. Stay tuned!
https://github.com/autosportlabs/CANx
We're working on the firmware right now. Stay tuned!
Yes - if you were following the commits to github! https://github.com/autosportlabs/RaceCa ... /tree/CANx
Done:
* hardware design is finalized
* CAN message read / write functional
* Lua scripting enabled for CAN message read/write
* Standard OBD2 PID reading enabled in firmware, blends with other channel data
* New API for version 2 firmware
* Improvements to Lua Scripting, including a log viewer to aid script debugging
Still to do:
* Virtual channels to enable receiving custom CAN messages and binding them to Logger channels, using math, algorithms, etc.
* Update Race Analyzer UI to select which OBD2 PIDs you want to query
* Update Race Analyzer for new Version 2 API
* CAN bus message sniffer to aid integrating custom / undocumented CAN hardware
We may be looking to beta test with users before full production. shmed , do you already have a RaceCapture/Pro system?
Done:
* hardware design is finalized
* CAN message read / write functional
* Lua scripting enabled for CAN message read/write
* Standard OBD2 PID reading enabled in firmware, blends with other channel data
* New API for version 2 firmware
* Improvements to Lua Scripting, including a log viewer to aid script debugging
Still to do:
* Virtual channels to enable receiving custom CAN messages and binding them to Logger channels, using math, algorithms, etc.
* Update Race Analyzer UI to select which OBD2 PIDs you want to query
* Update Race Analyzer for new Version 2 API
* CAN bus message sniffer to aid integrating custom / undocumented CAN hardware
We may be looking to beta test with users before full production. shmed , do you already have a RaceCapture/Pro system?