Feeler: Open Source OBC Firmware

[m2pc]

Thanks! I think you should be able to talk to all your modules with any OBD ediabas adapter and INPA in OBD mode as your e36 is 96+. You might try shorting the txd and rxd lines together. Your adapter may only be transmitting on txd and any module listening on rxd wouldn't hear it. As I recall, this doesn't impair communications in OBD mode. And certainly it can cause no physical harm.

Is this the "Pin 7 & 8 shorting" I keep reading about, in the connector? My interface goes from DB9F -> OBDII 16 pin -> Round Diag 20 pin. It's the 16 pin connector that needs pins 7&8 linked, correct?

[benemorius]

Is this the "Pin 7 & 8 shorting" I keep reading about, in the connector? My interface goes from DB9F -> OBDII 16 pin -> Round Diag 20 pin. It's the 16 pin connector that needs pins 7&8 linked, correct?

Actually, that may be what I meant to suggest. After a second thought, I seem to recall that your car wouldn't even have an rxd pin to short to txd as I suggested. I should be of much more help once I've had enough time to get back in to the right mindset. I think I've left myself enough to go on in this thread. I just need to read over it again.

Also I ninja'd a bit more info into my last post you may find relevant. Hopefully I didn't just do it again.

[benemorius]

I should say that in any case, you would certainly want to try the modification that you speak of if you can't talk to everything. I know it made the difference for a number of people, whatever it was.

[benemorius]

I played with INPA further this morning and found the ZKE and KOMBI aren't responding...

Does everything else work? Climate control? ABS? OBC?

[Joylove]

Is this the "Pin 7 & 8 shorting" I keep reading about, in the connector? My interface goes from DB9F -> OBDII 16 pin -> Round Diag 20 pin. It's the 16 pin connector that needs pins 7&8 linked, correct?

Pin 7 to 8 shorting is for full OBD2 cars E46/E39 onwards. There are two OBD2 K lines populated to pins 7 & 8 on cars post 09/2001, they made the change at the same time as deleting the round 20 pin connector. Your car won't have pin 8 populated.

One of needs to read ADS_DOCU to find out if RxD is a full on data line or a RTS/CTS/DTR/DTS type line.

[m2pc]

Does everything else work? Climate control? ABS? OBC?

I tried the DME (worked)
I tried the ZKE (no response)
I tried the OBC (no response)
I tried the KOMBI (no response)

So the bus I'm accessing is mainly the DME (and possibly the EGS, but haven't tried that module)

[m2pc]

Pin 7 to 8 shorting is for full OBD2 cars E46/E39 onwards. There are two OBD2 K lines populated to pins 7 & 8 on cars post 09/2001, they made the change at the same time as deleting the round 20 pin connector. Your car won't have pin 8 populated.

One of needs to read ADS_DOCU to find out if RxD is a full on data line or a RTS/CTS/DTR/DTS type line.

I translated the document using Google Translate. See attached. It _appears_ that one of the lines is used as some sort of "bus select" line to determine which modules to talk to?

TX Send To control unit, depending on DTR line or TXSG RXSG

DTR SteuerleitungfürUmschaltungderSendeleitungzumSG DTR = -12V: Senden auf RXSG DTR = +12V: Senden auf TXSG

[benemorius]

One of needs to read ADS_DOCU to find out if RxD is a full on data line or a RTS/CTS/DTR/DTS type line.

It is of the same type as txd. Upon module selection in INPA, a series of slightly different packets are sent out. First it tries them on txd, then it tries them on rxd. (well, for some modules it only tries one or the other) The idea being that the module will reply back when it receives the correctly structured packet on the correct line. From what I've seen, all my modules reply back and carry out their conversation on txd regardless of which line the opening query came on.

[benemorius]

I translated the document using Google Translate. See attached. It _appears_ that one of the lines is used as some sort of "bus select" line to determine which modules to talk to?

That is correct. When INPA asserts dtr, it expect an ads interface to transmit on txd. Otherwise the transmissions go out on rxd.

[Joylove]

It is of the same type as txd. Upon module selection in INPA, a series of slightly different packets are sent out. First it tries them on txd, then it tries them on rxd. (well, for some modules it only tries one or the other) The idea being that the module will reply back when it receives the correctly structured packet on the correct line. From what I've seen, all my modules reply back and carry out their conversation on txd regardless of which line the opening query came on.

Top posting. Maybe (looking at the translated PDF) we just need to tie RxD to +12V and talk/listen on TxD.

[benemorius]

Do I need a stronger pullup on the TXD line? I noticed the vehicle has 820Ohms, whereas I'm using 10K Ohms.

Yes I believe you will. Check your rise times with a scope. I suspect 10k is vastly insufficient for any communication.

[benemorius]

Top posting. Maybe (looking at the translated PDF) we just need to tie RxD to +12V and talk/listen on TxD.

No. The "older" modules (my dme with 100% certainty) must see their data packet on rxd to initiate communication.

[benemorius]

Ok, I can now optimistically suggest that you try shorting pins 17 and 20 in your 20 pin port under the hood. This should bridge the engine/tranny k line with the chassis k line. Or so I believe.

PS: We're really free of automerging? Yay!

[Joylove]

No. The "older" modules (my dme with 100% certainty) must see their data packet on rxd to initiate communication.

So according the to diagram inside ADS_DOCU, where DTR is only used to gate data in the ADS interface, combined with a shorted TxD and RxD, a single K line transciver could conceivably talk DS2 over USB.

[m2pc]

Ok, I can now optimistically suggest that you try shorting pins 17 and 20 in your 20 pin port under the hood. This should bridge the engine/tranny k line with the chassis k line. Or so I believe.

PS: We're really free of automerging? Yay!

Hmm, I cracked my eBay 20-pin connector open and pins 17 and 20 are already joined together.

I noticed that the 20-pin diag cap shorts pins 15 and 20 together (RXD and TXD) and pulls them to +12V with an 820 Ohm resistor.

Maybe I should try shorting all the data lines together (RXD, TXD, TXD2) and see if I can talk to all modules then?

[benemorius]

So according the to diagram inside ADS_DOCU, where DTR is only used to gate data in the ADS interface, combined with a shorted TxD and RxD, a single K line transciver could conceivably talk DS2 over USB.

Absolutely it could. The only reason we have to muck around with anything more complicated than the simple solution you describe is that ediabas and company are not programmed with such universal simplicity in mind. For example, inpa is intolerant of hearing its own echo on the serial rx when it sends something on the serial tx. The ads interface uses dtr to mute serial rx.

If we had open source software to replace bmw's tools, we could in fact have such a universal interface.

[benemorius]

Maybe I should try shorting all the data lines together (RXD, TXD, TXD2) and see if I can talk to all modules then?

Once again, absolutely worth a try given the simplicity of doing so. I did lots of shorting things together before I arrived at a working solution.

[m2pc]

Absolutely it could. The only reason we have to muck around with anything more complicated than the simple solution you describe is that ediabas and company are not programmed with such universal simplicity in mind. For example, inpa is intolerant of hearing its own echo on the serial rx when it sends something on the serial tx. The ads interface uses dtr to mute serial rx.

If we had open source software to replace bmw's tools, we could in fact have such a universal interface.

Aha! That must be why when the 20-pin cap is removed, it no longer shorts together RXD and TXD. So INPA can talk and not get confused by itself.

So theoretically we should be able to, with the cap in place, use the X1071 pins in the dash to talk to all modules, if we code it right so that it ignores its own local echo while transmitting?

[benemorius]

So theoretically we should be able to, with the cap in place, use the X1071 pins in the dash to talk to all modules, if we code it right so that it ignores its own local echo while transmitting?

This has long been my understanding, but now that I'm looking at the schematics for your newer e36 I'm wondering whether you can reach your dme and egs from X1071 without bridging 20 and 17 in the 20 pin cap.

[Joylove]

The 1 wire K line transciever TH3122 inside the USB OBD2 plug already isolates the echo from the RS232 Rx. The k line is bidirectional, and to enable that, there is a TxD lockout pin from the TH3122. This may need to be connected in such a way that the USB-RS232 port talks in half duplex. This is probably why INPA needs a large software buffer edit to the registry.

[benemorius]

The 1 wire K line transciever TH3122 inside the USB OBD2 plug already isolates the echo from the RS232 Rx. The k line is bidirectional, and to enable that, there is a TxD lockout pin from the TH3122. This may need to be connected in such a way that the USB-RS232 port talks in half duplex. This is probably why INPA needs a large software buffer edit to the registry.

The trouble (I think) is that in obd mode, inpa does actually want the echo. I admit I'm less certain about that one, but I do seem to recall that being one of the defining differences between ads and obd mode.

[Joylove]

The trouble (I think) is that in obd mode, inpa does actually want the echo. I admit I'm less certain about that one, but I do seem to recall that being one of the defining differences between ads and obd mode.

Easily fixed with a diode.

The thing that confuses me is that the SEN(STA) [gate] line must be in place already for OBD2 applications. Yet these adaptors aren't working out of the box.

[benemorius]

Easily fixed with a diode.

Sure. I'm just highlighting that the static nature of bmw's software is what's preventing the tangled web of interfaces and busses from being as consolidated and convenient as they could and should be. In other words, talking to every module in the car through usb (older/ads modules included) is easily possible - just not with bmw's software.

[benemorius]

Here is a more appropriate rendition of the interface I now use with inpa. It's an ads interface based on bmw's ads schematic. It is functionally similar to the one I posted many pages ago. I just reworked it for better diy consumption. I don't remember exactly what it will do in obd mode, and ads mode is only an option on a real windows pc with a serial port located at 0x3F8.

The car-side signals are marked k and l line. I attach these to txd and rxd in the obc harness. I can talk to everything this way, but as I said I don't know that later models will be the same. I'd expect that I could also hook it up to 15 and 20 in the 20 pin under the hood. I'd expect also that you could too, with an extra jumper from 20 to 17 to get to the dme and egs.

I did have to send the opening packet to my dme at 5 baud, but I believe obd-II cars don't have such an ugly requirement. Literally everything else that I (and inpa) do on my car is at 9600 baud. It is my (much faded) understanding that 10.4k will be the rate for obd-II cars. I haven't seen anything that fast on my car.

I'm going to get set up to capture inpa traffic on my car again for a refresher. I'm struggling to understand how you can reach your dme but not zke with the 17-20 bridge. I think my zke communication and yours should be simliar. Let me know if you get it working in the mean time. It may take me a while to gather my things and get going depending on how murphy feels about me today.

[benemorius]

It looks like I may run out of hands-on time today before I can get my breadboarded circuit working again. I'm always kicking myself for not having made something more permanent yet. I'm keeping everything in my car with me though so I'll get back to it if I get a chance. Given the choice, I'd always rather be doing this stuff anyway. Better luck to you! Hopefully I've distracted murphy enough just now to let you scrape by unnoticed.