I'd like to read at least RPM, TPS and ECT from the diagnostic connector of my bike (Yamaha Tracer 900 2019).
I've made a simple board with Arduino Nano v3 and the MCP2515 CAN module... my first issue was that the interrupt pin seems not work correctly (is always LOW) but I bypass the problem for the moment just checking the ret value of the read function to understand if something is ready to read. I'll try with a new MCP2515 module.
Now I can receive lot of CAN messages from my bike but how to retrieve the RPM. TPS and ECT?
It seems to me that the TPS could be send with ID 0x216 (bytes 1 and 3?), the ECT with 0x20A (bytes 2 and 3?) and the RPM with 0x280 (bytes 5 and 6?) but it's just a feeling looking at the screen while playing with the bike...
In attach the received messages... can you please help me?
Is there another way to retrieve the info I need? Asking via OBDII protocol?
If yes can you help me with the Arduino code?
Look at the thread Bike interface OBD (http://"https://forum.arduino.cc/index.php?topic=236092.msg1697710#msg1697710") in this section. Might be able to get some useful information.
Oh, I guess that won´t help.
Because in that thread, data will be translated from a custom K-Line signal into OBD2 compatible values.
Here, Bullone got a CAN-Bus, which already *should* be in OBD2 compatible format.
I´m not very deep into CAN-Bus. But I´d have tried to connect a regular ELM327 device to the bike and see if it is already capable of giving you RPM, speed, etc. via Torque, Carscan, or other OBD2 apps.
This seems to be a nice description how it works and how the CAN-bus handles the OBD2 PID´s and stuff:
Attacking CAN Bus (http://www.digitalbond.com/blog/2015/04/13/attacking-canbus-part-1/)
Good luck :)
Thank you so much guys!
I'll give it a look at both of the links :)
I have been working with automotive CAN bus communications for a few years and here is what I have learned:
(1) Capturing CAN bus data is easy.
(2) Decoding and understanding the data is not easy.
It is my understanding that motorcycles are NOT required to be OBD compliant, so the normal OBD scanner apps won't work. (no mode $01 for live date)
You best bet is capture the data and change one item (rev the engine) and try to figure out the algorithm used to calculate engine RPM. ASSUMING the engine computer is broadcasting engine RPM which it may or may not.
Also, look at the wiring diagram for your bike and try to determine how many CAN bus nodes are on the network.
This will give you an idea of what data is being broadcast on the CAN bus network.
I've tried to decode the CAN messages one by one but it's not simple so I decide to ask for OBD 2 messages and it seems to works fine.
The only think I'm not happy it that I'd like to ask for RPM, ECT and TPS with one request and get one response with all those 3 values so I'll have a "snapshot" with all data I need but still can't find a way to do it.
Now I'm asking for the data sending 3 requests and im my main loop I just read messages and when I have all 3 response I store the data but I'm not sure if that's the best approach to have consistent data.
I don´t see any possibility to receive 3 values at once by CAN.
You have to send three requests and store the three responses. That should not take to long!
Some manufacturers have individual functions to send some datasets constantly for testing purposes. But mostly not officially documented.
Thanks guys for the info!
It should be fairly easy as long as your on the right can bus.
You have done the hard part clearly.
1st thing to do is make sure you have a 16mHz xtal on the MCP board.
Then clock the SPI as fast as you can so that you do not miss any messages.
Then as others have said just monitor the bus.
Add some filters to eliminate those messages you don't care about,
find the ones you want, decode the packets and bingo.
You can either master the MCP onboard filter or just write your onw on the Arduino to simply ignore and not output those headers not required.
I actually used an ESP8266 with two can controllers.
Worked great for both listening and talking on the can bus.
Plus it was Wifi using websockets so could monitor everything in a normal browser.
Best of luck, don't give up you are 90% of the way....