I'm curious - what layout software are you using? I suppose I'm going to be the only one who uses gEDA tools.
I think I'm about out of ideas for fuel level. I'm at about half a tank now and that wire I was looking at before hasn't changed. I've gone over every other wire and found no analog levels or digital signals that were unaccounted for. I can only imagine that we're expected to provide the pullup for it, but the instrument cluster must surely already be doing that.
Personally I'm using ExpressPCB just due to the fact that it's free to download and you can order boards right from the program.
I'm trying to target the DIY audience as much as possible, without requiring the purchase of expensive CAD tools.
EDIT: I just looked up gEDA and it's a sweet suite of tools! Has anyone gotten this working on the Windows platform?
I suppose I could run it inside a VM or something...
Regarding the fuel level, is it possible this is being transferred via the diagnostic bus? Did any of your research into talking to the modules yield a fuel-level signal? I wonder if the cluster or DME reports this...
Last edited by m2pc; 07-14-2010 at 05:36 PM.
1999 ///M3 TiAg | Heated Power Vaders | DDM Projector36 5000K 55W HIDs | DDM 3000K 35W HID Fogs
DDM Smoked Corners | DDM Weighted Shift Knob | K&N CAI | Mishimoto AL Rad w/Zionsville AL Shroud
Stewart HiPo Water Pump | Samco Hose Kit | 16" SPAL Puller Fan | Viper 5701LE Security
E36 OBC is now open! Join the effort: BF.C Thread | openOBC Wiki
EAGLE pcb is a good free PCB editor. its limited to a certain board size for the free edition, but i dont think the OBC is big enough for that to be an issue.
http://www.cadsoftusa.com/
sun-roofless artic silver 97 m3, Squid Industries custom SSK, Vogtland club spec springs, Ground Control street camber plates, Bilstein sports, OEM RTABs w/limiters, 8.5 x 17" DSII's, Safety wired oil pump nut, Sway bars (27/stock), conforti tune
According to the ETM, the fuel tank level signal (X1071/9) goes only from the instrument cluster to the OBC. The OBC has a pullup resistor.
My best guess is that the pullup resistor is the "top half" of a voltage divider (because there is no transistor symbol on the instrument cluster side)
No, the diagnostic lines have nothing to do with this, they are really only for diagnostics and coding.
Last edited by jarda; 07-14-2010 at 07:04 PM.
I went poking around again with a weak pullup following my probe. This time I quickly found the 250 baud data on X1071.9 (from instrument cluster.) I see the same byte (well, 12 or so bits) repeated constantly at short intervals. I theorize that this may be the fuel level plus little or nothing else. I believe 8 or 9 bits at minimum are needed for fuel level based on my recollection of how precisely the OBC reports fuel in liters.
This is not entirely on topic, but I thought I'd report it in the company of those who can appreciate the significance and irony.
I doubt anyone expected this event to occur so early on the openOBC's timeline, but as of today the services of an openOBC have already been called upon in a non-demonstration diagnosis and repair of an e36.
I've just pulled my DME back from the brink of death (it's a long story but it involves a car wash) and I have my openOBC (that's what I call it; you may call it spaghetti on a breadboard) to thank, at least in part. Being able to read and clear DME error codes from it while taking care of volcanoes of corrosion and missing solder joints was wonderfully convenient, and I have no other means of doing so. Had this accident happened just a few short weeks ago, this would not have been possible. Even days ago, I'd have had to write a few more functions first. Quite a coincidence that it was just sitting there hooked up and ready to go right when I needed it. This little bundle of joy is going to make a lot of people's lives easier some day when she's all grown up.
Last edited by benemorius; 07-14-2010 at 08:01 PM. Reason: Automerged Doublepost
Express PCB, because is free, sufficient and is what the pcb board vendor will use flawlessly. I do not have the extra hours to fool around with semi-ported solutions or the garage lithography.
It has a schematic and a PCB element, again very simple but sufficient. I hope folks agree.
Good job with the pin9. Indeed the PCB has a 10K pullup to 12V. it must have some pulldown transistor on the cluster output.
I don't think there is a pulldown transistor on the cluster output because
1) these are always indicated in the ETM.
2) pulldown transistors are used to create square waves that carry information in form of frequency, pulse width or duty cycle, but not bytes of data.
If this is not a voltage divider (apparently isn't, wrong guess), then it is direct processor to processor communication over a line pulled high by the OBC, we only have to decode the protocol.
Benemorius - great work
I promise there's a transistor for the cluster output. It's called an open-collector output and it's quite common. The diagnostic lines are another example of this. I can't speak to your number one, but two is simply a misconception. These outputs aren't selected based on the type of signal they're outputting, but on the devices they're outputting signals to. Selection of the transistor itself is where the signal type can come in to play, but that's a different story entirely.
I have a mental idea of what the output looked like today and I'll check it again as I use some fuel. That will be a good indication of whether it will be a simple read. It will be nice if we don't have to actually talk back to the cluster. I expect we won't as Mefis hasn't mentioned any means for the OBC to drive this line low.
Yes, both nr 1 and 2 are only my experience, sorry for presenting it as facts. I'll stop guessing and start doing some actual work again
Also i can promise to you that there where data tranmission lines with resistor and NPN long before I was on diapers....
Moving on... I have not drawn the temp sensor part yet. Seems from the schematic that the temp sensor is a resistor to GND, and the MCU has some circuit to +5V. Perhaps a resistor of 9.91K but then there is some other devices and I am not done tracking them. It could be some kind of circuit to bias the sensor at specific times perhaps?
Has anybody measured the temp sensor resistance?
I've played with the temp sensor a little bit, see my blog http://blog.jaroslavklima.com/2009/1...re-sensor.html
but the second half of it is just theory... never got around to implementing it..
I never doubted that, what I'm saying is that in the diagrams for BMW E36, I've only seen pull down transistors used for the types of signals I mentioned.
Last edited by jarda; 07-15-2010 at 03:05 PM. Reason: Automerged Doublepost
1999 ///M3 TiAg | Heated Power Vaders | DDM Projector36 5000K 55W HIDs | DDM 3000K 35W HID Fogs
DDM Smoked Corners | DDM Weighted Shift Knob | K&N CAI | Mishimoto AL Rad w/Zionsville AL Shroud
Stewart HiPo Water Pump | Samco Hose Kit | 16" SPAL Puller Fan | Viper 5701LE Security
E36 OBC is now open! Join the effort: BF.C Thread | openOBC Wiki
I didn't intend to imply rs232. Baud and serial ports may know each other very well, but they aren't married. Once you've seen the attached image, I won't know anything you don't know.
Is anyone aware of a free c compiler for HCS08? I know SDCC has an HC08 port, but I'm not sure the instruction set is the same.
Regarding the gEDA inquiry that I missed, I don't believe it's a good match for windows. It didn't used to be, and it may actually be worse now than before. Some of the tools do have windows binaries, and running it all under cygwin should work, but I doubt either case would make for a very pleasant experience.
It'd be interesting to drive around with someone riding shotgun and watch this signal as the fuel gets consumed... or check it at various tank levels (full, 1/2, empty, etc.).
Either that or synthesize your own signal with an MCU and feed it to a stock OBC to see what the OBC reports as the "range" value.
1999 ///M3 TiAg | Heated Power Vaders | DDM Projector36 5000K 55W HIDs | DDM 3000K 35W HID Fogs
DDM Smoked Corners | DDM Weighted Shift Knob | K&N CAI | Mishimoto AL Rad w/Zionsville AL Shroud
Stewart HiPo Water Pump | Samco Hose Kit | 16" SPAL Puller Fan | Viper 5701LE Security
E36 OBC is now open! Join the effort: BF.C Thread | openOBC Wiki
Ok, I previously argued that pin 9 of X1071 was "engine speed" (RPM) but I was wrong.
Looking back, I remember having to grab the RPM signal from the climate control module, of all things. It's found on Pin 18 of X18155 (climate control module connector). Why the climate control module needs to know engine RPM, I have no idea, but it's there.
This goes to the cluster at pin 20 of X16 (crank RPM sig.), the EGS for auto transmission cars, and to the DME.
So, Pin 9 _must_ be fuel level, encoded to digital!
1999 ///M3 TiAg | Heated Power Vaders | DDM Projector36 5000K 55W HIDs | DDM 3000K 35W HID Fogs
DDM Smoked Corners | DDM Weighted Shift Knob | K&N CAI | Mishimoto AL Rad w/Zionsville AL Shroud
Stewart HiPo Water Pump | Samco Hose Kit | 16" SPAL Puller Fan | Viper 5701LE Security
E36 OBC is now open! Join the effort: BF.C Thread | openOBC Wiki
You reminded me that I have found the reason why we can't read RPM from the injector signal:
When you release the gas pedal, there is a short period of time when the injector is fully closed for several revolutions of the engine - the signal is flat and you don't know for how many revolutions.
1999 ///M3 TiAg | Heated Power Vaders | DDM Projector36 5000K 55W HIDs | DDM 3000K 35W HID Fogs
DDM Smoked Corners | DDM Weighted Shift Knob | K&N CAI | Mishimoto AL Rad w/Zionsville AL Shroud
Stewart HiPo Water Pump | Samco Hose Kit | 16" SPAL Puller Fan | Viper 5701LE Security
E36 OBC is now open! Join the effort: BF.C Thread | openOBC Wiki
So I guess the solution to gathering engine RPM is either:
a) Jump a wire from the climate control to the openOBC
- or -
b) Derive this signal from the diagnostic port interface.
Did anyone figure out b), or are we still trying to locate this?
1999 ///M3 TiAg | Heated Power Vaders | DDM Projector36 5000K 55W HIDs | DDM 3000K 35W HID Fogs
DDM Smoked Corners | DDM Weighted Shift Knob | K&N CAI | Mishimoto AL Rad w/Zionsville AL Shroud
Stewart HiPo Water Pump | Samco Hose Kit | 16" SPAL Puller Fan | Viper 5701LE Security
E36 OBC is now open! Join the effort: BF.C Thread | openOBC Wiki
I think I located RPM in the DME's memory, but I don't exactly recall. If not, only the lack of a proper ADS interface is slowing me down. It's extremely difficult (read: impossible) to change only a few variables when the engine is running. I expect I could have built an interface already if not for being clueless about what's on the GAL chip they all seem to use. I suspect everyone is just copying the same design and code over and over. It would be nice to finally reverse it and break the cycle. These stupid things should be just as cheap and plentiful on ebay as the OBD interfaces.
Finding the RPM isn't really the concern though. It's the fact that talking to the DME is worse than pulling teeth. Waking it up for communication takes more than 2 whole seconds (only 10 bits sent, but at *5* baud!!) and you can't talk to anything else on the bus without waiting >250ms for it to sleep. That means of course another >2 seconds to wake it up again. Not to mention, normal communications with it are only at 9600 baud which may not seem so bad except that each and every byte sent must be acknowledged with its complement, and each message sent is acknowledged with another message. So much unnecessary precaution. It spits out ram dumps so slow I can actually read the bytes as they mosey across my terminal. If you can't tell, I've been furious with BMW for the past few weeks.
Too bad about the injector trace. More than just a short while after closing the throttle - we'd lose it for the complete duration of any moderate engine braking.
Last edited by benemorius; 07-16-2010 at 02:51 PM. Reason: two madfaces weren't enough
Wow, so I guess the easier approach for now would be to steal the RPM signal from the climate control module. I did this before for an RPM-activated switch project I was building.
1999 ///M3 TiAg | Heated Power Vaders | DDM Projector36 5000K 55W HIDs | DDM 3000K 35W HID Fogs
DDM Smoked Corners | DDM Weighted Shift Knob | K&N CAI | Mishimoto AL Rad w/Zionsville AL Shroud
Stewart HiPo Water Pump | Samco Hose Kit | 16" SPAL Puller Fan | Viper 5701LE Security
E36 OBC is now open! Join the effort: BF.C Thread | openOBC Wiki
Couple things:
How does the instrument cluster get the RPM? through a dedicated pin from the DME? I remeber playing around with the "hidden" modes of the insturment cluster where you can get the oddometer diplay to show RPMs in real time.... Just wondering if that data does not come from the data bus. That one does not seem to take 2 seconds to start....
Regarding the temp, I think that the complicated circuit on the temp input may be to accomodate two pullup regimes. The nice plots from Jarda show that accuracy at low temps decrease, so maybe they change the pullup value at different temps.
The ADC is 10 bit, so 3mV per bit, taking a worst case of ~ -10C the precision could be better than 1/2 C. In the 20C case is for sure better than 0.1C
I think this is sufficient (a simple pullup), perhaps the stock OBC has a lower accuracy needing the fancy multi-pullup thing, or they do not have on-board ADC and the comparator is doing some kind of ADC. In any case i think we can stick to the single pullup design, unless anybody has any other inputs?
also... just wondering why rpm is so important folks? Any crucial calculation in the OBC?
Last edited by Mefis; 07-16-2010 at 05:21 PM. Reason: Automerged Doublepost
Bookmarks