Purplemeanie

Handwheels, Can't go wrong with a 420R! But I am also biased! ChrisC's website is a fantastic resource now... and goes way further than anyone else, my Purplemeanie site included. But if you want something to put you to sleep then my site is reputedly a great option! :-) At the risk of another bit of self promotion, I'll point you at my build video too. It's a bit bonkers how many people have watched it now, but I suspect its more entertainment than education, but you might get a kick from it if that's your thing. Also, if you haven't seen it already, Caterham Cave is doing a good series on building from kit, though he's not finished editing and uploading the full series yet... And finally, you can find a list of many of the build blogs here if you haven't found it already... https://www.lotus7.club/guides/getting-started-guides/build-blogs Good luck with the build! John

#8 Tuck2020... glad you enjoyed the blog and hope you enjoyed the video. #17 David... no problem and I agree. I had no idea if anyone would read my ramblings but it was a great way of documenting the build and makes me chuckle when I read it again. As time goes by it will become less and less relevant to others, bit it'll still make ME laugh! #18 Doctor... wow! Thanks! I'll have to get some badges made up for those that survived the whole experience, and then perhaps a gold one for anyone reading it in one go! :-) John

Thanks David that's interesting. Mine are working out at about 20,000 views a year, so we're very comparable I think. I suspect Daniel French has many more views but it would be interesting to see what others have done. I think a list of blogs somewhere on this site would be a great resource. I took a look at the page breakdowns of my site and it seems the most popular post of mine is on the engine cooling system and the animation I did. i was thinking of doing a YouTube video on the subject, especially as Mark (CtrMint)'s topic on 620 cooling has caused so much discussion. But interesting that its been a common theme for my site too, hmmm. For everyone's delectation, here's the all time stats on the top 30 pages on my site... I think Wordpress skews the stats somewhat, but also interesting that the Gallery is high up there. Hardly anyone reads my stuff about the ECU - not surprising! :-) John

David, if you don't mind me asking... what sort of traffic do you get to your blog? It might interest other people thinking about blogging their experience to know how many people actually read what they've written... I can offer the numbers from my blog which are a very modest, just shy of 60,000 views now. And just over 11,000 visitors. Both are all time figures for the 3+ years of running the blog. I'm sure other blogs must have much higher numbers. Perhaps that's worth a dedicated thread on ChitChat ?? I could give all the page stats if people are interested... might indicate what subjects people most have trouble with :-) John

#9 David, just finished binge reading your blog. Hugely enjoyed it! Well done and thank you for taking the time to do it! And thanks for hitting the like button and commenting on the video. It really helps to tell the YouTube algorithm that other people should get the video suggested to them. #10 James, thanks. You can find all the tools I used on my rather lengthy blog post in the next link (you can click on the pictures of the tools to take you to Amazon) - https://www.purplemeanie.co.uk/index.php/2018/07/01/caterham-420r-build-tools-and-trinkets/ After posting that link I always say this for full disclosure... the links are through the Amazon affiliate program, so in theory I get a kickback on any purchases made. I didn't do the program for that reason, it was just to get a way of being able to link reliably to Amazon. And just for S&G I can tell everyone that the affiliate links earnt me £6.95 in the last 6 months, with 5 purchases made through the links. Two of which were the folding creepers! :-) But a quick link to the creeper I used is here: https://www.amazon.co.uk/dp/B00EIGM5ZA/ref=as_li_ss_il?ie=UTF8&linkCode=li1&tag=purplemeanie-21&linkId=743d3ba4b39f6b886e379a7ef09c46ae They seem to be out of stock at the moment though :-( John

David, are you talking about the ECU blog stuff or the article in Lowflying last month and this? I tried really hard to make the Low flying articles accessible, but even if I didn't quite manage that, at least its out there now for others to follow in our footsteps. Thanks Piers, glad you enjoyed it.

David, thanks for the comment and for the appreciation of my blog - I very rarely get anyone on here comment about it. Makes me wonder if it was worth it sometimes! I hadn't seen your blog before, shame on me. But looks great... and I love the book! I'll add your blog to my list on my website. John

[ REPEAT ... Grr! ]

Hi All, I thought this one would be better in TechTalk rather than ChitChat as its slightly more technical. I just uploaded a bit of a longer video to YouTube this morning, documenting the build of my 420R nearly 3 years ago. I'd always planned to do this video, but for the usual many reasons it only got a few hours here and a few hours there since finishing the build in December 2017. But I've just had a week off work and with the weather a bit crap I decided to give it a final push over the line. I have no idea how many hours it took to edit the video but its probably well over 50 and might be closer to 100... bonkers, I know! The video is a bit rough in places, but I wanted to get something out as I hope its a useful addition to my (and others) blog. Below is the text from the YouTube description... note: when you're in YouTube now, you can click on chapter markers to jump you to wherever you want to go in the video... my favorite bit is the trip to the IVA at the end of the video when I'm leaning out of the car to see through the rain after the wiper fuse blew as I left the house! :-) I hope its a useful resource and of course I'd appreciate feedback, especially if I've made any glaring mistakes. Here's the link... John And here's the text from the YouTube description that includes the chapter minute:second timings,, but you can find that on YouTube too!

Hi Folks, I'm late to the party here... I know this is a 620 discussion but just wanted to throw in some work I did for my blog a couple of years ago when doing my 420. I hope I got everything right but it might help some people visualise what's being talked about, I appreciate its not the same as the 620's but hopefully the diagrams and the animations help the discussion. And of course I may have got some stuff wrong when I was writing things up and would greatly appreciate any corrections if I have. https://www.purplemeanie.co.uk/index.php/2017/09/23/build-session-17-5-caterham-420r-water-and-oil-overview/ Cheers, John

Hi Charles, I think I see where I'm getting confused - though I need to double check everything. On checking the Sigma wiring diagram it seems there is CAN bus there. But there's no sign of it on the 420 Duratec wiring diagram (my car) for the tacho. I'll need to do some more research and probably make sure I'm more specific that I'm only talking about Duratec and possibly even only 420 on my Blog. John

Hi Charles, having done some more research with the build manual wiring diagram I'm not so sure now that the rev-counter is on the CAN bus. I'll need to do some more digging around and will post back here when I find out, or someone else can chime in. John

Hi Charles, thanks for that info. I think that then makes a lot more sense if the rev-counter uses the default broadcast OBD data - what I called MBE-Broadcast in my blog posts. It was bugging me that it must be there for a reason and I had thought that perhaps the shift-lights shipped with many cars were the reason for the broadcasts to be there. But it makes sense that the rev-counter might use it. I had also thought that it might be a hang over from the days of stacked-dashes. I've updated the CAN bus post on my blog along with the MBE-Broadcast post too. If I get some time I might see if I can make sure it's the MBE-broadcast protocol that's definitely being used by the rev-counter. CAN bus is certainly not a PCM signal but should be simple enough to check what the rev-counter is doing from the wiring and maybe even do some tests with a CAN bus gateway to inject some dummy data into the rev-counter if it does indeed use CAN bus. John [ Edit: having done some more research with the build manual wiring diagram I'm not so sure now that the rev-counter is on the CAN bus. I'll need to do some more digging around and will post back here when I find out, or someone else can chime in]

If anyone's interested then I've got the bulk of the posts finished on all of this on my website here: https://www.purplemeanie.co.uk/index.php/2019/08/31/ecu-diagnostics-part-1-introduction/ If anyone finds any errors or omissions then I'll be more than happy to correct and/update. I'm still learning lots about the car's ECU and will keep posting to my blog when I find things. And as always, I'm sure you'll find my site a great cure for insomnia if you ever need one - there's over 26,000 words or write up on this ECU topic already! :-) John

Jonathan, the idea behind my wheel computer is to have the electronics on the wheel doing the display and the main processing in a Raspberry Pi sat under the dash and connected to the OBD port of the car. I toyed with the idea of having this wheel computer as a dash mounted display... but I got to thinking that the wheel would often be in the way and then it struck me that putting it on the wheel would make more sense. Once I'd built a 3D model of the wheel (and the electronics I thought I could get away with) then I thought it would probably work (I was going to say fly... but I hope it doesn't do that). I've also mocked up a few solutions using larger screens and different LED strip layouts. But I think a bigger screen would drain a battery too much and other LED options would be too bright and lower "resolution". I've built a number of these sorts of things over the years and I think it will work... battery life might be a problem but I've left room for more battery capacity in case its a problem. If it can last 6 to 8 hours then that'll be fine for what I'm thinking. A dash mounted unit would be possible though. And I might knock one up to see how that works too. I've also toyed with the idea of creating a head-up-display. The angle of a Caterham wind screen doesn't seem too conducive to a HUD but I might give that a go too at some point. I really like the one I have on my Beemer, and so that might be the ideal display. Something I prototyped a few years ago using similar technology (it's an alerting device for people who are deaf - yes people who are deaf do use phones... they use videophones! :-) ). So the idea is that the top LED array would be able to show a shift-light configuration but would also be able to scroll text/data if I wanted. The brightness of these things will need to adjust with ambient light levels and I've found that any LED array also needs a difuser in front of it... all things that'll go into the wheel-computer... along with indicator buttons and indictor self-cancelling gyro setup (yeh... I know Beemer drivers don't usually use indicators... but there are exceptions!). John

I suspect they're surprised nobody got this far already. And in fact I bet that the engine tuners out there know this stuff already but are keeping quiet. Like I said before, they weren't exactly hiding anything. If they'd have encrypted the .ec2 files or put some simple obfuscation on the connection protocol then I think we'd have struggled a bit more. John

As a teaser of things to come... here's a render of my next project to create a Steeting Wheel Computer for my car. It will connect to the CAN bus Raspberry Pi using Bluetooth and show stats and shift-lights on the steering wheel... The render shows the wheel and electronics... I'll "wrap" the electronics in a plastic case that I'll 3D print. John

Hi Jonathan, In theory, yes. If we can see all the inputs to the ECU (and I think we can) and we can see all the outputs (again, I think we can) then as we drive the car around (or perhaps more scientifically on a rolling road) we should be able to deduce the map - especially as we know how many maps there are (from the unlocked ECU maps that are around) and what format they take. ... in theory. It shouldn't be too difficult to write some software to do exactly that and test your suggestion. While Mark is working on his dashboard, I'm working on a steering-wheel-computer (more on that later). Once I'm done with that, and my blog updates, then I'll have time to do some testing. Now we have the basic code, it should also be possible for another softie to take what we've done and test your theory. BTW... if anyone needs more help with their insomnia, or found my previous posts on this thread too light weight, then I've started to write all the gorey detail out on my blog: https://www.purplemeanie.co.uk/index.php/2019/08/31/ecu-diagnostics-part-1-introduction/ John

Very cool Mark!

Hi John, I haven't tried to extract a map yet. I suspect it needs a different approach than the one we've been using to get the ECU variables. I'm also not that hopeful that we'll succeed, they are supposed to be locked after all and what we've done so far isn't anything that MBE have specifically protected against. They haven't used any encryption or subterfuge that we've had to break through, they've just used already existing protocols with a couple of twists. It wasn't as though they were hiding the info, it just took some persistence to figure out what they were doing. However, these ECUs are supposed to be locked and so I suspect won't give up a map that easily. Attempting to read a map is on the list of things to have a look at though. John

Progress report... Up until now, a lot of what we posted about the MBE ECU protocols has been a little theoretical. We've sniffed away at the packets on the canbus and we've poked and prodded at Easimap. We also wrote some simple test applications to test out our theories. But now we have a software tool to ask a standard locked MBE 9A4 to send us whatever data we want to ask it for. We've now been able to select which data parameters we want to know about and for the car to respond. We can then repeatedly ask the car for updates as often as we dare and to produce things like dashboards, data-loggers and change lights etc. I run these tools run on a Raspberry Pi at the moment but should work on any Linux system. It uses a PiCAN2 to access the canbus, but could use any SocketCAN compatible device. The code is available on GitHub for anyone to download, look at, and throw stones at, if that's what you're into. The code can be found here: https://github.com/Purplemeanie For the softies amongst you: The can-isotp repository is a modified kernel module that can knoble flow-control in the ISOTP protocol layer. The Caterham-OBD repo has the main access class (mbe.py) and a test app. There are also other support tools and files in there too. The code is still quite rough and ready, so don't be too critical of it.... it's a work in progress. So... by way of an example: I asked the car for the following EC2 data variables: RT_AIRTEMP1(LIM) RT_COOLANTTEMP1(LIM) RT_ENGINESPEED RT_BATTERYVOLTAGE(LIM) RT_SOFTCUTTIME RT_HARDCUTTIME And got the following back. As you can see, the battery needs charging and the engine wasn't running!... Air Temp RT_AIRTEMP1(LIM) 16.189669642175936 C Battery Voltage RT_BATTERYVOLTAGE(LIM) 11.815976195925842 V Coolant Temp RT_COOLANTTEMP1(LIM) 21.95635919737545 C Engine Speed RT_ENGINESPEED 0.0 RPM Hard Cut RT_HARDCUTTIME 7900.0 RPM Soft Cut RT_SOFTCUTTIME 7800.0 RPM If needed I can ask for that data repeatedly and get a continuous readout showing "real time" values for all the data points I ask for. I think we can say we have the basics now for a set of tools to be able to write whatever applications we want. Not bad progress for a few weeks tinkering. I'm just waiting for some old-hand to pop up and say they did this years ago. But what the heck, its been great fun solving the puzzle. John

Hi Toughie... I hope that's a vote of confidence in what we're doing :-) All these shenanigans are (I'm afraid) bread and butter for some of us doing this work. In the words of the slogan that was behind the Wireshark network sniffer a few years ago... we spend our working lives "Sniffing the glue that holds the internet together"! Packet analysis on an OBD canbus should be relatively simple, and certainly isn't rocket science ;-) New post coming later tonight...

First off, thanks to all those that have shown some interest in this thread, it can get a bit technical at times, so shout if you'd like me (us) to go into more detail. Or shout if you want me to stop :-) Ok, so another update. SummaryWe now understand the communications protocol used by Easimap and can use it to ask the ECU for whatever data the car has to offer. We can then manipulate the responses we get back from the car and format it to make sense to us. If you don't want the technical jargon, then skip to the bottom of the post for the Results :-) TL;DRI've got to a point now where I think we understand how Easimap is talking to the car and how it formats the data fields it gets from the car. And therefore we can just do the same to get whatever data the car has to offer. What I haven't looked at yet is how Easimap can set parameters in the car's ECU. I will take a look at that at some point but for the moment my interest is in creating some sort of Linux tool that can extract data from the car and display it. I may also have a look at whether the mappings on the ECU can be changed, though the general consensus is that the ECU's are locked, and I have no reason to change that theory at the moment. I'm not sure how that locking occurs or whether it can be circumvented. At the moment I'm not interested in that side of things and have no intention of looking at it - at least at the moment. So, to that end... here's what I understand now about what I called in the previous post the "MBE ISOTP-like" protocol used by MBE in their Easimap software and the ECU's. Firstly, this protocol is a multi-layered protocol. It's a bit like Russian Dolls, the actual data packets used by MBE are a couple of layers deep inside the doll. In order to look at the data the way that the ECU does we have to capture the data from the OBD port and then unpack it a couple of times to get at the real data. The unpacking layers in this case are CAN, ISOTP (ISO-15765) and a proprietary MBE layer. Lets dig into the various layers and explain what's going on, hopefully this will help future developers. I also intend to do a full writeup on my blog and I'm sure Mark will do the same for what he's been looking at. I'll have diagrams and code snippets there to help. Unfortunately, this L7 website is a little limited in the sorts of diagrams and files I can show you here, so my website will be a better place for a full write-up. I'll post a link when it goes live. CAN LayerThe OBD-II port (on my car (2017 420R) and most modern-ish Caterhams) connects to the ECU by way of a two wire differential voltage protocol. It uses CAN-H and CAN-L to signal 1s and 0s on the CAN bus. There are two critical things here in each CAN packet... firstly there's the CAN ID (identifier) and then there's the Data. The CAN ID can be either 11bits long or 29bits long. On my car with the MBE 9A4 ECU, it uses 29bit IDs. But other Caterhams also seem to use 11bit, probably with unlocked ECUs. Secondly, the CAN packet contains up to 8 bytes of data. The CAN standard does allow for more than 8 bytes but it doesn't seem as though our cars use that version of the protocol. Other than the ID and data the CAN packet also contains lots of start bits, CRC (cyclic redundancy check) error checking, data length parameters and an ACK section. The ACK section is perhaps worth a few words: a sending device on the network only knows if "something" has received it's CAN packet if a receiver sets the ACK bit when it received the data. Anyway, on to the more interesting stuff. The 29bit CAN IDs are used a payload type identifier - When a device sending on the bus sets a particular ID, it is telling any receiver what sort of protocol to expect in the packet. I'll talk more about the specifics of the IDs used in our cars when I get onto the ISOTP layer below. So, at a high level view of each CAN packet, there are the two things we're interested in, the CAN ID and the Data. For our cars the IDs are 29bit and the data can be up to 8 bytes. And a packet looks like this when we've captured it from the CAN bus: # Time Prot Len Info CAN ID Data 168 1.612770860 CAN 32 XTD: 0x0cbe1101 10 08 01 00 00 00 00 f8 169 1.613462515 CAN 32 XTD: 0x0cbe1101 21 7c 7d 00 00 00 00 00 170 1.614548554 CAN 32 XTD: 0x0cbe0111 03 81 34 12 00 00 00 00 This data is laid out in columns by the packet sniffing tool I'm using (Wireshark/tshark). - # = Packet Number - Time = number of seconds since the packet capture started - Prot = Protocol (CAN) - Len = Length of the capture packet. This is not the CAN data length, that's always 8 for us - CAN ID = 29bits (shown as hexadecimal in this example) - Data = Data in the CAN packet, shown as hexadecimal bytes You'll see why I picked those particular packets a bit later. So, to recap... when we put a packet sniffer (Raspberry Pi with PICAN2 interface in my case) and watch (sniff) the CAN bus, we see a succession of lines of output from our packet sniffer like above... ISOTPOk. So lets look at one level of Russian Dolls down (smaller doll). As you can see from the example above, our particular implementation of the CAN protocol allows the car and any other device on the CAN bus to talk in chunks of 8 bytes at a time. Now, this is quite restrictive for a modern car. The communication between Easimap and the car ECU might need to send all sorts of data that is longer than 8 bytes. For instance a 2 dimensional engine fueling map that might be hundreds of bytes long. The MBE ECU and Easimap get over this problem by adding another protocol on top of the CAN interface (another Russian Doll). This protocol is called ISO-15765 or ISO-TP. By formatting the data in the CAN packets we can send one ISO-TP "frame" across multiple CAN packets - allowing us to send more than 8 bytes in a frame. Here's the same 3 CAN packets from above, but this time we looking at it through an ISO-TP dissector (its dissecting the packet stream and viewing it as though it is formatted in accordance with the ISO-TP protocol). # Time Proto Len Info Data 168 1.612770860 ISO15765 32 First Frame(Frame Len: 8) 01 00 00 00 00 f8 169 1.613462515 ISO15765 32 Consecutive Frame(Seq: 1) 7c 7d 170 1.614548554 ISO15765 32 Single Frame(Len: 3) 81 34 12 Packets 168 and 169 are actually a single ISO-TP frame. The "First Frame" and the "Consecutive Frame" are "fragments" of a whole frame and can be joined together to form an ISO-TP frame with the following data: 01 00 00 00 00 f8 7c 7d The "Frame Len: 8" in the First Frame tells us there are 8 bytes of data at the ISO-TP protocol layer. Now, you might say... but hang on, we could send 8 bytes of data with just CAN frames. Well, that's true in this particular example but for more complex examples we can send over 4000 bytes of data in a single ISO-TP frame (using many CAN packets). One significant departure that MBE seem to make from the ISO-TP standard is that they do not implement flow-control in the protocol. We don't need to go into that here, but if anyone is trying to talk to an MBE ECU using their own software, then they'll need to remove any notion of flow control from the ISO-TP layer they use. At least that's my current theory - and it seems to be stacking up. Right, so now we've used up two layers of the Russian Doll. The CAN layer and the ISO-TP layer. In the third layer (I'll call it the MBE layer) we see exactly what the ECU and Easimap are really saying to each other. MBE LayerThe data we extracted using the ISO-TP dissector has given us the following (same as above): 01 00 00 00 00 f8 7c 7d What does that mean to the ECU? Well, this took a bit of figuring out. We don't have MBE's complete rule-book for decoding this layer of the communications. But what we do have is their Easimap software. That helps us in two ways. Firstly, we can watch Easimap and the ECU talking to each other. That's how we got these sample packets. But that just looks like random data at the moment. Secondly, we have the EC2 data files that Easimap loads when it discovers what ECU its talking to. MBE supports a whole raft of ECU's and each seems to communicate with Easimap in a different way. MBE could have coded each of those protocols into Easimap but that would mean that they needed to update the Easimap software whenever they make a new ECU for a customer (Caterham or whoever). So, MBE wrote Easimap to discover what ECU its talking to and then load the correct EC2 file for that ECU. Fortunately for us the EC2 files are easily found in the Easimap installation. A Digression into EC2 filesThe EC2 files are worth a whole post in themselves. And we had to write scripts to decode them and give us the keys to unlock the MBE layer. In simple terms though, the EC2 files set up a lot of "variables". Each variable is a type of data that Easimap can extract from the ECU. The 9A4 EC2 file that Easimap uses for our cars has over 2000 variables defined. It turns out that over half of them are "disabled" but that still leaves over 900 to work with. I suspect that many of these 900 don't actually do anything with our cars but I'm planning to got and check which are "active" and which are not. For each variable in the EC2 file there a definitions for things like, the number of bytes of data each variable takes up in the MBE communications layer, the short and long description of the variable that Easimap uses when showing the data on the screen and crucially it also has entries for what it calls a "page" and an "address". This information for each variable is spread all over the EC2 file and the scripts we wrote had to find each variable and pull the respective information together to build a picture of how each variable works. {'address': '0x237c', 'bytes': '2', 'display_interval': '1000.000000', 'display_maximum': '12000.000000', 'display_minimum': '0.000000', 'long_desc': ' Engine Speed in rpm as measured by the crankshaft sensor. This ' 'is the primary input for the fuel and ignition maps', 'name': 'RT_ENGINESPEED', 'page': '0xf8', 'scale_maximum': '65535.000000', 'scale_minimum': '0.000000', 'short_desc': ' Engine Speed', 'units': 'RPM'} [ You can read the info as address=237c etc. ] Once we'd decoded the EC2 file we could start to try and guess on the protocol used in this MBE layer. Back to the MBE LayerI picked all this example data and info for a reason. I had suspected ever since looking at the EC2 files for the first time a few weeks ago that the page and address info was important. And I had one of thos Eureka moments when I looked at the output of the ISO-TP layer and realized from: 01 00 00 00 00 f8 7c 7d The f8 looked like a page from the EC2 file (see 'page' : '0xf8' above) and the 7c looked like part of the address. So, I went away and hand decoded a bunch of messages from the ECU and low and behold it seemed to match up. So page=f8 and address Low-Byte (the 7c bit of the address) meant RT_ENGINESPEED - the engine RPMs. The next thing was to figure out what the rest of the packet means. And so I wrote a bunch more code and started to test out my theories. After the [01 00 00 00 00 f8 7c 7d] message is sent by Easimap, the ECU responds with: 81 34 12 One of the ways that we saw both CAN and ISO-TP communicate was to send a "command" in the first byte of the packet/frame. And for the response to have a similar format but with one or more other bits in the response byte being set. So, it seemed to make sense that the initial 01 byte in the frame from Easimap was responded to by the ECU with a response byte of 81 (81 in hexadecimal is 01 with the top bit set). This was starting to add up and so the request [01 .... 7d] was a data request for RT_ENGINESPEED and the ECU responded with 3412 (after the 81). Now I've connived to make the data here readable. When I was first testing I didn't have the car running and so the ECU was responding with 81 00 00... meaning 0 RPM. But when I started up the car the responses turned into real engine rev data. Turns out that the [34 12] is sent in reverse order and the bytes need to be swapped, making the engine revs 0x1234, which in decimal are 4660. That's revving the car a little highly in a test, but you can see how the data works. Addresses are WeirdOne of the complications around access to the ECU seems to be some weird mapping going on between the EC2 file and the address requests going to the ECU. For instance, if we take our RT_ENGINESPEED variable then the EC2 address is 0x237c. But what Easimap sends to the ECU is a request for two bytes, a Lowest Significant Byte (LSB) and a Most Significant Byte (MSB) or 0x7c and 0x7d i our RT_ENGINESPEED example. Having tried this out with a few dozen different variables it seems that Easimap takes the LSB of the Easimap address (0x7c in this example) and increments (adds one) for each extra byte it wants from the ECU. Easimap sometimes asks for 4-byte data and so this incrementing can be seen here, for example, with RT_ENGINERUNTIME... This is the variable info for RT_ENGINERUNTIME {'address': '0xcfcecdcc', 'bytes': '4', 'display_interval': '10000.000000', 'display_maximum': '1193046.500000', 'display_minimum': '0.000000', 'long_desc': ' Engine Run Time', 'name': 'RT_ENGINERUNTIME', 'page': '0xe2', 'scale_maximum': '1250999.875000', 'scale_minimum': '0.000000', 'short_desc': ' ERT', 'units': 'Hours'} RT_ENGINERUNTIME=3.9094e+04 Hours ( ERT ) [0x07ffffff=134217727, Scale:1250999.875, Div:4294967295, Offset:0.0] But that's a bit weird too, because the EC2 address ('0xcfcecdcc') is the actual series of requests sent to the ECU. I'm a little baffled at the moment about when Easimap uses the EC2 address and when it makes one up. I suspect there are rules depending on how many bytes are being asked for. Compound Data RequestsLets talk about another twist to the tale. In order that Easimap can talk to the ECU in an as-efficient way as possible. It batches up requests to pages inside the ECU and asks for a bunch of data results in one go. A request and response will therefore look like this at the CAN layer: 46 0.353164720 CAN 32 XTD: 0x0cbe1101 10 23 01 00 00 00 00 f8 47 0.353978868 CAN 32 XTD: 0x0cbe1101 21 30 31 36 37 44 45 4c 48 0.354710862 CAN 32 XTD: 0x0cbe1101 22 4d 4e 4f 50 51 5a 5b 49 0.355482989 CAN 32 XTD: 0x0cbe1101 23 5c 5d 64 6a 6b 7c 7d 50 0.356219206 CAN 32 XTD: 0x0cbe1101 24 9e 9f a0 a1 d8 d9 da 51 0.356950718 CAN 32 XTD: 0x0cbe1101 25 db 9f a0 a1 d8 d9 da 52 0.358137040 CAN 32 XTD: 0x0cbe0111 10 1e 81 4e 39 c7 47 e0 53 0.358462988 CAN 32 XTD: 0x0cbe0111 21 54 d4 83 3a 85 4e 39 54 0.358805252 CAN 32 XTD: 0x0cbe0111 22 a8 0d a2 a0 00 b0 4f 55 0.359140831 CAN 32 XTD: 0x0cbe0111 23 00 00 7a 9c 68 08 00 56 0.359467705 CAN 32 XTD: 0x0cbe0111 24 80 00 80 a1 d8 d9 da Which then looks like this at the ISO-15765 layer: 46 0.353164720 ISO15765 32 First Frame(Frame Len: 35) 01 00 00 00 00 f8 47 0.353978868 ISO15765 32 Consecutive Frame(Seq: 1) 30 31 36 37 44 45 4c 48 0.354710862 ISO15765 32 Consecutive Frame(Seq: 2) 4d 4e 4f 50 51 5a 5b 49 0.355482989 ISO15765 32 Consecutive Frame(Seq: 3) 5c 5d 64 6a 6b 7c 7d 50 0.356219206 ISO15765 32 Consecutive Frame(Seq: 4) 9e 9f a0 a1 d8 d9 da 51 0.356950718 ISO15765 32 Consecutive Frame(Seq: 5) db 9f a0 a1 d8 d9 da 52 0.358137040 ISO15765 32 First Frame(Frame Len: 30) 81 4e 39 c7 47 e0 53 0.358462988 ISO15765 32 Consecutive Frame(Seq: 1) 54 d4 83 3a 85 4e 39 54 0.358805252 ISO15765 32 Consecutive Frame(Seq: 2) a8 0d a2 a0 00 b0 4f 55 0.359140831 ISO15765 32 Consecutive Frame(Seq: 3) 00 00 7a 9c 68 08 00 56 0.359467705 ISO15765 32 Consecutive Frame(Seq: 4) 80 00 80 a1 d8 d9 da Which is a request like this at the MBE layer: 01 00 00 00 00 f8 30 31 36 37 44 45 4c 4d 4e 4f 50 51 5a 5b 5c 5d 64 6a 6b 7c 7d 9e 9f a0 a1 d8 d9 da db Followed by a response of this: 81 4e 39 c7 47 e0 54 d4 83 3a 85 4e 39 a8 0d a2 a0 00 b0 4f 00 00 7a 9c 68 08 00 80 00 80 Or once the MBE layer is decoded it's a request for: This is a command request for data in page: f8 ... [{'bytes': '2', 'name': 'RT_THROTTLEANGLE1(RAW)'}, {'bytes': '2', 'name': 'RT_AIRTEMP1(LIM)'}, {'bytes': '2', 'name': 'RT_COOLANTTEMP1(LIM)'}, {'bytes': '2', 'name': 'RT_COOLANTFUELFACTOR'}, {'bytes': '2', 'name': 'RT_AIRTEMPFUELFACTOR'}, {'bytes': '2', 'name': 'RT_THROTTLEANGLEINCREASING'}, {'bytes': '2', 'name': 'RT_TPSFUEL+TRIMBANK1'}, {'bytes': '2', 'name': 'RT_TPSVSSPEEDIGN+TRIM1'}, {'bytes': '1', 'name': 'RT_THROTTLESITE1'}, {'bytes': '2', 'name': 'RT_BAROSCALEDLIM'}, {'bytes': '2', 'name': 'RT_ENGINESPEED'}, {'bytes': '2', 'name': 'RT_BATTERYVOLTAGE(LIM)'}, {'bytes': '2', 'name': 'RT_BATTERYVOLTAGECOMP'}, {'bytes': '2', 'name': 'RT_MAPPINGPOT1LIM'}, {'bytes': '2', 'name': 'RT_MAPPINGPOT2LIM'}] and a response with these values: RT_THROTTLEANGLE1(RAW)=1.1192 V ( Throttle Angle 1 (Raw) ) [0x394e=14670, Scale:5.0, Div:65535, Offset:0.0] RT_AIRTEMP1(LIM)=14.862 ( Air Temp ) [0x47c7=18375, Scale:160.0, Div:65535, Offset:-30.0] RT_COOLANTTEMP1(LIM)=23.048 ( Coolant Temp ) [0x54e0=21728, Scale:160.0, Div:65535, Offset:-30.0] RT_COOLANTFUELFACTOR=105.98 ( Coolant Fuel Factor ) [0x83d4=33748, Scale:400.0, Div:65535, Offset:-1e+02] RT_AIRTEMPFUELFACTOR=4.0848 ( Air Temp Fuel Factor ) [0x853a=34106, Scale:200.0, Div:65535, Offset:-1e+02] RT_THROTTLEANGLEINCREASING=1.1192 V ( Throttle Angle Increasing ) [0x394e=14670, Scale:5.0, Div:65535, Offset:0.0] RT_TPSFUEL+TRIMBANK1=5.6013 ms ( TPS Fuel + Trim ) [0x0da8=3496, Scale:105.0, Div:65535, Offset:0.0] RT_TPSVSSPEEDIGN+TRIM1=4.7022 ( TPS vs Speed Ign + Trim ) [0xa0a2=41122, Scale:-120.0, Div:65535, Offset:80.0] RT_THROTTLESITE1=0.0 Site ( Throttle Site 1 ) [0x00=0, Scale:16.0, Div:255, Offset:0.0] RT_BAROSCALEDLIM=1.04 Bar ( Baro Pressure ) [0x4fb0=20400, Scale:6.5535, Div:65535, Offset:-1.0] RT_ENGINESPEED=0.0 RPM ( Engine Speed ) [0x0000=0, Scale:65535.0, Div:65535, Offset:0.0] RT_BATTERYVOLTAGE(LIM)=12.225 V ( Battery Voltage ) [0x9c7a=40058, Scale:20.0, Div:65535, Offset:0.0] RT_BATTERYVOLTAGECOMP=0.43116 ms ( Battery Voltage Comp ) [0x0868=2152, Scale:13.13, Div:65535, Offset:0.0] RT_MAPPINGPOT1LIM=0.0015259 ( Mapping Pot 1 ) [0x8000=32768, Scale:200.0, Div:65535, Offset:-1e+02] RT_MAPPINGPOT2LIM=0.0015259 ( Mapping Pot 2 ) [0x8000=32768, Scale:200.0, Div:65535, Offset:-1e+02] All that done in one ISO-TP request frame and one response frame. ResultsMost of the variables have scale and offset factors that have to be applied, but initial results give the following for the default Easimap screen... RT_CURRENTFAULTSB=3.2769e+04 - ( Current Faults B ) [0x8001=32769, Scale:65535.0, Div:65535, Offset:0.0] RT_ENGINE_CONFIG=176.0 - ( Eng Cnfg ) [0xb0=176, Scale:255.0, Div:255, Offset:0.0] RT_MEMORYCONFIG=64.0 - ( Memory Configuration ) [0x40=64, Scale:255.0, Div:255, Offset:0.0] RT_IGNITIONADVANCEBANK1=23.691 ( Ignition Advance ) [0x7820=30752, Scale:-120.0, Div:65535, Offset:80.0] RT_BAROFUELCOMP=3.5294 ( Barometric Pressure Fuel Compensation ) [0x84=132, Scale:200.0, Div:255, Offset:-1e+02] RT_CRANKCOUNT=463.0 - ( Crank Count ) [0x01cf=463, Scale:65535.0, Div:65535, Offset:0.0] RT_ENGINERUNTIME=3.9094e+04 Hours ( ERT ) [0x07ffffff=134217727, Scale:1250999.875, Div:4294967295, Offset:0.0] RT_THROTTLEANGLE1(RAW)=1.5767 V ( Throttle Angle 1 (Raw) ) [0x50ba=20666, Scale:5.0, Div:65535, Offset:0.0] RT_AIRTEMP1(LIM)=14.615 ( Air Temp ) [0x4762=18274, Scale:160.0, Div:65535, Offset:-30.0] RT_COOLANTTEMP1(LIM)=23.121 ( Coolant Temp ) [0x54fe=21758, Scale:160.0, Div:65535, Offset:-30.0] RT_COOLANTFUELFACTOR=22.719 ( Coolant Fuel Factor ) [0x4e8a=20106, Scale:400.0, Div:65535, Offset:-1e+02] RT_AIRTEMPFUELFACTOR=4.0848 ( Air Temp Fuel Factor ) [0x853a=34106, Scale:200.0, Div:65535, Offset:-1e+02] RT_THROTTLEANGLEINCREASING=1.5767 V ( Throttle Angle Increasing ) [0x50ba=20666, Scale:5.0, Div:65535, Offset:0.0] RT_TPSFUEL+TRIMBANK1=4.5887 ms ( TPS Fuel + Trim ) [0x0b30=2864, Scale:105.0, Div:65535, Offset:0.0] RT_TPSVSSPEEDIGN+TRIM1=24.32 ( TPS vs Speed Ign + Trim ) [0x76c8=30408, Scale:-120.0, Div:65535, Offset:80.0] RT_THROTTLESITE1=8.2824 Site ( Throttle Site 1 ) [0x84=132, Scale:16.0, Div:255, Offset:0.0] RT_BAROSCALEDLIM=1.04 Bar ( Baro Pressure ) [0x4fb0=20400, Scale:6.5535, Div:65535, Offset:-1.0] RT_ENGINESPEED=2400.0 RPM ( Engine Speed ) [0x0960=2400, Scale:65535.0, Div:65535, Offset:0.0] RT_BATTERYVOLTAGE(LIM)=13.087 V ( Battery Voltage ) [0xa782=42882, Scale:20.0, Div:65535, Offset:0.0] RT_BATTERYVOLTAGECOMP=0.33138 ms ( Battery Voltage Comp ) [0x0676=1654, Scale:13.13, Div:65535, Offset:0.0] RT_MAPPINGPOT1LIM=0.0015259 ( Mapping Pot 1 ) [0x8000=32768, Scale:200.0, Div:65535, Offset:-1e+02] RT_MAPPINGPOT2LIM=0.0015259 ( Mapping Pot 2 ) [0x8000=32768, Scale:200.0, Div:65535, Offset:-1e+02] RT_SOFTCUTTIME=7800.0 RPM ( Soft Cut ) [0x1e78=7800, Scale:65535.0, Div:65535, Offset:0.0] RT_HARDCUTTIME=7900.0 RPM ( Hard Cut ) [0x1edc=7900, Scale:65535.0, Div:65535, Offset:0.0] RT_INJECTIONTIMEA=7.2051 ms ( Final Injection Time ) [0x1191=4497, Scale:105.0, Div:65535, Offset:0.0] RT_DUTYCYCLEA=14.51 ( Duty Cycle ) [0x25=37, Scale:100.0, Div:255, Offset:0.0] RT_HAVESPEEDS=169.0 - ( RT_HAVESPEEDS ) [0x00a9=169, Scale:65535.0, Div:65535, Offset:0.0] Some of this still isn't making sense but most of it seems to. I hope that's been at least somewhat informative for people. Feels like I should do a lecture course on the subject [ and really put you all to sleep ] :-) John

Another Progress Report: We (CTRMint, Aerobod and myself) have made some good progress since the last update. Our work is with the 9A4 MBE ECU and the car's OBD connector with the following working assumptions: There are three protocols used by the ECUs A Broadcast Protocol with limited information that outputs about every 100ms. OBD-II standard protocol that is a request/repsonse protocol based around 29bit CANbus IDs Easimap ISOTP-like protocol that is a request/response protocol using 29bit CANBus IDs and a modified ISOTP (ISO-15765) protocol Broadcast Protocol There are a few CANbus messages broadcast by the ECU's using a CAN ID of 0x0cbb0001. These messages are sent as soon as the car is put into ignition position 2. There are probably some useful data entries in these messages but there's not a lot there so we haven't concentrated on that yet. OBD-II Protocol The MBE ECU's support the standard OBD-II protocol. You can send the ECU OBD-II data requests and the ECU will respond. We've seen this protocol being used by OBD scanners and it mostly makes sense. We've been using the Wireshark packet sniffer to decode the OBD-II protocol and have submitted a code patch to Wireshark.org to allow Wireshark to decode the 29bit CAN IDs, modes and PIDs that the MBE ECUs use. This patch has now been accepted and should hopefully appear in the next release of Wireshark. EasiMap ISOTP-like Protocol The third protocol is probably the most interesting and where we have spent the most of our time. This protocol is used by Easimap 6 to communicate with the ECUs and has a lot more data variables than either of the other two protocols. This protocol is also a request/response protocol where a querying device (Easimap with MBE 985, or some other CANbus tool like a Raspberry Pi with a PICAN2 HAT) sends a command to the ECU and the ECU responds with the data. We've found that on top of the CANbus protocol, the ECU's add ISOTP packetisation. This allows the ECUs to communicate in larger than 8 byte frames. At the lowest level 8 byte packets are sent but with ISOTP on top it can bunch up multiple 8 byte packets into ISOTP frames - allowing larger transmission chuncks to/from the application layer to the car. I've called this a "ISOTP-like" protocol because it uses the packet structure of ISOTP but critically seems to omit the use of FlowControl. So, we've had to modify some standard Python libraries to be able to talk to the car. We haven't made a whole lot of communications to our cars yet, but we have sent commands to the cars and got responses for things like Serial Number, Engine RPM and Coolant Temp. On top of the ISOTP protocol the ECUs are adding another control layer. We don't completely understand this layer at the moment but we are able to "hard code" some commands and then get responses. We have seen a couple of these commands so far, one that asks the car for its serial number and another that asks for data back from the car. The second of these commands is also interesting in that it can ask for multiple data items back from the car at once. It can ask for single items but it can also ask for multiple items and so make the communication on the bus much more efficient. In parallel with this work around the commands, we've also spent a lot of time trying to figure out what each data request means and what the respective results are - how the data is placed in the response, how it is scaled and what its ranges are. To that end we've decoded the Easimap EC2 file used for our ECUs (9A4be52a.ec2). As a result we have a Python tool now that can take an EC2 file and extract the communication protocol used by Easimap and store it in a form that we can now write software against (we have it in csv, json and python formats). Here's an example of the configuration for engine rpm... { "name" = "RT_ENGINESPEED". "page" = "0xF8". "address" = "0x237C". "bytes" = "2". "scale_minimum" = "0.000000". "scale_maximum" = "65535.000000". "display_minimum" = "0.000000". "display_maximum" = "12000.000000". "display_interval" = "1000.000000". "units" = "RPM". "short_desc" = " Engine Speed". "long_desc" = " Engine Speed in rpm as measured by the crankshaft sensor. This is the primary input for the fuel and ignition maps" } The page and address fields above are used to create the "request for data" commands and then the remainder of the configuration tells us how to interpret the results. The "bytes" field tells us how many bytes of data will come back from the car. If anyone is interested to know more then please contact CtrMint to join our Slack workspace or DM me and I can send more info. The Slack channel has all the source code and output files that we've been working on. I must stress that this is all a work-in-progress. Any of this information may change... though we think (hope) we are on the right track. I hope that's vaguely interesting to a few of you. More to come over the next few days/weeks... and there will be a full write-up, source code and sample files available on the subject at some point. John, Mark and James.

Progress Report: Mark and I haven't given up on this project (yet)! We've been setting up test systems and figuring out what's what on the OBD port. It's clear that the MBE 9A4 ECU's use a couple of different protocols on that port. There's an MBE specific protocol that's used by Easimap to talk to the car, and there's OBD-II. In order to decode the OBD traffic I had been using the Wireshark packet sniffer. Wireshark has recently updated its support for OBD and it can now decode 11bit CAN OBD IDs. However, it struggled (that's software speak for: it didn't) when we tried to get it to decode the 29bit codes used on our MBE ECUs. So, to get that fixed I've worked this week on getting Wireshark patched for our OBD 29bit protocols and have now submitted a patch to allow Wireshark to correctly dissect our OBD port. Here's a screen shot of what the OBD protocol now looks like with my patch in Wireshark: The patch is here: https://code.wireshark.org/review/#/c/34297/ This is my first Wireshark commit so I'm not quite sure how the process runs for getting it into the regular Wireshark releases, but hopefully it won't take too long. If anyone's interested, Wireshark can be downloaded from here (obviously doesn't contain my patch yet): http://wireshark.org The next step is to try and decode the MBE Easimap protocol. Mark and I have made some good progress on this but we're still a long way from having it cracked. More to follow over the coming days/weeks... John