According to the Bentley diagrams I'm looking at, the RPM signal originates from the DME and then gets split off to the EGS, Climate Control Module, Instrument cluster and in some years, goes to the Data Link Connector.
I'm not 100% sure we _need_ the RPM signal, but it's yet another vehicle parameter we can use if we have access to it. Things like logging RPM vs. vehicle speed/time can be useful for track purposes, etc.
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'm inclined to agree about the temperature sensor. We're replicating electronics from two decades ago. It stands to reason that we'll be doing a lot of things differently now.
I myself have no particular need for RPM separate from datalogging, but I started or at least perpetuated the idea that we could get it from the fuel consumption signal so I suppose I felt the need to assist in stamping that idea back out again.
Yes, long before ADCs were common features of microcontrollers, all manner of schemes were used to approximate an analog voltage as a digital signal.
There could be a simple RC circuit where the capacitor C is constand, and thermistor forms the "R" component and the OBC MCU sets a pin low and times the charge/discharge rate to determine the resistance.
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
IMHO the best place to get the RPM signal is the splice panel under the left side of the dashboard. Just add our own faston. The RPM wire color is solid black..
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
Yes, there are several splice panels all over the car, basically all signals shared by more than two units...
I knew about these "splice blocks" but I thought it was mainly for power connections.
It's nice to see that BMW engineered these in for our use.
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
Drawing update:
On second thought i will have to stick to a 20 pin "daughter board" instead of a 26 pin, meaning that there will be only 5 GPIO available instead of 7.... there is just no room. Check the pic how J4 overlaps U8 which is the flash card, and i can't move it right because U10 is the bluetooth and it needs clearance for it's antenna.
Anybody knows a bluetooth module significantly smaller than 26mmx19mm and direct weld? (without expensive fancy interconnect headers)...
Final thought on the temp sensor, the PNP pullup connected to the sensor may also be reducing the self-heat error of the sensor, but 3 IO pins for one temp sensor is too much. We'll have to live with the self-heating error....maybe is negligible
Last edited by Mefis; 07-18-2010 at 11:31 AM.
I'm going to call it very negligible, though I welcome anyone to check my math. Given jarda's figures of pulling with 12k ohms to 5v, worst case will occur just above freezing and will be just above 0.5mw. The engine probably contributes more heat than that. Also remember that it's located within the airflow of the left brake cooling duct.
The smallest (and by far the cheapest) bluetooth modules I'm aware of are USB and are not significantly larger than the USB connector. How many of those footprints are through-hole? I wasn't expecting to run out of board space so easily. I think we have plenty of room behind the OBC to stack two boards together and almost double the usable space.
Last edited by benemorius; 07-18-2010 at 01:26 PM. Reason: Automerged Doublepost
Only the power output transistors, the power resistors and the connectors are through-hole. Everything else is SMD.
Two boards is what i mean by "daughter board", definitely there is space to stack them except for the bluetooth antenna problem. The thing is that i want to get away with one board to start (one order to express PCB) and implement the radar interface/voice/ anything else later.
Guys,
I have a design proposal for you all. I believe the openOBC users will fall into 2 main groups:
1) Those who want the basic OBC functions, with a few added features, such as oil temp/boost pressure, etc., and
2) Those who want to go "all out" and have bluetooth, GPS, acceleration/G-force measurements, data logging, etc.
I propose we design the openOBC to be modular, sort of like the PC-104 architecture. This would consist of a "base" board which would take care of the display and keypad interface, power supply, RTC (real-time-clock). This base board would have 1 or more "expansion" headers that serve several purposes:
a) to connect to external sensors when only the basic configuration is used, and
b) to link to the expansion board
c) to allow anyone to create their own external board without having to redesign the whole system
The expansion board could contain the more advanced features such as the bluetooth and GPS radios, accelerometers, and more analog and digital I/O to connect to the vehicle.
This is where we could also have a radar detector interface, voice module, etc.
I believe approaching the project in this manner will allow us to get off the ground quickly and expand as time and funds permit.
The tendency is to try and pack as much as possible into the design from the get-go (I do this all the time with my projects), but I'd much rather get something simple working first, then move on to more advanced features.
My personal goals for this project are:
- Simple for anyone with soldering skills to build (meaning: through hole as much as possible)
- Modular
- Easily expanded
Thoughts?
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
Well I can only speak for myself, but I think we're all thinking along roughly the same line. I don't have much more than the basics on mine plus an odd thing or two and I'm going to end up with a ton of unused IO pins so I was hoping to have two long rows of headers along the top and bottom for fitting a custom second board.
We should keep in mind that just because there's a spot for something on the board doesn't mean anyone has to put something there. I think it's worth trying to make each board revision as useful as it can reasonably be given the cost of ordering prototype quantities. I don't see myself getting my hands dirty with bluetooth or GPS until I have a solid OBC again, but it will certainly be a plus if I can just drop them in when that time comes.
I was even going to see about surrounding the microcontroller with headers so that a small daughter board can be fitted instead. This would allow anyone to fit a microcontroller of their choosing - even a DIP on protoboard if one should so desire. I'm all about leaving the possibilities as limitless as possible.
Speaking of which, I haven't seen much talk of micros recently. As I'm rather certain this project has already outgrown most 8 bit options, it seems like it might be worth some discussion. With the prices so low in recent years, I have a hard time finding a reason to not go straight for 32 bit. I have NXP's LPC17xx series in mind unless Atmel changes that with their upcoming cortex-m3 devices. It has USB host/OTG, a hell of a lot more flash and ram than any 8 bit, and it has a serial bootloader in ROM straight from the factory, making programming absolutely as easy as it could be for DIY users with no programmer. Plus, changing the micro later on down the road is one of the more costly things we could do (board and code redesign.) We would do well to not short ourselves on this one. Anyway, what do you guys have to say on the matter?
I agree it would be nice to get this thing off the ground already. I think perhaps the best thing we could do right now is get some simple development hardware out to those who can and will work on programming. There are a lot more C coders out there than EEs and we need to find out who they are and who among them are willing to contribute. They could be hacking out code while we're still working on hardware. There's a lot of code that can't really be written yet, but that doesn't change the fact that there's a heck of a lot that can be. Also I think this in itself would stir up some productive excitement.
Soldering might be the only place where I'll admit to a slight disagreement. I very much prefer SMD work and I've seen similar comments from other hobbyists. It's not as intuitive as through-hole, so some initial guidance is warranted, but once you know what you're doing I think it's less trouble. I've even taught my wife to solder SMD. We skipped through-hole entirely and went straight for a QFP64. I didn't tell her it was a difficult task, and consequently it wasn't. I don't think there will be any way to avoid using an SMD micro, and if one can solder that then one can solder everything else too. Likewise if one can't solder it, then the task of soldering everything else becomes irrelevant anyway.
This is only my opinion, and I offer it humbly. I think we've lost most of our audience, especially over the last few pages. If only this link wasn't still returning a 404 we could put up polls there for exactly these kinds of things.
I don't think you have lost your audience but rather the audience does not have a real understandable question to answer. I know I am very interested in this project but my knowledge of programming is little so there isn't much to add to the current convo about the technical specs, etc.
I would agree on the notion of building a primary and secondary "optional features" board just for the ease of getting things on the ground and real for everyone (and less expensive platform to build from).
I think you have a big audience. I have been checking every post made waiting to see when this is done and workable and ready to be installed in my car. Like the previous post said, we probably just don't know what language you are speaking when you are talking about through hole and all that other stuff. We are just waiting for a working finished product...
Sounds like a good plan guys. Have a basic board that will do the 'Primary' features, with room for expansion for those who want it all.
Ok.. few things:
a) I do not think thrugh hole is viable. My schematic has 66 resistors and 10 diodes just for the existing OBC functions. Can you fit 76 through hole resistors plus a 40 pin dip plus 20 somethign capacitors into the board?
Through hole are those devices with legs that go thorugh a hole in the board. SMD have tiny (0.8mm, 0.6mm) legs that are welded to the surface of the board.
b) the thing is that I do have a freescale (ex motorola) HSC08 microcontroller experience and the development connector. I do not feel like buying anythign else for hundreds of dollars at the moment. Also they offer this programming header in open source (or you pay $50 to get one shipped to you). $50 is probably the retail cost of everythign that goes in it. Freescale provides the codewarrior software.
c) I can draw the board with a header and the stuff i described before. It has the SPI bus, so anyone can draw an expansion board with a 40 pin dip and a slave SPI in it??
d) a lot of folks may need to "buy" the finished product. I think me and others are comitted to open source on everything, but i am sure a number of people do not weld very well, or may not have the patience for 300-500 welding points...hole or smd...
also folks... i feel i got some obc-fever. is pretty bad and i may not be able to stop until i finish this drawing and start welding the parts .....
let me explain further the bluetooth. Bluetooth is not just the stuff that goes into your ear. Is a standard that enables audio, data, fax, etc over radio. In the case of the open OBC, i plan to use it as a substitute for a COM port. It is basically acting as a serial COM port over a radio bridge.
The vision is that anybody hops on the passenger seat with a bluetooth enabled laptop and reads the data off the openOBC without any wires.
The bluetooth module that i want to draw in the board is about $30 bucks.
Last edited by Mefis; 07-20-2010 at 12:46 PM. Reason: Automerged Doublepost
Ok, design discussion aside, I finally confirmed X1071/Pin9 is the fuel tank level signal. Check this out from the "E36 Electrical Troubleshooting Manual":
Benemorius, have you gotten any further in decoding this serial signal?
This bit of info (from the E36 cluster test documentation) may help decode which values mean what fuel level:
Looks like an 8-bit value to me...Test 6: Fuel Level and coolant temp. - Display of hexadecimal codes in
relation to gauge position.
Fuel gauge ----> Hex value
A (empty)---------> 0d
End of reserve---> 37
B-------------------> 54
C-------------------> 90
D------------------> c4
E (full)-----------> f0
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 don't have enough data to make anything more than an educated guess at this point. I've been recording the changes every time I drive it, but that isn't very often.
Reading the middle 8 bits least significant first (the hex I added) is the only way that makes sense to me given what we know so far, but that could still change with more data.Code:01 0111 0101 000 0xae 00 1111 1110 001 0x7f 01 0110 0110 001 0x66
I'll probably continue recording changes, but I think being sure that this is fuel level is sufficient for now. It's enough to be confident that we're doing the hardware correctly, and this sort of investigation will be much more convenient once the hardware is in place. I mostly just wanted to confirm that what I was seeing wasn't a query from the cluster to which we would need to reply in order to procure information from it.
Update: Today I finally got the PIC talking to my OBC display; I had the "unknown" pins tied to LOW and HIGH and it turns out to reset the display, one needs to pulse them low and then high again in code.
A "pic" of my PIC driving the display is attached.
I also drew up a draft of my version of the OBC prototype hardware; I'll post this up tomorrow once it's finalized. I found some really neat expandable driver ICs that will allow us to drive an infinite number of 500mA loads from a single 3-line interface.
Last edited by m2pc; 07-22-2010 at 09:34 AM.
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
That is cool!!!
WHat do you mean by unknown pins? Last time we discussed we had the following: Which of these is the "unknown" pin?
1 +5V
2 gnd
3 LCD bias (+6, works with +5)
4 fix at 1
5 config strobe
6 data strobe
7 clock
8 data
9 final strobe
10 enable
11 LCD clk
What is the part number for the expansion IO? I was using the MAX7317 which has 10 I/O with open drain and also can read the state back, but a) comes in SMD only and b)the max current drive is only 18mA.
Thanks!
Last edited by Mefis; 07-22-2010 at 09:06 AM. Reason: Automerged Doublepost
I copied the naming convention from Benemorius; pins 4 and 10 are marked "unknown" in my diagram. I haven't tried tying pin 4 high and using pin 10 as an enable. I'll modify my C code and report back.
As for the driver, I'm going to be using one of these: http://focus.ti.com/lit/ds/symlink/tpic6b595.pdf
8 channels, 150mA per channel, 3-wire interface. It has built-in clamping diodes, perfect for driving relays.
By providing 3 extra pins on an expansion header and modifying code, it's possible to expand this to any number of I/O pins.
According to my research, we need 7 high-current, open-drain outputs:
1) Check control lamp
2) Independent ventilation relay
3) Alarm siren relay
4) Main display backlight
5) Secondary display backlight
6) Gong pin 2
7) Gong pin 3
That leaves 1 extra for controlling an external relay, etc.
The IC comes in 18-DIP and SOIC, so it's a flexible solution in my opinion.
Last edited by m2pc; 07-22-2010 at 09:28 AM.
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 also had to pulse 4 and 10 low before writing to the LCD. It's sounding like none of us knows for certain what exactly they're for.
Ok, I just confirmed; tying 4 low doesn't affect the display. I'm currently only pulsing 10 low on startup and leaving it high during the LCD operation.
Pulling 10 low during LCD operation causes the LCD to stop clocking. I'm calling 10 an ENABLE line at this point, and leaving 4 connected to GND.
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 reported 2 pages ago that i pulled pin4 down and somehow got "stock" messages such as "CHECK OWNER MANUAL" in various languages. Pulling pin4 up i got normal operating conditions.
I like your TI chip, it is MOSFET and perfect for replacing some devices, but the minimum VCC is 4.5V (designed for 5V). I'll try to find a 3.3V version from TI.
Last edited by Mefis; 07-22-2010 at 11:21 AM. Reason: Automerged Doublepost
I'm still finding this hard to believe -- are you sure you had the stock OBC logic board completely out of the picture when you did this? The display is just a pair of driver ICs that shouldn't contain any stored messages. Unless BMW partnered with ST micro and had these custom-made, the only place these messages could come from is the original OBC board.
Besides, we've all observed the "INPUT TIME" message come across from the logic board; why would this not be embedded in the display as well?
As for the 5v/3.3v dilemma, I'm using 5V on my design, just because a) many parts support it, and b) if I need 3.3V for any parts, it's easier to obtain from a 5V source (I can drop it down using some diodes).
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
Bookmarks