How to make it work.... #41
Comments
I'd do the same, sounds reasonable. Start with setting the define here to enable debug mode, you should get more info. |
|
Apparently, pin 1 and the first 5 pins are on the bottom beveled edge. So I fixed that. In case I smoked the IC by hooking it up backwards, I have 5...ha ha. I enabled debugging. I'm not sure what all this means. I searched the OBD9141.h, Arduino.h, and AltSoftSerial.h for the words "magic" and "read" but didn't find a clue as to what it might be doing. Any idea what that means? During that test, I sniffed what was happening with the ELM327. It prints a line of "55 E9 8F" at every loop, and the ELM seems to think its an error. The ELM considers this a header packet because they dont show up in H0 (headers off) mode. I switched between modes just in case it would change the sniff reading, it didn't. Finally, I connected with the ELM327 and it connects just fine. The ECU side hardware and connection seems ok. My next step might be to rig up a voltage divider and another Arduino as a 12V scope to see what is happening on the K line and series RX/TX? What do you think? Any advice? I wonder if we can put the 33290 into monitor mode??
|
|
Please always upload images to github instead of linking to a third party, just drag them into the edit window, that way they never expire. And ideally, no screenshots of text, I can't copy paste from that.
Certainly, we are now seeing the prints from the init function, so we get more information about what we get from the ECU and what we expect.
I'm not sure if the ELM can sniff this correctly without interfering with the handshake. So what happens during the handshake is that we send a very slow 5 baud init, then the reader reads the first byte; So I'm a bit confused with the screenshot, is the screenshot's left side part is just the output from this library and without the ELM interfering? If so we're failing this check. You can try to remove the check on line 421 and just send back the inverted value of
It's always in monitor mode! These chips don't have state, so just latch EN high, attach a serial port to the Rx pin at 10400 baud and you should be able to sniff the ELM (not the slow 5 baud init though, but the rest should show up).
It's an option, first I'd try to attach just your 33290 with arduino, in debug mode and see what happens. |
|
Oh the cpp file! I forgot about that one. Learning lots today about OBD, GitHub, Electronics.. Thank you! Much easier to post images directly here. I was messing around and noticed the ELM327 thinks the 55 E9 8F is a header, because it doesn't show up if in H0 (headers off) mode. Unplugged the 327 and my splitter cable. K line is straight to the ECU... Forever... it never exits the loop to a new loop. Not in a minute anyway. I got my old school needle multimeter out and I've got constant power on Pin 1 and Pin 5 (K-Line) shows activity and bouncing voltages. |
I don't think that will work, because we still need to read the 0xCC from the ECU first, if anything, disable the check on 421, or comment out 422. Can you copy the full output during the initialisation (So the section above |
|
Here is the full log... Bonus round, FYI, might be relevant. I spent a bunch of time sniffing and messing around. At one point in time I tried using two 33290 chips, hooking their serial together...didn't work, and I wonder why? |
Yup, looking good, glad you got confirmation the hardware is working, these are good discoveries.
Ooh, but that looks like a KWP request! So 9141-2 should be 0x86, 0x6a, 0xf1, 0x01, 0x0d, but this starts with So that does change things, can you try readerKWP? That may just work out of the box. It's pretty weird that we do get the
You'll probably need to cross Rx and Tx between the two 33290s (so connect the left 33290's Rx to the right 33290s Tx), and you can only connect the arduino's Rx line to one of the communication directions, if you connect the tx line to anything it'll just pull that line high or low since the arduino would drive the tx line. |
|
YAY! KWP worked out of the box! I saw that as an option but it wasn't clear to me, I knew I wanted software serial so all I did was change init to initKWP! I put the check back in and disabled debug mode and it still works! Why it thinks I have throttle 240 when there is no pedal, I dont know. Is this 0-255? I'm working on debugging and getting another windows ECU tool to connect to my ECU. We're noticing if you set the headers to the Functional ECU address 33 (broadcast) C1 33 F1 it works. If you send the Physical ECU address 82 10 F1 it doesn't listen. Not to mention somehow its communicating the number of data bytes in the header (3?). It's SOOO detailed and hard to understand. I'm barely wrapping my head around it. Kind of fun. I've also seen it respond to C1, C2... doesn't seem to matter. I hate the new Arduino IDE serial monitor. I cant copy paste many lines with it. It stays connecting and I have to kill it to do an upload..ugh. What serial program do you use in Windows/Linux when messing with things? Putty is to old-ish too.
I tried crossing the Rx and Tx lines. I had no arduino in the mix. I thinking maybe I need to connect the arduino to set the speed an initialize the serial communication, even if Rx only. I'll try that next. Next Next, mess with your simulator :D :D. |
Hah, very nice, that makes things a lot easier :D Glad we got it working.
Hmm, I think this is supposed to be 0-100, so in percent? Maybe it's 240-255 for this car? To indicate there's only 16 levels? (I'm 100% guessing here, I have no idea :D)
Yeah... I always feel different cars have their own idiosyncrasies.
Yes, with kwp the number of length in the request is encoded in the first byte, I'd be surprised if the ECU ignores that field, because then the checksum should also be invalid.
😮 I almost always use Linux, I usually use
Heh, the simulator's handshake simulation is flakey, which is why that part is disabled by default. The simulator without the handshake should be fine. Just make sure you force your reader to assume it initialised correctly. I mainly built this to allow me to develop this display without having to test it on my car all the time. |
|
Big Thank you for your help!!!!!! What does your display look like in real life? I messed with the serial to serial connection, Arduino in RX only mode. Completely Disconnect RX and TX from both modules, the only pins I read data on is 33289 #1 RX (6) and 33289 #2 RX (6). Never TX.
Huh, it definitely listens to that. I swear I've seen C1s. I tried C1-C3 and only C2 works VIN and everything that is a two byte request (01 01, 09 02... most things are two bytes. What is a 3 or 1 or 5? I'll do some poking around.
Hmm I wonder how the 5 baud init can work. Or if I can pass though the init from the connection requester to the connection receiver (ECU here), kind of a MITM approach. This is an engine swap into a MK1 VW. I'm trying to make some gauges, which is a read only operation. However the ECU also freaks out when half the modules it's used to talking to isn't there so I was going to fake their responses in the Arduino. Big thank you!!! Fun too. I can close this but might poke around with more questions. |
|
Oh man, looks like I lied. initKWP did not work by itself. I had an ELM327 connected and it was maintaining the connection. I unplugged everything and power cycled the arduino and ECU. Just for grins I did the same thing with init instead of initKWP. How would I get my VIN? |
Hmm... can you try to build To capture what the ELM is sending during the handshake? Just put a minimal sketch on the arduino that just dumps everything from the Rx pin of the 33290 to the usb serial port? A lot of things are working, we're just failing at the handshake it seems? You could also try to just skip the init, and just force your reader to assume init has worked... maybe the ECU doesn't care about the initialization and just responds.
Yeah, I think that 233 & 143 for v1 and v2 is some kind of KWP error response.
You said it was: We can decode this using this line and this for the first two, mode would be |
Yes, seems like things are working just need massage out the handshake. I tried to skip the init, it never responded. The first part pre 39.171 should be whatever magic is happening with the handshake. Here is what the Chinese ELM outputs. I noticed I can just ATZ 09 02. I dont have to specify anything. They sure handled a BUNCH of logic obfuscated from the user. This is the sketch I used... How you group up the stream is currently beyond me. You also specify how long it is. I'm studying that.... I had an idea to try it with the ELM establishing and the OBDLink monitoring. |
Yeah, you can... but the problem is the 5 baud init, that will cause problems since that's not a proper serial port procedure at 10400 baud. So you'd have to first do either a very tight loop to just reflect the Rx state with polling, or pass that 5 baud init through with some interrupts, then only after that start the serial port.
Yes, you are correct. So interestingly enough, this is not a kwp init... it appears to be closer to a standard 9141-2 handshake. The kwp init is this sequence with a start pulse, basically. What you got here is Which corresponds to the So the handshake is;
What is super odd... is that the timestamps group the bytes as:
But the Either way... in this comment we had success doing the initialisation with So I think next step to try is:
uint8_t message[5] = {0xc2, 0x33, 0xf1, 0x01, 0x0d};
uint8_t received_length = obd.requestKWP(message, 5);I think at least... obviously can't try this. To make that more elegant / less error prone, it's probably easier to:
|
|
YAY!! I think we got it. I tried it several times to make sure. So, this is one strange ECU. I wonder how all the OBD2 software and scanners are connecting. It only kind-of adheres to the protocols. That throttle of 240 is interesting. Maybe I have to pull it to ground or something. I'll worry about it later. I think it's valid because other OBD software shows throttle open 92%. I need more experience with object orientated. I wasn't sure how to add the method to flip the bit, or track the bit. I tried... I saw the use_kwp_ bit was set in the first line of OBD9141::init() Here I'm glad you explain concepts so well. I'm going to mess with it more and probably come back to this 12 times to learn more. this->write(~v2); I noticed the readBuffer method does not contain the header in any position. How can we make it contain the header? Would adding a SoftwareSerial on pins 4 and 5 cause problems on a nano? Once the arduino is connected and initialized I can read and write straight serial and look for key bits (ex "C2"). I'm trying to identify outgoing data so I can process it and send it to my gauges. This logic will mess up if C2 is ever in the data or a checksum.... VIN is weird because there are 4 lines in the response I just made up 4, I don't know how long it is. Vin is the only PID I've seen that gets returned in multiple chunks... Should I brew this up from scratch? What is the difference between 8 16 and 32? I'm going to close this now. I'm going to try and not pester you, I would love to ask questions as I mess around! |
I think the main problem is that there's a bunch of protocols, and they are all different. None of the specs are publicly available :( I built this from information on the internet and used it on my first car, a Kia, and currently on my Nissan.
Could be a stuck sensor yeah, or signalling issue.
Yeah, that's fine. I finally remembered that I saw these numbers before in #34. So this is not a special init, this is a relatively standard / common one. I've filed #42 to add support for this initialisation procedure to the library, and added an example to use this init. If you could help test that example that'd be appreciated.
Should be
You can only use these pins with AltSoftSerial, they need a timer's comparison, so it's limited to a number of pins.
readBuffer allows access to all received bytes? I think it should be there?
See my last sentence in this comment
See the implementation when in doubt :) Since there's no zero's in front of the bytes, we can't just always cast it to a uint32. |
|
SlowKWP works great! Thank you.
Not quite what I mean. I have a working AltSoftSerial. As soon as I add another SoftSerial (for communicating with another module) the whole thing breaks.
In the grey log there is a loop that reads out the contents of the readbuffer. I went to a max of 11, just because and indexed it at 0, also just because. In the white box I have an output of the command. The header is missing from the readbuffer...
|
Yeah, they both probably use the same hardware timer and end up breaking functionality. On microcontrollers the number of timers is limited and to guarantee functionality a library needs exclusive access to the hardware timer. Two libraries usually can't share a timer. AltSoftSerial uses one of these timers. A timer is a dedicated piece of hardware in the microcontroller with various registers that allow you to configure how it is used. I'd consider switching away from the atmega328 based arduino's and switch to something newer with more functionality. I've used Teensy 3.2's for years, they're performant, convenient and are really compatible with arduino sketches. Related to my comment on your PR, they have Another option are the stm32 series microcontrollers, they're available cheaply from various suppliers and can also run Rust. I used an stm32f103 for my displaylight firmware.
Ehh, do you mean the whole request? The blue text? Because, no that's not in the buffer. I never thought that would be relevant, so we don't store it lives here on the stack, if you want to keep that around you'll have to store it in a second buffer. The first byte though is present; Weird is that |
Nope I mean the green 83.
Would that still be true if I can use SoftwareSerial and AltSoftSerial together in schetches that do not use OBD9141? Wonder if 9141 is using some timers or something... I'd love to see the screen in your car, if you're willing to share. I found the official documents for 9141 and 14230. I just dont have the skills to interpret them. You want em? |
Hmm, but it's there, just something with printing looked off, from here;
Somehow the hexadecimal printout is wrong, but the 131 is the green
The only thing that OBD9141 uses is a serial port. It needs exclusive access over that serial port, but it does not matter the serial port is made (or what timers that uses). But yes, the two serials likely both use a timer (or even the same timer).
I actually don't have any photos of my current screen and it's dark outside, but here's a photo from 2016 with the screen in my Kia;
That car didn't have an RPM gauge, so this screen provided that. This one had a PCB behind the screen with transceiver IC and voltage regulator. Plug at the bottom right is just gnd, 12v from accessory connection and the K-line. Very self-contained and modular, mounted on an aluminum bracket on the center console.
Sure, not like I'll be doing any more work on this library, I consider it pretty much done / life support. I answer the occasional issue, but mostly don't touch it. It's been working well enough and I consider it pretty much complete. But having the official docs never hurts, you can find my email from any commit in this repo.
Yeah, I feel these K-line obd ports are less standardized and mostly from the 90s early 00s. The CAN busses are more standardized and have more features I think. |
Hey there.
I've been trying to connect to my VW EDC16 ECU with an arduino.
I have the 33290. It looks like this chip but labeled ZAUO instead of XAIK. I put pin 1 at the square, wasn't 100% sure.
I connected it like this... I also swapped TX and RX pins just in case they were backwards.
I keep getting init_success: 0. How can this be debugged?
If I connect with my ELM327 over COM port with putty, it works. So it's something in the Arduino or chip part of my configuration.
ATSP4 = ISO 14230-4 KWP (5 baud init, 10.4 kbaud). The documentation here mentions 14230-2, could that be the problem?
The text was updated successfully, but these errors were encountered: