{"id":5008,"date":"2019-09-15T14:42:15","date_gmt":"2019-09-15T13:42:15","guid":{"rendered":"https:\/\/www.purplemeanie.co.uk\/?p=5008"},"modified":"2025-01-31T13:08:42","modified_gmt":"2025-01-31T13:08:42","slug":"ecu-diagnostics-part-8-easimap-uses-isotp","status":"publish","type":"post","link":"https:\/\/purplemeanie.co.uk\/index.php\/2019\/09\/15\/ecu-diagnostics-part-8-easimap-uses-isotp\/","title":{"rendered":"ECU Diagnostics &#8211; part 8 : Easimap uses ISOTP (sort of)"},"content":{"rendered":"\n<p>Ok, that&#8217;s enough of the theory about mapping. Lets get back to what Easimap is doing when it talks to the car.<\/p>\n\n\n\n<p>When we left this subject last we had got to the point where we could see what Easimap was sending and receiving on the CAN bus, but we didn&#8217;t know what it meant. We had seen a set of startup packets like this:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">#  Time        ID         Data\n28 0.265548270 0x0cbe1101 03 04 00 0d 26 40 42 43\n29 0.266543253 0x0cbe0111 10 0d e4 00 0d 23 39 41\n30 0.266872637 0x0cbe0111 21 34 62 65 35 33 30 00\n37 0.326052544 0x0cbe1101 03 04 00 5e 26 40 42 43\n38 0.327045620 0x0cbe0111 07 e4 00 5e 2b 07 01 00<\/pre>\n\n\n\n<p>Then we get this set of 31 packets that repeat continually but with small changes (probably the &#8220;real&#8221; data from the ECU):<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">#   Time        ID         Data\n80  0.736160089 0x0cbe1101 10 0a 01 00 00 00 00 12\n81  0.736958836 0x0cbe1101 21 66 67 a8 a9 00 00 12\n82  0.738230722 0x0cbe0111 05 81 aa aa 16 00 12 66\n84  0.749027454 0x0cbe1101 10 09 01 00 00 00 00 1a\n85  0.749733313 0x0cbe1101 21 52 5c 5d 00 00 00 1a\n86  0.750875498 0x0cbe0111 04 81 84 00 00 00 1a 52\n89  0.767924313 0x0cbe1101 10 0a 01 00 00 00 00 e2\n90  0.768777632 0x0cbe1101 21 cc cd ce cf 00 00 e2\n91  0.769825875 0x0cbe0111 05 81 ff ff ff 07 e2 cc\n93  0.780880102 0x0cbe1101 10 23 01 00 00 00 00 f8\n95  0.781565869 0x0cbe1101 21 30 31 36 37 44 45 4c\n96  0.782301116 0x0cbe1101 22 4d 4e 4f 50 51 5a 5b\n97  0.783061863 0x0cbe1101 23 5c 5d 64 6a 6b 7c 7d\n98  0.783818702 0x0cbe1101 24 9e 9f a0 a1 d8 d9 da\n99  0.784526524 0x0cbe1101 25 db 9f a0 a1 d8 d9 da\n100 0.785768596 0x0cbe0111 10 1e 81 5e 39 cc 48 dc\n101 0.786095776 0x0cbe0111 21 50 9c 89 1e 85 5e 39\n102 0.786437863 0x0cbe0111 22 a8 0d 66 a0 00 b0 4f\n103 0.786777913 0x0cbe0111 23 00 00 56 95 80 09 00\n104 0.787102630 0x0cbe0111 24 80 00 80 a1 d8 d9 da\n106 0.798260523 0x0cbe1101 10 0a 01 00 00 00 00 f9\n107 0.799080454 0x0cbe1101 21 ba bb bc bd 00 00 f9\n108 0.800070197 0x0cbe0111 05 81 78 1e dc 1e f9 ba\n110 0.810033090 0x0cbe1101 10 09 01 00 00 00 00 fa\n111 0.810853632 0x0cbe1101 21 64 65 6c 00 00 00 fa\n113 0.812042780 0x0cbe0111 04 81 8c 1e 00 00 fa 64\n115 0.821498922 0x0cbe1101 10 0e 01 00 00 00 00 fd\n116 0.822377593 0x0cbe1101 21 20 24 25 26 40 42 43\n117 0.823099192 0x0cbe1101 22 4d 24 25 26 40 42 43\n118 0.824343987 0x0cbe0111 10 09 81 40 00 00 01 80\n119 0.824665352 0x0cbe0111 21 b0 40 40 26 40 42 43<\/pre>\n\n\n\n<p>We&#8217;ve also seen that I&#8217;d had a diversion <a href=\"https:\/\/www.purplemeanie.co.uk\/index.php\/2019\/09\/07\/ecu-diagnostics-part-5-the-correlator-dead-end\/\">looking for bit-shifted pages and addresses<\/a>&nbsp;which got us nowhere.<\/p>\n\n\n\n<p>Lets get back to Wireshark again&#8230;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Wireshark Sub Dissectors<\/h3>\n\n\n\n<p>I&#8217;d played around with a lot of the CAN bus packet captures we&#8217;d taken from Easimap talking to our ECUs and I&#8217;d taken a bit of a diversion to fix Wireshark&#8217;s OBD-II dissector. I&#8217;d also spent time trying to see if Wireshark could dig deeper into the packets with it&#8217;s sub-dissectors.<\/p>\n\n\n\n<p>Wireshark works by iterative dissection &#8211; meaning that it decodes a packet then passes that packet on to further dissectors, called sub-dissectors, to see if they can further decode the packet. So, Wireshark&#8217;s CAN dissector defines further sub-dissectors for these protocols:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>OBD-II (which I&#8217;ve talked about before)<\/li><li>ISO 15765<\/li><li>CanOpen<\/li><li>DeviceNet<\/li><li>J1939<\/li><li>ISOBUS<\/li><li>AUTOSAR NM<\/li><\/ul>\n\n\n\n<p>I thought I had tried to decode our Easimap stream with all of them before, but after coming up blank with my <a href=\"https:\/\/www.purplemeanie.co.uk\/index.php\/2019\/09\/07\/ecu-diagnostics-part-5-the-correlator-dead-end\/\">correlator<\/a> and having read the <a href=\"https:\/\/www.purplemeanie.co.uk\/index.php\/2019\/09\/07\/ecu-diagnostics-part-6-reading-material\/\">Car Hacker&#8217;s Handbook<\/a>, I thought I&#8217;d have another go. The Car Hacker&#8217;s Handbook talks about car manufacturers using proprietary protocols on their CAN bus implementations but it also talks about progress in standardising some of the protocols used.<\/p>\n\n\n\n<p>And&#8230; low and behold&#8230; when I selected the ISO 15765 sub-dissector to decode our Easimap communications, it was showing some promise. Once I&#8217;d issolated just the Easimap traffic then it looked something like this:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">[ 2] ISOTP OTHER_REQUEST :04000d\n[ 4] ISOTP OTHER_RESPONSE :e4000d23394134626535333000\n[ 5] ISOTP OTHER_REQUEST :04005e\n[ 6] ISOTP OTHER_RESPONSE :e4005e2b070100\n[ 8] ISOTP REQUEST :0100000000126667a8a9\n[ 9] ISOTP RESPONSE :81aaaa1600\n[11] ISOTP REQUEST :01000000001a525c5d\n[12] ISOTP RESPONSE :81840000\n[14] ISOTP REQUEST :0100000000e2cccdcecf\n[15] ISOTP RESPONSE :81ffffff07\n[21] ISOTP REQUEST :0100000000f83031363744454c4d4e4f50515a5b5c5d646a6b7c7d9e9fa0a1d8d9dadb\n[26] ISOTP RESPONSE :814e39094a9c52b886e8844e39a80d70a000b04f00005695800900800080\n[28] ISOTP REQUEST :0100000000f9babbbcbd\n[29] ISOTP RESPONSE :81781edc1e\n[31] ISOTP REQUEST :0100000000fa64656c\n[32] ISOTP RESPONSE :81ef1d00\n[35] ISOTP REQUEST :0100000000fd202425264042434d\n[37] ISOTP RESPONSE :814000000180b04040<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">ISOTP Basics<\/h3>\n\n\n\n<p>Ok. Lets step back a bit here. More info on ISOTP (ISO 15765-2) can be found <a href=\"https:\/\/en.wikipedia.org\/wiki\/ISO_15765-2\">here<\/a>. It defines a bunch of packet types that can be used to extend the regular CANbus communications from packets of 8 up to packets with a total of 4095 bytes. To do that it steals the first byte or two (depending on the message type) to say what ISOTP packet type this is, and to tell us how long (in bytes) the packet is.<\/p>\n\n\n\n<p>Those first two bytes are described as follows:<\/p>\n\n\n\n<figure class=\"wp-block-image alignnone is-style-default\"><a href=\"https:\/\/www.purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/CANBus-Header-Diagram.png\"><img loading=\"lazy\" decoding=\"async\" width=\"1052\" height=\"210\" data-attachment-id=\"5025\" data-permalink=\"https:\/\/purplemeanie.co.uk\/index.php\/2019\/09\/15\/ecu-diagnostics-part-8-easimap-uses-isotp\/canbus-header-diagram\/\" data-orig-file=\"https:\/\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/CANBus-Header-Diagram.png\" data-orig-size=\"1052,210\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}\" data-image-title=\"CANBus Header Diagram\" data-image-description=\"\" data-image-caption=\"\" data-large-file=\"https:\/\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/CANBus-Header-Diagram.png\" src=\"https:\/\/www.purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/CANBus-Header-Diagram.png\" alt=\"\" class=\"wp-image-5025\" srcset=\"https:\/\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/CANBus-Header-Diagram.png 1052w, https:\/\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/CANBus-Header-Diagram-600x120.png 600w, https:\/\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/CANBus-Header-Diagram-768x153.png 768w\" sizes=\"auto, (max-width: 1052px) 100vw, 1052px\" \/><\/a><figcaption>Table of ISOTP Message Types and Bit Patterns<\/figcaption><\/figure>\n\n\n\n<p>For those wanting some help with what that means:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>The top 4 bits (7..4) of byte zero define the message type as follows:\n<ul>\n<li>0 = &#8220;Single&#8221; Byte Message<\/li>\n<li>1 = &#8220;First&#8221; byte of a multi-byte message<\/li>\n<li>2 = a &#8220;Consecutive&#8221; byte sent after a &#8220;First&#8221; byte<\/li>\n<li>3 = &#8220;Flow&#8221; Control message<\/li>\n<\/ul>\n<\/li><li>The bottom 4 bits of byte zero change their meaning depending on which message type is being sent<\/li><li>If data is being sent (anything other than a flow control message) then the data starts in either byte 1 or byte 2 and continues for &#8220;size&#8221; bytes<\/li><\/ul>\n\n\n\n<p>Lets look at an example of what that means&#8230;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">ISOTP Example Transmission<\/h3>\n\n\n\n<p>From the CAN bus packets shown at the top of this post, we have the first packet viewed as a CAN bus packet as follows:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">#  Time        ID         Data\n28 0.265548270 0x0cbe1101 03 04 00 0d 26 40 42 43<\/pre>\n\n\n\n<p>So the data part of that is:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">03 04 00 0d 26 40 42 43<\/pre>\n\n\n\n<p>If we look at the top 4 bits (0x0) of the first byte (0x03), we can see that we have a message type of &#8216;0&#8217;. And from the table above message type &#8216;0&#8217; means we are sending one CAN bus frame and the bottom 4 bits of byte 0 tell us how many data bytes we have in this frame, which is 3.<\/p>\n\n\n\n<p>So, even though there were 8 bytes sent on the CAN bus, only the first byte (0x03) and the subsequent 3 bytes (0x04, 0x00, 0x0d) are of any use. The last 4 bytes (0x26, 0x40, 0x42, 0x43) are junk. In some implementations of ISOTP the devices on the CAN bus would insert &#8220;padding&#8221; where these junk bytes are here, and we might see them as 0x00 or 0xff or 0xaa, or some other constant but essentially useless data.<\/p>\n\n\n\n<p>In theory Easimap and the ECU don&#8217;t need to send these junk or padding bytes. And in my experiments the ECU&#8217;s are happy to be sent them or not.<\/p>\n\n\n\n<p>That&#8217;s decoding the CAN bus packet and interpreting it as ISOTP.<\/p>\n\n\n\n<p>I also wrote some <a href=\"https:\/\/github.com\/Purplemeanie\/Caterham-OBD\/blob\/master\/tools\/mbepcap2txt.py\">Python code<\/a> to decode and display ISOTP packets and it shows us the output of this single CAN bus frame as this:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">[ 2] ISOTP OTHER_REQUEST :04000d<\/pre>\n\n\n\n<p>Which matches up with our manual decoding of that packet, the data is 0x04, 0x00, 0x0d.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">But There&#8217;s a Twist &#8211; No Flow-Control<\/h3>\n\n\n\n<p>As you can see from the &#8220;Table of ISTOP Messages and Bit Patterns&#8221; above, there&#8217;s a flow-control message type defined&#8230; but I&#8217;ve not shown any flow-control messages so far.<\/p>\n\n\n\n<p>ISOTP is a simple protocol, buts also not just a few lines of code to write the software for. I&#8217;d anticipated using a Python compatible library to decode this layer and didn&#8217;t really want to write my own.<\/p>\n\n\n\n<p>However, flow-control is an implicit part of the ISOTP protocol and any the libraries I looked at had it intrinsic to the code.<\/p>\n\n\n\n<p>I looked at two ways of doing ISOTP. Both were using the Python-CAN-ISOTP library. And this can either implement ISOTP in user space (meaning it is written in Python, communicates with SocketCAN directly, and is not a kernel module) or it can sit as a thin &#8220;wrapper&#8221; for the can-isotp kernel module.<\/p>\n\n\n\n<p>I looked at hacking the user space Python version of python-can-isotp but decided that was going to be a lot of work, and there were speed and software architecture benefits to using the can-isotp kernel module.<\/p>\n\n\n\n<p>So, I got to work &#8220;adjusting&#8221; (some may say hacking) the can-isotp module from Oliver Hartkopp. I changed the code to not wait for flow-control messages when receiving packets (this is almost exactly the same as how can-isotp does the same when in listening mode) and stopped it from sending flow-control when sending packets. All in all it was only some 40 changes to Oliver&#8217;s original code.<\/p>\n\n\n\n<p>Normally I&#8217;d put a link to Oliver&#8217;s GitHub repository here, but that might confuse people. &nbsp;What I&#8217;m going to do is link <a href=\"https:\/\/github.com\/Purplemeanie\/can-isotp\">here<\/a> to my modified version of his repo. That way you&#8217;ll not go to all the trouble of installing his code, only to find it won&#8217;t work on an MBE ECU. If you want to find his unadulterated code then it can be found from my version of his repo. It might be that Oliver can support this removal of flow-control, but I can fully see how he might not want to do that &#8211; you&#8217;re supposed to use flow-control with ISOTP and so why would a library supporting the standard include some perversion of that standard. We&#8217;ll see how this one plays out and I might update this post to account for where it goes.<\/p>\n\n\n\n<p>But also, for the record&#8230; Oliver has done an awesome job with his kernel module. I almost feel embarrassed to have chopped out the flow-control segment, which is a big part of the code. Sorry Oliver!<\/p>\n\n\n\n<p>Back to our ECU&#8217;s: We&#8217;re not sure why MBE don&#8217;t implement flow-control. It&#8217;s possibly because it was thought to be too complicated. Or perhaps the ECU&#8217;s can respond fast enough not to need the timing \/ throttling that flow-control offers. Or perhaps it&#8217;s both.<\/p>\n\n\n\n<p>One thing we&#8217;re going to have to keep in mind though&#8230; it might be the case that flow-control is required in an MBE ECU application. It might be that Easimap is doing the backing-off of the transmission to the ECU and if we &#8220;hit&#8221; the ECU to hard then it might not be able to keep up. We&#8217;ll have to keep an eye on this as we develop our applications going forwards. We certainly don&#8217;t want to overload the ECU and for it not to be able to do what it&#8217;s really meant to&#8230; i.e. keeping the engine running properly&#8230; that would not go well if we screw that up!<\/p>\n\n\n\n<p>But with flow-control removed from the ISOTP layer we&#8217;re off to the races.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">It All Starts to Make Sense<\/h3>\n\n\n\n<p>As I looked through the communications between Easimap and the car, it was clear that it made a lot of sense when it was decoded as ISOTP. I had no idea what 0x04,0x00,0x0d meant at this time, but at least I had a sense that another layer of the onion was understood.<\/p>\n\n\n\n<p>This made even more sense when I looked at the response from the car&#8230;<\/p>\n\n\n\n<p>Easimap was sending 0x04000d and the car was responding with 0xe4000d23394134626535333000 (I&#8217;ve just joined all the bytes together here instead of adding the 0x to each one).<\/p>\n\n\n\n<p>That response may seem a bit random. But if we look at it by converting it to&nbsp;<a href=\"https:\/\/en.wikipedia.org\/wiki\/ASCII\">ASCII<\/a>&nbsp;then we get the following:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">...#9A4be530.<\/pre>\n\n\n\n<p>That also looks a bit random, but if we ignore the dots (which mean the byte is an unprintable ASCII character) then we&#8217;re left if 9A4be530&#8230; and pulling that apart&#8230; clearly 9A4 is the model of the ECU&#8230; and by checking back with Easimap&#8230; be530 is hexadecimal (0xbe530) and is the serial number of my ECU.<\/p>\n\n\n\n<p>Voila!<\/p>\n\n\n\n<p>By decoding the CAN bus data as ISOTP we&#8217;d managed to extract a string (of characters) that was the model of the ECU and the ECU&#8217;s serial number. That meant we had some meaningful data and we&#8217;re on the right track now.<\/p>\n\n\n\n<p>It also made even more sense when we look at what Easimap does when connected to the car. When Easimap first communicates with the car, it pops up a window in the software showing that it needs to load a particular EC2 file. It must do that because it has found something out about the ECU it&#8217;s talking to. It makes perfect sense that as the first communications with the car, it will ask for its model number and serial number so it can go and load the correct EC2 file. It all adds up.<\/p>\n\n\n\n<p>We just need to figure out what all the rest of the communications between Easimap and the car are.<\/p>\n\n\n\n<p>And to do that, it seemed that I needed to know more about what the Ec2 file was telling Easimap when it loads at the start of the communications. So next up we&#8217;ll dive back into the EC2 files again&#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ok, that&#8217;s enough of the theory about mapping. Lets get back to what Easimap is doing when it talks to the car. When we left this subject last we had got to the point where we could see what Easimap was sending and receiving on the CAN bus, but we didn&#8217;t know what it meant. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":5025,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[51,20],"tags":[34],"class_list":["post-5008","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-caterham-blog","category-ecu-diagnostics","tag-ecu-diagnostics"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/CANBus-Header-Diagram.png","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p8yl38-1iM","jetpack-related-posts":[{"id":4769,"url":"https:\/\/purplemeanie.co.uk\/index.php\/2019\/09\/01\/ecu-diagnostics-part-3-test-setup\/","url_meta":{"origin":5008,"position":0},"title":"ECU Diagnostics &#8211; part 3 : Test Setup","author":"John Martin","date":"September 1, 2019","format":false,"excerpt":"Ok, so we have an OBD port\/connector on our cars that connects directly to the ECU. How are we going to figure out how to talk the right communications protocols to the car to get at its internal data? We need a test rig to do some experiments with. If\u2026","rel":"","context":"In &quot;Caterham Blog&quot;","block_context":{"text":"Caterham Blog","link":"https:\/\/purplemeanie.co.uk\/index.php\/category\/caterham-blog\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/08\/Test-Setup-Diagram.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/08\/Test-Setup-Diagram.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/08\/Test-Setup-Diagram.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/08\/Test-Setup-Diagram.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/08\/Test-Setup-Diagram.png?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":4943,"url":"https:\/\/purplemeanie.co.uk\/index.php\/2019\/09\/07\/ecu-diagnostics-part-5-the-correlator-dead-end\/","url_meta":{"origin":5008,"position":1},"title":"ECU Diagnostics &#8211; part 5 : The Correlator Dead-end","author":"John Martin","date":"September 7, 2019","format":false,"excerpt":"Hopefully this is a quick post... The story so far is that: We've got a test bench made of a Raspberry Pi, CAN bus decoder board and an OBD Y-cableThe Raspberry Pi can \"sniff\" all the packets sent between the car's ECU and something that can talk to the car,\u2026","rel":"","context":"In &quot;Caterham Blog&quot;","block_context":{"text":"Caterham Blog","link":"https:\/\/purplemeanie.co.uk\/index.php\/category\/caterham-blog\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/Github-Correlator.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/Github-Correlator.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/Github-Correlator.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/Github-Correlator.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/Github-Correlator.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/Github-Correlator.png?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":5155,"url":"https:\/\/purplemeanie.co.uk\/index.php\/2019\/09\/20\/ecu-diagnostics-part-13-3-mbe-isotp\/","url_meta":{"origin":5008,"position":2},"title":"ECU Diagnostics &#8211; part 13.3 : MBE-ISOTP","author":"John Martin","date":"September 20, 2019","format":false,"excerpt":"SUMMARY We now understand the communications protocol used by Easimap (the Windows software supplied by the ECU manufacturer) 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 them to\u2026","rel":"","context":"In &quot;Caterham Blog&quot;","block_context":{"text":"Caterham Blog","link":"https:\/\/purplemeanie.co.uk\/index.php\/category\/caterham-blog\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":5050,"url":"https:\/\/purplemeanie.co.uk\/index.php\/2019\/09\/16\/ecu-diagnostics-part-11-logic-analyzer-on-the-can-bus\/","url_meta":{"origin":5008,"position":3},"title":"ECU Diagnostics &#8211; part 11 : Logic Analyzer on the CAN Bus","author":"John Martin","date":"September 16, 2019","format":false,"excerpt":"To test out my theories and the code I'd been writing, I needed a simple test and a way to make sure the code (and I) was doing what I thought it should be. The code part was easy, take the JSON files I'd created from the Easimap EC2 file\u2026","rel":"","context":"In &quot;Caterham Blog&quot;","block_context":{"text":"Caterham Blog","link":"https:\/\/purplemeanie.co.uk\/index.php\/category\/caterham-blog\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/img_2013.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/img_2013.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/img_2013.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/img_2013.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/img_2013.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/09\/img_2013.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":5192,"url":"https:\/\/purplemeanie.co.uk\/index.php\/2019\/09\/20\/ecu-diagnostics-part-14-software-framework-mbe-py\/","url_meta":{"origin":5008,"position":4},"title":"ECU Diagnostics &#8211; part 14 : Software Framework mbe.py","author":"John Martin","date":"September 20, 2019","format":false,"excerpt":"This is hopefully a reasonably short post about the software framework I've developed to help read sensor data from the MBE 9A4 ECU. The software is written in Python 3 and is available here: Caterham-OBD. However, I'm going to talk about using one file only which is mbe.py.\u00a0 The idea\u2026","rel":"","context":"In &quot;Caterham Blog&quot;","block_context":{"text":"Caterham Blog","link":"https:\/\/purplemeanie.co.uk\/index.php\/category\/caterham-blog\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":4765,"url":"https:\/\/purplemeanie.co.uk\/index.php\/2019\/08\/31\/ecu-diagnostics-part-2-ecu-obd-and-can\/","url_meta":{"origin":5008,"position":5},"title":"ECU Diagnostics \u2013 part 2 : ECU, OBD and CAN","author":"John Martin","date":"August 31, 2019","format":false,"excerpt":"ECU Caterhams, like all modern cars, have an Engine Control Unit (ECU) - a black box full of electronics, controlled by a microprocessor that manages how the engine runs. \u00a0And because it has a microprocessor it means it runs some software to control everything. It also connects to a bunch\u2026","rel":"","context":"In &quot;Caterham Blog&quot;","block_context":{"text":"Caterham Blog","link":"https:\/\/purplemeanie.co.uk\/index.php\/category\/caterham-blog\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/purplemeanie.co.uk\/wp-content\/uploads\/2019\/08\/9A4.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/5008","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/comments?post=5008"}],"version-history":[{"count":1,"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/5008\/revisions"}],"predecessor-version":[{"id":10699,"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/5008\/revisions\/10699"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/media\/5025"}],"wp:attachment":[{"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/media?parent=5008"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/categories?post=5008"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/purplemeanie.co.uk\/index.php\/wp-json\/wp\/v2\/tags?post=5008"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}