Modern Vespa

Because I needed another project.

It's been my intention for a good number of years to try to figure out the underlying communications protocol of the ECU used in the GTS, LXie, and various other injected models under the Piaggio umbrella. I am a software engineer by trade, and device communication is one of my specialties. I have spent literally years of my career doing forward and reverse engineering on various devices, over a huge variety of communication protocols. So this has always seemed like a project that would be right up my alley, if only I had the time.

Well, I don't have the time. I still have projects stacked up around the house, waiting for me to get to them. Still, I've been amassing all the necessary equipment over the years to tackle this project, and recently I had enough of those things on hand that I could at least start.

Some critical pieces:
- Fluke 124 Industrial Scopemeter -- Take the scope to the bike, not the bike to the scope
- Saleae Logic 16 digital logic analyzer -- Small, cheap, and runs on a Mac
- DigiTek diagnostic tool for Piaggio and Vespa bikes -- this is the traditional dealer diagnostic ECU reader

With all three of these in my possession and an open workbench, I was able to start analyzing the signals.

Task 1
Build a tap connector to go between the bike's diagnostic port and the Piaggio ECU reader. The connector is an AMP Superseal 1.5 3-pole connector, but only two wires are actually populated.

---

Task 2
Figure out the signal levels. Is it TTL? Is it some variant of RS232? Is it CanBus? No. It's kind of TTL-ish, but uses inverted 12V signals instead of 5V. The outer pin on the diagnostic port is communication, and the middle pin is ground.

---

Task 3
Having established the signal level at 12V (which is really going to be 14.5V while the bike is running), I needed to create a quick circuit to bring the level down within range of my logic analyzer (0-5V) so as not to destroy it. I made a second tap connector to go between the bike and the ECU reader, this one with a little circuit board attached. A 10K resistor and a 5.8K resistor in a classic voltage divider layout brings the 14.5V down to a level approximately in line with the abilities of the logic analyzer.

---

Task 4

Now it's time to capture a trace. I hooked up the logic analyzer to my new circuit, fired up the software, started the trace, started the ECU reader on the "Read Parameters" mode, and captured about 12 seconds of data.

---

I'm now decoding the data, and I've made quite a bit of progress in deciphering the communications protocol. But more on that in a future post.

R

This would be pretty much "the next big step (to breaking our bikes)".

Bravo.

For all of us that will be following along. Once you decipher the protocol what is the next step?

step 3: 100 mph!

Well, I've basically deciphered the protocol already. Or, I've managed to stumble on the industrial standard that the ECU uses, and matched the data trace I captured to that spec. I'll post more about that tomorrow.

The next step is to document which commands the Piaggio ECU reader uses for each function. After that, I'll want to tackle reading out the EEPROM from the ST Microcontroller inside the ECU. As it turns out, I now know that this is possible (there are some systems on the market that in fact will do just that) and I also know that the codes for the chipped keys are in that EEPROM data. Theoretically, one can read out those codes and program new keys -- including the red master key -- from that data.

After that, I want to decipher the fuel map, alter it, and program it back into the ECU. I think this should be possible, since there's a company in Germany that is advertising that service.

Yeah, but what's Phase 2?

Ding Ding Ding

We have a winner..

R

Okay, the real next step is going to be to build an interface between the ECU diag port and a computer. This will allow me to create an app (probably a simple command-line tool at first) that will pretend to be the Piaggio ECU reader and allow me to further explore the ECU internals.

And I have a simple design in mind that will give me a serial connection to the ECU over a USB link.

and I just sold my scooter because I wanted to go fasted

Hook up the doll. Then who cares about Vespas.

Weird Science reference FTW.

we have the software to edit the maps and load them into the Vespas.

Really all the magnetti-marelli ECU bikes can be done this way-- Aprilia, Moto Guzzi, Ducati, etc.

Micah's (AF1) custom GTS300 is hitting close to 100mph

Check out all the tables that can be adjusted on a GTS250-300.

The files are then loaded with the Rexxer flash box. The software will create a new .bin file and then the Rexxer box will load it into the scoot.

Still in the early stages of playing with it all. They have a better map for stock bikes that we are testing.

Well come on, post to the GTS Land Speed Record

Picture of the GPS!

Yep. Figured someone was playing with the Rexxer stuff by now. Unfortunately, their pricing is well out of reach of most of us. By doing my own reverse engineering of the MM ECU and posting my results, I'm hoping to bring the price of entry down considerably.

(And realistically, by the time I am done I will have spent enough time and money that I could have just bought a full-on system from them -- but that was never the point of my project).

yeah it wasnt cheap, but the ECM software lets us custom edit maps for all the bikes we specialize in. Scoots was just a bonus.

I need to get them to crack the 150 Vespa .bin files, as those scoots are lean at part throttle and the on/off throttle could be so much smoother.

We can use the one Rexxer loader box for all the bikes too.

I think what you are doing is super cool...if you could make a cheap .bin loader, we could come up with the better .bin file to load.

I think I could build a USB / ECU interface for about $30. I've got some parts on order, will be experimenting soon.

Who needs sleep.

Exciting project!

This just blows my mind on many levels. I wish I had this type of knowledge, passion and dedication.

(back to watching Step Brothers on FX)

Jess
How on earth do you expect to complete this project without a Retro Encabulator ?

Amazing experimentation. I'm always left wishing I understood better how things work. At least until I need another riding fix...

It will be tough, for sure. I'll try to muddle through, though.

Good luck with the project. Awesome on many levels.

If you are ever able to crack the code for the ignition keys maybe keep it to yourself. We wouldn't want a $30 product that makes all our immobilisers redundant.

I'd be first in line for a new fuel map.

Ha!!

who the fck needs Higgs Boson, we got Jess

keep up the good work chap

Jes, I take it that scaling down the o/p sig was from experience? Not checking the o/p sig voltage is a mistake I won't make again, fried a board on a signal converter interfacing a CNC tickertape writer, well it looked like RS 232. mmm bosses were none too chuffed.

Look forward to reading more.

I had been told many years ago that the ECU probably used CANBus communication, but I was able to rule that out pretty much right off the bat. CANBus typically uses two signal lines that create a differential signal, with one line going high whenever the other line goes low, and vice versa.

And despite the 12V signaling, this wasn't really quite RS-232, either. RS-232 signals are traditionally +-12V, with the signal line swinging from positive to negative as it goes from high to low.

In fact, superficially, the signaling I was seeing resembled TTL communication, with idle state at the supply voltage and a 1-bit at 0V. However, TTL voltage is never more than 5V. Running 12V into a TTL receiver is usually considered poor form, and tends to result in the release of the all-important magic smoke that makes ICs work.

So, a mystery. And here's where I got lucky. I had been poking around on the interwebs in between bouts of soldering, looking for information on the GTS ECU, which is made by Magneti Marelli and is technically known as the MIU model. Magneti Marelli doesn't say jack about this device on their public website, aside from mentioning that they make it. No documentation, no technical specs (aside from some marketing overview fluff), no nothing.

Just by chance, though, I stumbled on some mention of the MM MIU elsewhere on the internet, and this documentation labeled the pinout of the ECU that leads to the diagnostic port as the "K-Line". This one single reference led me on a wild ride through the internet, discovering in-depth documentation of an industry specification known as K-Line, aka ISO-9141. It turns out that K-Line is one of the early automotive diagnostic protocols that were eventually bundled into the OBDII specifications found in all cars in the US since 1996. More specifically, K-Line uses signal states of 0V and battery voltage -- exactly what I was seeing.

Somewhere along the way, K-Line / ISO-9141 morphed into a more advanced standard known as Key Word Protocol 2000 (often abbreviated KWP2000) and defined formally as ISO-14230. At the physical layer, the signaling mechanism of ISO-14230 is identical to ISO-9141, so "K-Line" is still an accurate term, depending on what layer of communication you're referring to.

Having established that the signal levels I was seeing were consistent with K-Line, I sat down with the trace I had captured to see if the data made any sense in that context. After fiddling around with some settings in the Logic application, I was able to have Logic decipher the bits with their Async Serial protocol analyzer, turning the bit signals into hex digits. After scratching my head for a few hours as to why the data didn't seem to make sense, I fiddled around with the Async Serial settings some more (remember, I only just got the Logic 16 device, and haven't used it before) and then I was able to get a new set of hex digits that actually made some sense.

And lo, a light shone down from above.

Now for the first time I was able to see the message from the DigiTek scanner to the ECU, and the response of the ECU back to the DigiTek scanner. The bytes I was seeing not only made sense, they conformed perfectly to the KWP-2000 communication protocol. So the ECU doesn't just use K-Line signaling, it uses the higher-level ISO-14230 protocol built on top of it. Perhaps not all of ISO-14230, as it's a pretty big spec. But at least I now have an understanding of the sentence structure, even if I don't know all the vocabulary yet.

This changes my whole approach, in fact.

ISO-14230 is officially a part of the OBDII specification. Auto manufacturers since 1996 have been able to choose from among five different protocols to fulfill their legally-mandated OBDII requirements. Because of its inclusion as one of these OBDII protocols, there is a fairly broad representation of parts that understand K-Line signaling or even the subtleties of the KWP2000 protocol built on top of it. At the low end, there are chips that will translate the 0-12V signals to and from TTL-level signals. At the high end, there are chips that do most of the packet-level communication for you, based on a serial connection.

One of these chips, in fact, has become somewhat legendary in the industry: the ELM327 chip speaks all flavors of protocol found in OBDII connectors, and thus is a popular choice for all manner of OBDII scanner tools. In fact, it's my understanding that most OBDII scanners have at their heart either an ELM327 chip or a cheap knock-off of the ELM327 chip, made from v1.0 of the ELM product before they realized they needed to copy-protect the programming inside the chip.

Theoretically, I think I ought to be able to hijack a cheap OBDII <-> USB device, the kind that expects to be plugged into a computer so that software can drive the process. Most of these devices simply run the serial ELM327 output to a serial <-> USB converter and call it a day. Which is good, because I don't need or want a scan tool that attempts to drive the whole OBDII diagnostic process -- I want an easy way to hook my computer up to the ECU so that I can poke it and probe it and try out different parts of the ISO-14230 spec from the comfort of my keyboard.

To that end, I'm expecting delivery by tomorrow of an appropriate OBDII <-> USB interface and a sacrificial extension cable. Once I build a cable and get some drivers installed on my Mac, I should in theory be able to start figuring out the well-documented ELM327 communication protocol, which will allow me to send and receive data directly to the ECU on the other side.

In theory.

A few diagrams.

Here's a screen shot of what the "fast init" process (something that is specific to ISO-14230) looks like. It's 25ms low (which is actually "1") and 25ms high (which is actually "0") followed by some commands that we are zoomed out too far to see here.

Right after the init, here we have the DigiTek ECU reader addressing the ECU:

Here's the ECU responding:

Zooming way out, here's the DigiTek querying the ECU for parameters (the lines with wider spaces between them -- though you can't see the detail, each line is a whole byte) followed by the response from the ECU (which has less space between each byte).

Nice work! Now that you've figured out what language it speaks, you have a "dictionary" so you can build your virtual Piaggio ECU Reader, right? Or do you have to do a lot more sleuthing to figure all that out?

How interesting...... So, I assume you'll build patch cable to interface the OBDII connector to the diagnostic cable on the Vespa. On the computer end, is this as simple as opening a port and typing commands similar to the old serial communications with modem? In looking at the OBDII to USB products available, most come with some generic software, PC based I presume, that will read codes and display sensor information.

I'm interested in playing with this as well. Not for modifying mappings and such, just from a diagnostic perspective.

Thad

It's more like I have the rules of grammar without the vocabulary. I know what structure each query takes, and what form the response takes, but the queries above have details buried in the payload that seem to be vendor-specific. It'll take a bit of work to figure out which ECU parameters are assigned to which op code. Shouldn't be too hard, as there are a finite set of parameters and I know what they are. I just have to make some observations and take some guesses about which are which.

You guys amaze me, and I find it fascinating!!

That's the plan, yes. At least, I'm theorizing that it ought to be possible to cobble together a working ECU <-> USB interface from off-the-shelf products, slightly modified to use a different connector. In fact, the ELM327 "language" is very much just like communicating with a modem via Hayes-style "AT" commands over a virtual serial port. I doubt very much any of the OBDII diagnostic software will be of any help, but I'm guessing that much of the functionality of the MM MIU will be according to the general conventions set out in ISO-14230, and thus will conform to the ELM327 parser in the OBDII <-> USB interface.

Before that, however, I think I need to create a slightly different ECU <-> USB adapter, one that is geared toward listening in on the conversation between the DigiTek and the ECU. The Logic 16 device was a great first step, but it's going to be somewhat awkward to observe ongoing conversations with. To speed things up somewhat, I'm going to attempt to use an FTDI USB <-> serial interface cable, connected to my tap cable (and the voltage divider) so that everything that happens on the K-Line gets picked up by the FTDI cable and sent to my computer. I'll then write a simple command-line tool to monitor the communication and maybe even parse the packets into symbolic keywords.

Jess, I admire your passion. Seems like you've got the theory and there's just some practical bits to work out. It makes me smile to know I'll someday need a USB adapter to hook up to the scoot. I already imagine threads about diagnostics and firmware upgrades.

You guys are the future. I look forward to the trend this thread implies.

Thanks again!!

Dude. Awesome.
If I could give you more thumbs up I would.

What if this thread tips off the mad scientists in the Piaggio Lab? Sweep the house for bugs and watch for cars tailing you....

"Breaking Code - we don't cook...we crack." (horrible Breaking Bad analogy)

Now I get it. Thank you.

Once you get this figured out, you would be in a position to combine your technology with a cheap cell phone and create your own little OnStar service for Piaggio owners. Seriously, think of all the folks out there who don't even have access to a dealer. Your little gizmo could be packaged up into a service that would call/email them and tell them why their scooter just stopped running, what part they need (or are going to need in the near future), etc.

Sorry, I'm really jumping ahead, but it's a thought.

I don't even think you'd have to combine it with a cell phone. If the device could be made relatively easily from off-the-shelf parts and hooked up to a simple piece of software, it would be within reach of a lot more people. Perhaps not everyone, but anyone who is capable of making a custom cable.