Fiat 500 Forum banner

500e CAN bus decoding

21010 Views 44 Replies 17 Participants Last post by  Yayitazale
Hey people,

I've been poking around the 500e CAN bus in my spare time, trying to decipher messages for custom behavior, data collection (like performance and battery health over time), and remote control. I believe I've identified 30+ messages, but want to confirm before sharing widely and going further down this rabbit hole. Any chance someone is willing to collect and share a minute or two of logs? You can PM me with an attachment if you aren't comfortable sharing publicly. Here is what would be helpful:

No adapter:
  • Connect the logger directly to the ODB-II port (I believe this is CAN-C?)
  • 500k speed
  • Make sure car is "ready"
  • Take note of any metrics you have access to: % charge and GOM from cluster. Pack voltage, Soc, SoH-R, SoH-C, ODO, 12v from AlfaOBD or Multiecuscan would be extra helpful.
Yellow adapter (requires a physical Alfa/Fiat yellow adapter or direct wire like it does):
  • Connect the logger to OBD-II through a yellow adapter (I think this is CAN-B?)
  • 50k speed
  • Make sure car is "ready"
  • Perform some actions inside the cabin (change gear, turn climate on/off, turn various lights on/off, press SWC buttons, open doors)
  • Write down which actions you did
Any format is fine. Here is a snippet (of pressing vol- on steering wheel) if you need an example of what I am looking for:
Thanks for any help/consideration. Also, if you've already done some of this work I'd be happy to help or compare notes. I'd love to get this all documented for tinkerers, apps, and integrations.
See less See more
  • Like
Reactions: 1
1 - 16 of 45 Posts
wich logger do you (safely) use?
Any layout for the different can bus cables? (green/yellow/blue?) Where to get these?
Passive logging is very safe AFAIK, just records signals that are going out either way. I use a CL2000 which is purpose built for easy logging and has very little sending capabilities and a dedicated "silent" mode ensures it sends nothing. You could also piece together much cheaper options (Pi + a CAN shield.)

For the adapters, I have this set but only use yellow so far. One yellow cable description says: "Female pin 6 to male pin 1 - Female pin 14 to male pin 9 - Female pin 7 to male pin 12"
wow, thats a bit steep for rarely usage...
I get that. Pi and CAN shield is cheaper like I mentioned. Ultimately I have limited time to work on this project. I’d rather focus on results not worry about the right hardware/software or if I made a mistake and made my car unsafe.
Great to hear!

There are about 2k messages a second on CAN-C at idle and most Bluetooth adapters can handle around 100. If you do get up and running, let me know. ELM327 spec allows for filtering at device level so I could give you some PIDs I am more confident in which should allow you to capture/confirm.

Coincidentally I started down this path too (Mac + BT ELM327) since my high speed device failed. Ultimately I want a phone app + a the BT adapter since most people already have or can get setup cheaply.

Just before my good logger died I was able to do remote lock/unlock and precondition. Just need my replacement to come in so I can confirm I wasn’t dreaming 😄.
  • Like
Reactions: 1
@Wavelength We are at the stage where hundred or thousands of messages are coming in a second, 99.9% of which I have no idea what they contain. The other 0.1% I have a good guess. Having a high speed, logging focused setup is the only sane way to figure out which messages are useful and what they contain.

I agree at the end of the day a cheap, sleek, low throughput device is what you’d leave installed.
  • Like
Reactions: 1
@twinturboz I linked to some above that work for me. Can’t speak for these. I imagine if they are Alfa/Fiat adapters they should work.

Yellow is needed to get to most things inside the car (SWC, doors, climate, remote UConnect features, etc) though some of that data is also available without it on CAN-C.

I’ve sniffed Multiecuscan (using a splitter, ELM327, and the CL2000) and it is directly connecting to ECUs rather than consuming data already on the bus. I assume AlfaOBD is the same. Haven’t ventured down the direct to ECU path yet but you should be able to see everything it does.

Either way those apps are a good way to narrow down your hunt. Which bus, what does their data look like, etc.
One snag on cansniffer (tool from videos above) - looks like 29bit PID support was only recently added. On Ubuntu 20.04 cansniffer is blank for 500e (but candump shows correct data.) After building from source it works correctly.
  • Like
Reactions: 2
I’ve made good progress on passive signals and recently started figuring out requesting specific data. That’s more time consuming (and feels sort of sketchy) so I’d rather focus on what people would use - what is most interesting?

I imagine the EV basics? SoC, range, SoH, speed, motor RPM, 12v, etc. For the most part I’m able to see what the common apps are doing, but each data point takes time to figure out and test.
  • Like
Reactions: 1
Here is what I've got so far. As mentioned in the notes:
  • This is a WIP and probably has lots of errors.
  • It's is a living document so things will be added/removed/updated over time.
  • If you die or destroy your vehicle, thats on you.
  • A sample size of 1 means it works on my car, software, and hardware but hasn't been confirmed anywhere else.
  • Like
Reactions: 1
Does anyone know which protocol CAN-B uses? It's 50k, but all the software I’ve encountered “just works” if you know the speed. Trying to use something now that wants to know the exact protocol.

I've determined CAN-C is happy with ISO 15765-4 (CAN 29/500)
  • Like
Reactions: 1
Update for those looking to go Raspberry Pi route - here is a setup I built that sniffs both CAN-B and CAN-C at same time at full speed. Also works for the final install.
  • Raspberry Pi 4 (but any should work)
  • Waveshare "2-Channel Isolated CAN FD" hat
    • Setup docs here
    • Move 120Ω resistor jumpers to OFF
    • Move voltage jumper to 3.3v
  • OBD-II pigtail (triple check wiring/pins on these things with a multimeter)
    • CAN-B = 1/9 H/L
    • CAN-C = 6/14 H/L
    • Ground = 4/5
Moving forward I'll probably be building against this setup. Next steps are to filter messages into a database, show in a UI (HDMI to head unit), and figure out power management so it doesn't smoke the 12v when parked.
See less See more
  • Like
Reactions: 4
Been using the above setup for 2 weeks, works great. Overall I've found that there is a lot more to this project than simply finding the requests/responses/format - a lot of it needs be validated over days and miles. This lead me to build out the software stack to support that. Very easy to see when a formula or datapoint is wrong when it's live updating on the head unit.

Here is the foundation:
python-can - read/write to the CAN bus with little effort, even in our car. supports virtual devices for bench testing.
couchdb - easy to use database with GUI admin, but most importantly, it has a web API built in. easy to pull, replicate.
web app - simple HTML, CSS, Javascript app consumes the couchdb data to make a UI. No backend, internet, or fancy stuff.

Obligatory screenshot. Data is live, but some formulas not right. Still working out the layout/data visualization, but taking inspiration from Tesla and Bolt:

Current features:
  • Speed, gear, soc, range estimates, steering wheel lines, gauges, and a line at the bottom thats supposed to represent how aggressive you are driving. Consistent speeds, it levels out, hard launch/stops create the color spikes.
  • Dark main panel switches when charging, parked, or driving. Current setup is HDMI only so the screen is not touchable, so relies on automated switching.
  • Car overlays for doors/trunk open, placeholder for TPMS once I figure it out
  • History panel shows kW used/added but I plan on making it more useful with m/kw, historical temps, speed, and aggressiveness to sort of represent an energy "score"
  • Tied into my aftermarket blindspot/cross traffic alerts to show yellow warnings to left/right behind car

I'll eventually share the source once the project matures a bit - had a bug just this morning showing me at 102mph on residential streets :ROFLMAO:
See less See more
  • Like
Reactions: 2
The above linked spreadsheet is the best place to start. I am currently using both busses but data points sometimes exist on both. AlfaOBD and Multiecuscan also give an idea of what data is on the bus. If it requires a yellow adapter it’s on the slower bus. No adapter is high speed.

That said it’s all a work in progress. As I figure more out you might be able to pick one or the other depending on your project. Nerdy battery stuff? C. Remote precondition and light shows? B. etc..
  • Like
Reactions: 1
You need a yellow adapter since it’s on CAN-B. Then it’s all about configuring the ELM327 and sending the command. Does the dongle stay active all the time or does it eventually shut down? Power management could get annoying. Similarly the CAN bus shuts down shortly after you exit the vehicle. Not entirely sure if you need to wake it up in a special way, but sending the command twice seemed to work for me in my initial testing.
  • Like
Reactions: 1
The bus actually needs to be awake, so you may need to send it twice to ensure it’s actually unlocked. First command wakes it up, second time it unlocks.

It may work when in the vehicle but probably not while in gear. Preconditioning for example doesn’t work if the car is already on.
Hello, I'm quite new with all this stuff, but I figured I would point out there is a set of example commands here by the same author. He doesn't seem to be very active on this forum currently.
I got busy, lost steam, and eventually moved on to another vehicle (MINI SE.) In any case, this is the right path. ELM327 devices just need to be configured correctly to read/write. Most vehicles "just work" out of the box but 500e can be quirky.
Which OBD do you recommend for a 2017 500e?
I like ODBLink devices as it works with AlfaOBD, Multiecuscan, ABRP, etc. and any other car I've plugged into. Not the cheapest but they are reliable, secure, and have no battery drain issues. Occasionally even get firmware updates. Most importantly they are supportive of developers and casual tinkerers alike. I have MX+ and CX because I wanted iOS+Android support, but they do have other models for other situations.
  • Helpful
Reactions: 1
1 - 16 of 45 Posts