Jump to content
Click here if you are having website access problems ×

Purplemeanie

Area Representative
  • Posts

    658
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Purplemeanie

  1. So a bit of a diversion today... I was looking at the Easimap protocol again as Mark and I were chatting on Slack and I remembered I had an OBD scanner that I bought when I was building the car. So I decided to connect that back up to the car again and see what it did on the CANBus with my newly set up Raspberry Pi CANBus sniffer. By the way, some of you old hands will probably know all this already. But hopefully its helpful to some of you. The scanner is an Autolink AL319. It goes through a setup phase where it tries to decide what protocol the car is talking - Which turned out to be "CAN EXD FAST". Makes sense seeing as the Wireshark captures we've been looking at report exactly that (CAN EXD). It then goes through a phase of deciding what data the car can report using the OBD protocol. It's perhaps worth noting here that these ECU's talk at least two protocols. The one Easimap uses and OBD-II. The OBD protocol is quite easy to decode but the Easimap one is proving to be a little more troublesome. Anyway, that lead me to what OBD is, and to this page: https://www.csselectronics.com/screen/page/simple-intro-obd2-explained/language/en and then to the Wikipedia page here: https://en.wikipedia.org/wiki/OBD-II_PIDs If you want to dig into OBD then those two pages explain it all. But suffice to say the protocol is a Request/Response protocol. The Scanner sends a request for a response about a PID (see the two links for more info on PIDs). The upshot of my research was that I could see the car responding to three PID discovery requests as follows: 9A4 ECU Response the OBD PID 0 0xd8368019 -> 0b11011000001101101000000000011001 9A4 ECU Response the OBD PID 20 0x20002001 -> 0b00100000000000000010000000000001 9A4 ECU Response the OBD PID 40 0x40100000 -> 0b01000000000100000000000000000000 And that leads to the following PIDs being supported by the car. Just thought some of you might appreciate this research. It seems that some websites refer to Services (the new term) and some to PID, they are the same thing as far as I can see. (I've checked my working out and I think I've got it right, but someone might like to check it) To be clear: This data is not present on the OBD/CAN port by default. You have to have a device connected that can "ask" for the data. i.e. the device has to send a "request" and the car sends the "response". Service (PID) Supported (Snn) S01 1 -> Monitor status since DTCs cleared. (Includes malfunction indicator lamp (MIL) status and number of DTCs.) S02 1 -> Freeze DTC S03 0 -> S04 1 -> Calculated engine load S05 1 -> Engine coolant temperature S06 0 -> S07 0 -> S08 0 -> S09 0 -> S0A 0 -> S0B 1 -> Intake manifold absolute pressure S0C 1 -> Engine RPM S0D 0 -> S0E 1 -> Timing advance S0F 1 -> Intake air temperature S10 0 -> S11 1 -> Throttle position S12 0 -> S13 0 -> S14 0 -> S15 0 -> S16 0 -> S17 0 -> S18 0 -> S19 0 -> S1A 0 -> S1B 0 -> S1C 1 -> OBD standards this vehicle conforms to S1D 1 -> Oxygen sensors present (in 4 banks) S1E 0 -> S1F 0 -> S20 1 -> PIDs supported [21 - 40] S21 0 -> S22 0 -> S23 1 -> Fuel Rail Gauge Pressure (diesel, or gasoline direct injection) S24 0 -> S25 0 -> S26 0 -> S27 0 -> S28 0 -> S29 0 -> S2A 0 -> S2B 0 -> S2C 0 -> S2D 0 -> S2E 0 -> S2F 0 -> S30 0 -> S31 0 -> S32 0 -> S33 1 -> Absolute Barometric Pressure S34 0 -> S35 0 -> S36 0 -> S37 0 -> S38 0 -> S39 0 -> S3A 0 -> S3B 0 -> S3C 0 -> S3D 0 -> S3E 0 -> S3F 0 -> S40 1 -> PIDs supported [41 - 60] S41 0 -> S42 1 -> Control module voltage S43 0 -> S44 0 -> S45 0 -> S46 0 -> S47 0 -> S48 0 -> S49 0 -> S4A 0 -> S4B 0 -> S4C 1 -> Commanded throttle actuator S4D 0 -> S4E 0 -> S4F 0 -> S50 0 -> S51 0 -> S52 0 -> S53 0 -> S54 0 -> S55 0 -> S56 0 -> S57 0 -> S58 0 -> S59 0 -> S5A 0 -> S5B 0 -> S5C 0 -> S5D 0 -> S5E 0 -> S5F 0 -> S60 0 -> John
  2. Looks like our messages crossed Mark, I was responding to your previous one. Now for your last message... Yes, PiCan2 is SocketCan compatible... seems to work well, once I'd found the one I'd squirrelled away from 2017!. They also do variants with GPS and accelerometer built in, and one that has two CAN interfaces that can be used as a bridge. Let me know if you get to try one as there were a couple of twists to the driver setup for the latest 4.x kernels. i should probably do a blog post on its setup, but I was hoping we'd crack the code before I did that :-)
  3. That would certainly be worth a try Mark. Can you put up the converted candump formatted file somewhere? How did you convert it? Have you got some custom code in Wireshark or have you written a libpcap based converter? I was thinking of just parsing an exported CSV file from Wireshark, but that's not very elegant :-) John
  4. For anyone interested, here are two .pcap files... The first is the pcap that generated the packet listing in post #64 above: https://www.dropbox.com/s/29vkmdltab3ytm3/cano-003-ig2_0s-easimap_1000p.pcap?dl=0 The second pcap is a simple capture of what was on the CAN bus with just Easimap looking for an ECU to monitor: https://www.dropbox.com/s/07i02ojv9lsum2z/cano-004-only-easimap.pcap?dl=0 Knock yourself out! :-) (I'm currently trying to figure out if there's a mapping between what's in the can bus data and what's in the Easimap EC2 file. I'm sure there must be a correlation between the can bus data and the page/address config from the EC2. There are some correlations but I haven't got the confidence yet that I've figured it out.) And Mark, I also think there's a good chance that replaying the 0x(03,04...) packet into the canbus may just wake up the gateway that's hiding the second CAN ID. But Easimap is a little chatty around that time so it might take a few of those codes around pkt 528 in that pcap. One of my next experiments is to see what Easimap does if it's running but the car is off, then I turn the car on. I'm wondering if Easimap turns the 0x(03,04,00,0d,cf,00,00,e2) into 0x(03,04,00,0d,ef,fb,ff,f7) or is the first data set enough to wake things up. I'm definitely still poking around in the dark, but at least we now have a torch! John
  5. Hi James, that should be possible. I may need to wait for the weather to clear and be able to get the car out of the garage :-) Do you want the CAN data in any particular format? I've only used tshark (Wireshark) to capture packets so far, and the associated .pcap can be a little difficult to work with - though libpcap programming isn't too bad its not easy to dump pcap's into something like Excel. Can you tell me what you're going to do with the data and then hopefully I can make sure it works as best as I can make it for you.
  6. Ok, so hopefully I can move this on a small amount... I've now got both Easimap running and a CANBus sniffer. The setup is: MacBookPro running Easimap through Parallels,Windows 10 VM SBD USB to CANBus interface connected to Mac and the USB routed through to the Windows VM Raspberry Pi 4 with a PiCAN2 HAT OBD-II Y-cable plugged into Caterham, MacBookPro (Easimap) and Pi (PiCAN2 running tshark) Ignition set to postion 2 but engine not running (I'll try some running tests when I've (we've) firgured out some more of what's going onHere's a picture of the setup: I've tried a few captures of what's going on when Easimap is running with the following findings: Until easimap is running the car outputs CAN packets as per Marks output on page 3 of this thread (all the packets are coming from a device with an ID of 0x0cbb001) Once Easimap is started there are two new devices that start talking on the bus 0xcbe1101 - seems to be the SBD USB to CANBus interface 0xcbe0111 - seems to be another device in the car, probably where Easimap is getting its data from It seems that Easimap is sending a packet with 0x(03,04,00,0d,ef,fb,ff,f7) which starts the 0xcbe0111 device sending. I also tried turning the car off to see what Easimap would do then. It then starts sending packets out at about 1s intervals with the values 0x(03,04,00,0d,cf,00,00,e2). That's what makes me think that 0xcbe1101 is the SBD interface and that it sends a 03,04... packet to get the car to output more info. My suspicion is that the 03,04 packet is opening a CAN gateway in the car. I now have a lot more data, but still no idea what it means. Here's a chunk of data from Wireshark at around the time that Easimap starts to talk to the car, the initial Easimap packet seems to be at packet 528 (left column): No. Time Protocol Length Info 522 5.217999920 CAN 32 XTD: 0x0cbb0001 04 95 ff 28 00 00 00 00 523 5.227903970 CAN 32 XTD: 0x0cbb0001 03 27 00 1d 00 1d 00 00 524 5.237803910 CAN 32 XTD: 0x0cbb0001 02 aa aa 00 cf d6 00 00 525 5.248304747 CAN 32 XTD: 0x0cbb0001 01 52 00 00 39 00 95 49 526 5.257841952 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 527 5.267871945 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 528 5.269606548 CAN 32 XTD: 0x0cbe1101 03 04 00 0d ef fb ff f7 529 5.270596810 CAN 32 XTD: 0x0cbe0111 10 0d e4 00 0d 23 39 41 530 5.270927046 CAN 32 XTD: 0x0cbe0111 21 34 62 65 35 33 30 00 531 5.277878771 CAN 32 XTD: 0x0cbb0001 ff 49 00 00 00 00 00 00 532 5.288061077 CAN 32 XTD: 0x0cbb0001 ff 95 00 00 00 00 00 00 533 5.297965424 CAN 32 XTD: 0x0cbb0001 04 95 ff 28 00 00 00 00 534 5.308121693 CAN 32 XTD: 0x0cbb0001 03 27 00 1d 00 1d 00 00 535 5.318314165 CAN 32 XTD: 0x0cbb0001 02 aa aa 00 cf d6 00 00 536 5.328443119 CAN 32 XTD: 0x0cbe1101 03 04 00 5e ef fb ff f7 537 5.328729670 CAN 32 XTD: 0x0cbb0001 01 52 00 00 39 00 95 49 538 5.329432159 CAN 32 XTD: 0x0cbe0111 07 e4 00 5e 2b 07 01 00 539 5.337934713 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 540 5.347971169 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 541 5.357984570 CAN 32 XTD: 0x0cbb0001 ff 49 00 00 00 00 00 00 542 5.368106561 CAN 32 XTD: 0x0cbb0001 ff 95 00 00 00 00 00 00 543 5.378248386 CAN 32 XTD: 0x0cbb0001 04 95 ff 28 00 00 00 00 544 5.388638336 CAN 32 XTD: 0x0cbb0001 03 27 00 1d 00 1d 00 00 545 5.398827049 CAN 32 XTD: 0x0cbb0001 02 aa aa 00 9f d6 00 00 546 5.408066758 CAN 32 XTD: 0x0cbb0001 01 52 00 00 39 00 95 49 547 5.418108103 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 548 5.428370518 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 549 5.438262384 CAN 32 XTD: 0x0cbb0001 ff 49 00 00 00 00 00 00 550 5.448232693 CAN 32 XTD: 0x0cbb0001 ff 95 00 00 00 00 00 00 551 5.459009322 CAN 32 XTD: 0x0cbb0001 04 95 ff 28 00 00 00 00 552 5.468146959 CAN 32 XTD: 0x0cbb0001 03 27 00 1d 00 1d 00 00 553 5.478194340 CAN 32 XTD: 0x0cbb0001 02 aa aa 00 ef d6 00 00 554 5.488435460 CAN 32 XTD: 0x0cbb0001 01 52 00 00 39 00 95 49 555 5.498216679 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 556 5.508246450 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 557 5.518649382 CAN 32 XTD: 0x0cbb0001 ff 49 00 00 00 00 00 00 558 5.528866409 CAN 32 XTD: 0x0cbb0001 ff 95 00 00 00 00 00 00 559 5.538409909 CAN 32 XTD: 0x0cbb0001 04 95 ff 28 00 00 00 00 560 5.548303645 CAN 32 XTD: 0x0cbb0001 03 27 00 1d 00 1d 00 00 561 5.558352749 CAN 32 XTD: 0x0cbb0001 02 aa aa 00 bf d6 00 00 562 5.568327299 CAN 32 XTD: 0x0cbb0001 01 52 00 00 39 00 95 49 563 5.578379125 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 564 5.588759816 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 565 5.599091804 CAN 32 XTD: 0x0cbb0001 ff 49 00 00 00 00 00 00 566 5.608444419 CAN 32 XTD: 0x0cbb0001 ff 95 00 00 00 00 00 00 567 5.618418746 CAN 32 XTD: 0x0cbb0001 04 95 ff 28 00 00 00 00 568 5.628551367 CAN 32 XTD: 0x0cbb0001 03 27 00 1d 00 1d 00 00 569 5.638437603 CAN 32 XTD: 0x0cbb0001 02 aa aa 00 8f d6 00 00 570 5.648491596 CAN 32 XTD: 0x0cbb0001 01 52 00 00 39 00 95 49 571 5.658657346 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 572 5.669189776 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 573 5.678610186 CAN 32 XTD: 0x0cbb0001 ff 49 00 00 00 00 00 00 574 5.688548625 CAN 32 XTD: 0x0cbb0001 ff 95 00 00 00 00 00 00 575 5.698673153 CAN 32 XTD: 0x0cbb0001 04 95 ff 28 00 00 00 00 576 5.708593426 CAN 32 XTD: 0x0cbb0001 03 27 00 1d 00 1d 00 00 577 5.718837841 CAN 32 XTD: 0x0cbb0001 02 aa aa 00 ef d6 00 00 578 5.729158163 CAN 32 XTD: 0x0cbb0001 01 52 00 00 39 00 95 49 579 5.738714219 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 580 5.748656584 CAN 32 XTD: 0x0cbb0001 ff 00 00 00 00 00 00 00 581 5.758626393 CAN 32 XTD: 0x0cbb0001 ff 49 00 00 00 00 00 00 582 5.768961752 CAN 32 XTD: 0x0cbb0001 ff 95 00 00 00 00 00 00 583 5.776471191 CAN 32 XTD: 0x0cbe1101 10 0a 01 00 00 00 00 12 584 5.777320493 CAN 32 XTD: 0x0cbe1101 21 66 67 a8 a9 00 00 12 585 5.778524474 CAN 32 XTD: 0x0cbe0111 05 81 aa aa 16 00 12 66 586 5.778809858 CAN 32 XTD: 0x0cbb0001 04 95 ff 28 00 00 00 00 587 5.787125934 CAN 32 XTD: 0x0cbe1101 10 09 01 00 00 00 00 1a 588 5.787834886 CAN 32 XTD: 0x0cbe1101 21 52 5c 5d 00 00 00 1a 589 5.788834463 CAN 32 XTD: 0x0cbe0111 04 81 84 00 00 00 1a 52 590 5.789118458 CAN 32 XTD: 0x0cbb0001 03 27 00 1d 00 1d 00 00 591 5.799340004 CAN 32 XTD: 0x0cbb0001 02 aa aa 00 bf d6 00 00 592 5.800358840 CAN 32 XTD: 0x0cbe1101 10 0a 01 00 00 00 00 e2 593 5.801094588 CAN 32 XTD: 0x0cbe1101 21 cc cd ce cf 00 00 e2 594 5.802136776 CAN 32 XTD: 0x0cbe0111 05 81 ff ff ff 07 e2 cc 595 5.808806413 CAN 32 XTD: 0x0cbb0001 01 52 00 00 39 00 95 49 596 5.814872560 CAN 32 XTD: 0x0cbe1101 10 23 01 00 00 00 00 f8 597 5.815639382 CAN 32 XTD: 0x0cbe1101 21 30 31 36 37 44 45 4c 598 5.816393407 CAN 32 XTD: 0x0cbe1101 22 4d 4e 4f 50 51 5a 5b 599 5.817143414 CAN 32 XTD: 0x0cbe1101 23 5c 5d 64 6a 6b 7c 7d 600 5.817903458 CAN 32 XTD: 0x0cbe1101 24 9e 9f a0 a1 d8 d9 da
  7. CharlesElliott, what are you using to do the analysis? What CANbus analyser have you got and what software are you using? I think you mentioned Excel before, but is that what you're using to do the analysis?
  8. All your screen shots have shown up for me. I've been pondering them so haven't commented. The last one you show makes some sense now. You've got the same 29 bit ID that Mark was reporting but you've got additional devices on the bus. Makes a lot more sense now. Not sure why Mark wasn't seeing the same but maybe he didn't have the car running or something.
  9. Thanks Mark. FWIW, I would have thought a Y-cable would be fine... it's not a particularly fast bus and I would have thought the resistive pull-up and active pull-down mechanism should play fine with the Korlan sniffing while the SBD/Easimap is doing its thing. Would be cool to find out what magic Easimap does to turn on all the goodies it can record. I haven't seen anyone else post the exact mechanism yet, but I may have missed it. Where did you get the Korlan from... the US link you provided? or was there a UK/EU site? John
  10. Isn't your ECU a different one to Mark's though? Yours is putting out two channels, Mark's seems to be dumping way more than that and with a different CAN format? What ECU are you running CharlesElliott (sorry if I missed that somewhere in this thread)? John
  11. That makes things a little trickier then :-) I guess that's why Mark was trying to parse the Easimap config files. John
  12. Looks to me as though the data portion of Mark's packet capture is set out something like how this document sets things out... https://www.sbdmotorsport.co.uk/index.php/instructionpdf/index/186 The first byte of Mark's candump data output corresponds to the Identifier field in that PDF (01, 02, 03, 04 look the most interesting but there's clearly something also in the FF messages - which might be an end of stream message as mentioned earlier in this thread, but might also just be a NULL message dumped out at regular intervals if there's nothing else to transmit in that time slice). So as an example from Mark's data, #014F00003D009C46 might break down as: 01: Identifier 01 Which implies that: 4F: Engine Speed MSB 00 : Engine Speed LSB etc I guess the SBD PDF isn't actually the mappings used in the Caterham ECUs... but... From what I can tell it looks as though that's all defined in Easimap under the System -> CAN Bus data stream menu and should be reasonably trivial to take the output from candump and parse it using the mappings from Easimap. Or have I got that all wrong? John
  13. Mark, it looks to me as though the dump you've provided is: 29 bit ID: 0CBB0001 64 bit data: #FF00000000000000 Is that the way you're reading this? In which case the ID would stay the same if there's only one device transmitting on the bus?? John
  14. Mark, before you bought the Korlan CAN-USB widget, did you try the SBD interface with the SocketCAN drivers for Linux? Just wondering if I need to buy the Korlan interface or whether I can hook up the SBD interface to a Pi. I presume you're using Linux to be able to use candump, right? Also, to get an EasyMap pcap, are you going to use the SBD interface and the Korlan interface connected on a OBD y-cable? Or have you got some other cunning plan? I presume Wireshark won't capture the SBD interface packets on Windows... or will it? John
  15. In case anyone's interested, I've uploaded a video of my rear pad slapping in the caliper here: (Note: this is an unlisted video, so you won't be able to search for it on YouTube, you'll need to use the link above) John
  16. I already have the hoses for the SV from Redline... just need the time :-)
  17. I chased a rattle/knock from the rear end of my car for a while, tried all the things you mentioned. Turned out to be the rear brake pads rattling in the calipers. I could move the pads up and down in calipers by just moving them with my fingers poked through the spokes of the wheel. They bounce up and down going over a bump giving a clanking noise. Still haven't got round to fixing it because I want to switch out my copper brake lines to be flexible hoses and that project hasn't got to the top of my list yet. I'm expecting to find the spring clips are not installed correctly but others may have better suggestion. Most passengers didn't notice it until I told them about it, and then they would hear it too. So not particularly obvious. Just a thought. John
  18. Glad to hear I'm not imagining things Chris! :-) Some of the confusion about where the submarine goes might be coming from how different people lay out their pipework. On my diagrams (and on the cars I'd seen to that point) the pipe from the back-right (offside) of the cylinder head is routed UNDER the back of the cylinder head to the submarine and then on to the bottom fitting on the heater control. My diagrams are here in case anyone is interested: https://www.purplemeanie.co.uk/index.php/2017/09/23/build-session-17-5-caterham-420r-water-and-oil-overview/ Since then I've seen some people route that pipe from the back-right of the head up and over the back of the head, through the submarine and then to the bottom of the heater control. It makes it easier to adjust and tighten the jubilee clips on either side of the submarine but, IMHO, I think it makes the routing of the pipe to the heater less neat and doesn't give as much free space around the back of the battery for "other projects" I had in mind. You pays your money and takes your choice :-) I hope that hasn't confused things even further! John
  19. Hi Roger, I'm not sure if this helps at all but while not getting my head around how the rear brake calipers work I pulled one apart and took a picture of the insides. If that's not high enough res then I put a copy onto the blog post I mentioned above. It might confuse you more than help, but I found I wanted to know how things worked before I would accept what others were telling me. John
  20. Hi Roger, as p.mole1 says the pips being in the right place might be the issue. If I got this wrong though (I did once) the caliper wouldn’t fit over the pads, so perhaps not that. As Jonathan says you have to make sure you do everything in the right order. If you apply the handbrake before filling and bleeding the brakes then you can get the self adjusters activated before they should be. This all confused the hell out of me when I recently built my 420 and I have half a blog post written about how the brakes and self adjusters work (sorry that doesn’t help a great deal for you though) - one day I may finish that off. You’ll need to rewind the pistons if that’s the case. There might be something in the pictures on this page that help though... https://www.purplemeanie.co.uk/index.php/2017/10/01/build-session-21-a-frame-ears-hubs-discs-callipers-brake-pipes-wheels/ John
  21. Glad you're enjoying the blog Will. I must say you're doing well if you managed to read until the early hours, most people fall asleep (day or night) long before that! :-) If you have any questions about the blog then please feel free to contact me, either on FB Messenger (JFPMartin) or email (john.martin@purplemeanie.co.uk). Or of course on this site. John
  22. Will, I did like others for my build last year and bought CJ Autos smallest mobile axle stands. I bought the steel wheeled version but switched the castors out for “rubber” shod wheels that I bought from Amazon... made it much easier, and quieter, to wheel around my concrete garage. I also had barked shins from the front cross member being too long but just cut it, and the rear, to be the right size for the application after a couple of hours of dancing around them. Best purchase I made for the build. I still use them regularly to get the car up high to work on and to wheel it in and out of the garage when I’m working on it. In fact one of the best things about the mobile stands and a small garage was that I could get the build out onto my drive on a nice day and have extra space to work. The height aspect was also worth the purchase for me. The CJ stands go high enough, and securely enough, to give plenty of room to work under the car. I also found myself leaning my head on the cross members as I lay under the car for long periods. In terms of getting the engine hoist into place, you can see how I got on here... http://www.purplemeanie.co.uk/index.php/2017/08/28/build-session-11-all-hands-to-the-hoist-engine-in/ Good luck with the build! John
  23. Totally agree with all comments - fantastic day on and off track. Made some great new friends and look forward to more club run track days. John
  24. Thanks Dave. Had a great day, everyone really friendly and great fun. John
×
×
  • Create New...