Bavarian Soundwerks
Page 19 of 79 FirstFirst ... 910111213141516171819202122232425262728294469 ... LastLast
Results 451 to 475 of 1959

Thread: Feeler: Open Source OBC Firmware

  1. #451
    Join Date
    Jul 2010
    Location
    Greenville, SC
    Posts
    49
    My Cars
    2002 996tt
    Quote Originally Posted by jarda View Post
    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..
    Cool!

  2. #452
    Join Date
    Sep 2006
    Location
    Bahrain
    Posts
    197
    My Cars
    1994 325i - 1992 525i (SOLD) - 1983 E23 (soon?)
    I just finished reading 18 pages. Seeing others doing what I always wanted to do is great.
    Sadly, my EE skills are barely enough to understand what is going on. Participating in the reverse engineering or Electronic design process would be hard for me, but I am ready to jump in when it's time for coding.

    Up until this point, there are 18 pages on this forum with valuable info scattered all around, not to mention the code that has already been written and all the references to other documents online. I think what we really need right now is a wiki to put together everything we have until this point.

    m2pc: Thank you for starting this thread. You're doing a great job.
    benemorius: You're doing great things. Let us see more of your schematics and code.
    Mefis: Great job keeping it up since the start of this thread.
    nuvola rossa & jarda & everyone else: valuable info & resources. I'm hoping that I'll be part of this group and help this project as much as possible.

    I'm very excited.. Now let's get that wiki started

  3. #453
    Join Date
    Apr 2007
    Location
    Yorba Linda, CA
    Posts
    3,781
    My Cars
    1999 TiAg M3, 2003 E46M3
    Quote Originally Posted by alkumaish View Post
    I just finished reading 18 pages. Seeing others doing what I always wanted to do is great.
    Sadly, my EE skills are barely enough to understand what is going on. Participating in the reverse engineering or Electronic design process would be hard for me, but I am ready to jump in when it's time for coding.

    Up until this point, there are 18 pages on this forum with valuable info scattered all around, not to mention the code that has already been written and all the references to other documents online. I think what we really need right now is a wiki to put together everything we have until this point.

    m2pc: Thank you for starting this thread. You're doing a great job.
    benemorius: You're doing great things. Let us see more of your schematics and code.
    Mefis: Great job keeping it up since the start of this thread.
    nuvola rossa & jarda & everyone else: valuable info & resources. I'm hoping that I'll be part of this group and help this project as much as possible.

    I'm very excited.. Now let's get that wiki started
    Thanks for the compliments, and excellent idea on the Wiki. I'll look into putting one up shortly. I've started a document detailing all I know about the interface, which I will be completing and placing online soon.

    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

  4. #454
    Join Date
    May 2007
    Location
    US
    Posts
    942
    My Cars
    '94 325i / s13
    I've managed to figure out at least some of what the ADS interface is supposed to do and I have a circuit working with INPA now which I'm attaching. I'll probably start a new thread in the relevant section and post it there too at some point, but I don't think it's entirely off topic here.

    The significant difference is that the DTR line controls whether the k or l line will be driven by TXD. INPA can now talk to every control module with one exception. It still doesn't work with the damn DME. It makes sense that I'm still missing an important aspect of the interface, though that isn't necessarily what the evidence seems to suggest. Communication does actually occur and appears normal, but breaks down at the end of the first packet from the DME. INPA refuses to acknowledge the packet and request the next, instead simply acking the last byte of the packet over and over until it gives up. I haven't decided how to proceed yet, but I expect I'll figure it out sooner or later. If I can't and no one else does, figuring out how to request live data from the DME is going to be an extremely painful and incomplete process.

    On a brighter note, we have some pretty cool features to work with now. Some of the most useful are:

    -wheel speed from ABS (low tire pressure warning)
    -all kinds of temperatures (coolant, heater cores, evaporator core, cabin, ventilation intake...)
    -activation of countless test/diagnosis/repair functions
    -reading and clearing of diagnostic codes from all modules (I just found a few things to fix that I wasn't even sure were broken)
    -recoding modules from the OBC for swaps/mods/features
    -some other stuff I can't remember

    I have no further code or schematics right now. I don't make a habit of withholding information.

    Also, unlike communication with the DME, queries are quick and responsive for all other modules. Only the DME seems determined to throw a wrench into the works.
    Attached Images Attached Images
    Last edited by benemorius; 07-25-2010 at 11:42 PM.

  5. #455
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    Benemorious:

    Good work, but seems that this bus is still not a close issue.

    In your previous diagram you drive both lines and you listen on pin5 (TX). Not clear why you would drive both lines with the same data.

    On the recent circuit it seems that DTR toggles on when RX is driven, but again the same is true for the TX line.

    Consider the stock schematic. The stock OBC listens the RX line (input only) and can transmit or receive on the TX line (bidirectional open collector).

    This is consistent with an address being broadcasted by the RX line and a response/ack issued on the TX line.

    Apparently the stock OBC is some kind of a "slave only" device in the bus because it can not broadcast an address through the RX line. I understand we want to be able to drive both, but If you drive both with the same data, aren't you going to disturb other modules listening?


    Another alternative: COnsider the OBD-II wire. The BMW schematics show that the single wire OBD connector goes to the ECU and transmission modules only. How about wiring that to the openOBC and turning the openOBC into an OBD reader. We can plug one and monitor how is that all that data is reported from the ECU to the OBD reader. just a thought.
    Attached Images Attached Images
    Last edited by Mefis; 07-26-2010 at 04:46 PM.

  6. #456
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    Now an update on my first prototype drawing. It is perhaps 40% done but I still have a lot of lines to draw. Again i do not think i can do a hole-only version.

    The horizontal yellow line is where the screen board actually comes very close to the OBC board, hence no device can be placed along that line (no bottom device) while the vertical yellow lines mark the height limit because of the plastic box.

    Also note 2 rectangular holes about mid height. Those are the plastic clips that will hold the board in place. of course those also limit the placement of devices on the board.
    Attached Images Attached Images

  7. #457
    Join Date
    May 2007
    Location
    US
    Posts
    942
    My Cars
    '94 325i / s13
    Quote Originally Posted by Mefis View Post
    Benemorious:

    Good work, but seems that this bus is still not a close issue.

    In your previous diagram you drive both lines and you listen on pin5 (TX). Not clear why you would drive both lines with the same data.
    The simple reason is: because it didn't work otherwise. Many OBD ediabas interfaces are wired like this, and those that aren't are sometimes modified by their users so they work properly. Some modules are listening to one line, and some listen to the other. Driving both does no harm, or at least it didn't until I put ediabas into ADS mode. In ADS mode, it didn't like hearing its own echo on the k-line when it thought it was only transmitting on the l-line
    On the recent circuit it seems that DTR toggles on when RX is driven, but again the same is true for the TX line.
    I'm not sure I fully understand what you're saying, so I'll just explain in patronizing detail. DTR is an output from the serial port. DTR switches TXD between driving the k-line exclusively and driving the l-line exclusively. It does this by either disrupting the emitter connection of the k-line driver, or by grounding the base of the l-line driver. When ediabas switches DTR high, the data coming out TXD drives the k-line. While low, it drives the l-line.

    Consider the stock schematic. The stock OBC listens the RX line (input only) and can transmit or receive on the TX line (bidirectional open collector).

    This is consistent with an address beeing broadcasted by the RX line and a response/ack issued on the TX line.

    Apparently the stock OBC is some kind of a "slave only" device in the bus because it can not broadcast an address through the RX line. I understand we want to be able to drive both, but If you drive both with the same data, aren't you going to disturb other modules listening?
    All correct, but no, nothing gets disturbed by this. And I'm not driving them together anymore anyway. My understanding has passed the point where that was necessary.

    You're right - the issue is still not closed. I still don't have DME communication working, and as much as it looks like a software problem with INPA/ediabas, it is most probably a hardware problem with my interface. The hardware that we need to include in the openobc will not change. We need the ability to drive (separately) the k and l lines, and we need the ability to receive on the k-line. I need to somehow modify my interface only so it can work with INPA/ediabas, and only because I need to then analyze the data going back and forth so we can send the right queries to the modules and understand the replies.

    Quote Originally Posted by Mefis View Post
    Now an update on my first prototype drawing. It is perhaps 40% done but I still have a lot of lines to draw. Again i do not think i can do a hole-only version.
    Awesome progress. Do you mind sharing the schematic?

    I'm curious about how you're handling power regulation. I haven't drawn anything in or selected any parts yet myself. I forgot to hook up my battery charger the other day and it reminded me that we're going to need to be careful about power consumption and efficiency. The linear regulators we all have on our breadboards right now certainly won't do. With space already as tight as it is, making room for switched regulation is not a welcome prospect, but it is a necessary one.
    Last edited by benemorius; 07-26-2010 at 05:20 PM. Reason: Automerged Doublepost

  8. #458
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    Oh!!! i missed that the DTR is tying the base to GND, now it makes sense, DTR will select K or L...


    In terms of power, i am going with a national semiconductor "simple switcher" with the inductor build into the power module. I have worked with the national switching power in the past and is a bit complicated to get the right schottky diode, the right inductor and specially the right low ERS capacitor, but now the came up with these modules with the inductor and diode build-in, so you just use the right low ESR cap and done. They claim 90% efficency, so for 100mA @3.3, we will be drawing about 30mA at 12V. 100mA is exagerating my power budget, the main power glutons are the GPS and the bluetooth with ~30mA each.

    and in terms of hardware for the openOBC, you think a general purpose IO is best, or a UART is best?
    Last edited by Mefis; 07-26-2010 at 05:34 PM. Reason: Automerged Doublepost

  9. #459
    Join Date
    May 2007
    Location
    US
    Posts
    942
    My Cars
    '94 325i / s13
    openOBC IRC channel on freenode: irc://irc.freenode.net/openobc
    I'm not sure why I didn't think of this before. It could be rather useful. Well, if anyone else joins me, that is.


    Quote Originally Posted by Mefis View Post
    In terms of power, i am going with a national semiconductor "simple switcher" with the inductor build into the power module. I have worked with the national switching power in the past and is a bit complicated to get the right schottky diode, the right inductor and specially the right low ERS capacitor, but now the came up with these modules with the inductor and diode build-in, so you just use the right low ESR cap and done. They claim 90% efficency, so for 100mA @3.3, we will be drawing about 30mA at 12V. 100mA is exagerating my power budget, the main power glutons are the GPS and the bluetooth with ~30mA each.
    How low is the quiescent current draw? Can I ask for a part number?
    and in terms of hardware for the openOBC, you think a general purpose IO is best, or a UART is best?
    For the diagnostic lines, you mean? A UART will certainly be preferable if one is available. Everything is standard 9600 8n1 except the slow initialization for the DME. I'm having to do that in software because I can't run the baud rate generator that slow without sacrificing main clock speed.

  10. #460
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    I apologize.. i do not have it here (work). also, i am forced to use a microsoft product and probably has irc blocked.

    But it does have an enable line and I am sure the off current is pretty low. I guess we have to discuss the power scheme. I was thinking of using pin 8 for the main power, and using the acc line (PIN 14) to enable the power regulator.

    Do you think this will do? Or we want something more elaborate like a sleep mode disabling the main regulator?

    Yes i was talking about a UART for the diagnostic lines. I was planning the build in UARTs for the gps and the bluetooth/expansion but given the 5bps requirement, i can use an expernal SPI UART, because i have the 18.476 MHz clock into a 74HC4060 for the LCD clock of ~76KHz. I can take a kilohertz-range output of the 4060 divider and feed it to the external UART, such that it works for 9600 and 5bps.

  11. #461
    Join Date
    Apr 2007
    Location
    Yorba Linda, CA
    Posts
    3,781
    My Cars
    1999 TiAg M3, 2003 E46M3
    Quiescent current on this guy: http://www.national.com/ds/LM/LMZ12001.pdf
    Is a whopping 25uA

    I've used other members of the "Simple switcher" series in the past with very good results.
    I haven't used this one with the integrated inductor, but for a very stable, efficient (92%) 1A regulator, this one rocks!

    More on power management: I plan to use the PIC's software-adjustable clock and sleep modes to put it way down to 32KHz when not in use.
    It will simply maintain the RTC at that point. Using the "Hot in run and start" line (X1070/9) can trigger an interrupt to "wake up" the CPU and go into full-power mode.

    Thoughts?
    Last edited by m2pc; 07-26-2010 at 06:21 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

  12. #462
    Join Date
    May 2007
    Location
    US
    Posts
    942
    My Cars
    '94 325i / s13
    Quote Originally Posted by m2pc View Post
    More on power management: I plan to use the PIC's software-adjustable clock and sleep modes to put it way down to 32KHz when not in use.
    It will simply maintain the RTC at that point. Using the "Hot in run and start" line (X1070/9) can trigger an interrupt to "wake up" the CPU and go into full-power mode.
    This is what I had in mind, and it's why I'm paying close attention to the efficiency of the power regulator. In this case the regulator will never be shut down. This makes the rated shutdown current irrelevant, and it makes the quiescent current (Iq in that datasheet - not Isd) and light-load efficiency very important. I'd expect to see Isd <1uA and Iq <100uA for something worthy of our application. Efficiency of that part is likely to be horrid when we're only drawing a few mA with the car off. It would be wise to select a device which is designed with these concerns in mind, and such devices are a minority. However, having said all that, the size and simplicity of a monolithic solution like that one is most tempting. I for one think I'd be willing to give it a chance. There are far worse things to have to redesign than the power supply, after all.

  13. #463
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    well the datasheet is quoting a non-switching (zero output) of 1mA. Now i am having a hard time to find a reason to have the main power on while the ACC is off? you guys want to be parked somewhere with the key off and use the openOBC?

    I am not concerned with an on-MCU real time clock because i do plan to weld the GPS module very early in the process, and the GPS needs a standby supply (either on board battery or regulator) so i want to use a super low Iq 3.3 linear regulator off the main supply (pin8). The GPS of course keeps an RTC and accuires the exact time on powerup.

    What do you guys think in terms of the wake-up capability?

  14. #464
    Join Date
    May 2007
    Location
    US
    Posts
    942
    My Cars
    '94 325i / s13
    Quote Originally Posted by Mefis View Post
    well the datasheet is quoting a non-switching (zero output) of 1mA. Now i am having a hard time to find a reason to have the main power on while the ACC is off? you guys want to be parked somewhere with the key off and use the openOBC?
    That is my perspective, yes. We're all coming at this from slightly different angles. In my case, I don't have much of a choice. In a sense, my obc is my key. That is, it controls my ignition and I no longer have an ignition switch in my steering column. It also handles my RFID readers and car alarm. My needs aside though, I still always maintain a "leave all doors open unless something closes them" approach. There could be (now or in the future) good reasons for the obc to be able to power up portions of itself, so to me it makes sense to design that possibility in unless doing so requires unreasonable measures to be taken.

  15. #465
    Join Date
    Apr 2007
    Location
    Yorba Linda, CA
    Posts
    3,781
    My Cars
    1999 TiAg M3, 2003 E46M3
    I think we should use our own internal RTC and sync it to the GPS when there's a signal. I don't want to start my car in a garage and not be able to see the time until the satellite signal is acquired.

    IIRC the stock OBC allows you to operate it for a bit with the car off, for example, you can bring up the date/time. Or maybe that's in ACC. I need to go verify.

    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

  16. #466
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    J: the GPS has a RTC, regardless of sat availability. You can display the time as soon as the bulbs will light up without any GPS signal. After aquisition what you get is a time that is +-50ns from the universal clock.

  17. #467
    Join Date
    Apr 2007
    Location
    Yorba Linda, CA
    Posts
    3,781
    My Cars
    1999 TiAg M3, 2003 E46M3
    I'm still thinking of having the main board without any "extra" functions such as GPS, Bluetooth, Accelerometer, etc. Those should go on an expansion board IMHO.

    Here's a complete schematic of my design thus far.
    Attached Images Attached Images

    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

  18. #468
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    Oh i did not read benemorious post. RFID.. that is fancy security.

    Well... i think the guys from national did a good of a job as is physically possible. it may not be possible to have 92% efficency at 12V and uA at no current output. How about a 3.0 linear standby regulator off the 12V with a diode array to the 3.3V main, and enable of the main is software controlled?

  19. #469
    Join Date
    Jan 2010
    Location
    Atlanta
    Posts
    69
    My Cars
    94 325i
    Quote Originally Posted by m2pc View Post
    I think we should use our own internal RTC and sync it to the GPS when there's a signal. I don't want to start my car in a garage and not be able to see the time until the satellite signal is acquired.

    IIRC the stock OBC allows you to operate it for a bit with the car off, for example, you can bring up the date/time. Or maybe that's in ACC. I need to go verify.
    You can see the clock and date while completely off at the demand of the button. The check module also stays active for 3 cycles of check messages after the car is turned off.

  20. #470
    Join Date
    Apr 2007
    Location
    Yorba Linda, CA
    Posts
    3,781
    My Cars
    1999 TiAg M3, 2003 E46M3
    Quote Originally Posted by Mefis View Post
    Oh i did not read benemorious post. RFID.. that is fancy security.

    Well... i think the guys from national did a good of a job as is physically possible. it may not be possible to have 92% efficency at 12V and uA at no current output. How about a 3.0 linear standby regulator off the 12V with a diode array to the 3.3V main, and enable of the main is software controlled?
    What is the standby current of a 3.3v linear regulator?

    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

  21. #471
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    quiescent current is 15uA.

    Please find the bill of materials so far in terms of IC: I have not kept a list of links but they all come from newark.com. Also attached is my schematic in it's current form.


    Q9 IRL620 power FET
    U1 MC9S08AC60 MCU
    U2
    LMZ14203 Main Regulator
    U3 AMB2300 Bluetooth Module
    U4
    ULN2003A NPN Array
    U5
    LM339 Comparator
    U6
    74LVX4245 3.3 to 5 Translator (for screen)
    U7 CD4060 clock divider
    U9
    LIS3LV02DQ Accelerometer
    U10 LR9548 GPS
    U11 LM2936 secondary linear regulator (+3 for standby)
    U12
    CSX750 clock
    U13 MAX7317 IO extender
    U14 LM2936 secondary linear regulator (+5V for screen)
    Attached Images Attached Images
    Last edited by Mefis; 07-27-2010 at 10:09 AM.

  22. #472
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    Quote Originally Posted by benemorius View Post
    This is what I had in mind, and it's why I'm paying close attention to the efficiency of the power regulator. In this case the regulator will never be shut down. This makes the rated shutdown current irrelevant, and it makes the quiescent current (Iq in that datasheet - not Isd) and light-load efficiency very important. I'd expect to see Isd <1uA and Iq <100uA for something worthy of our application. Efficiency of that part is likely to be horrid when we're only drawing a few mA with the car off. It would be wise to select a device which is designed with these concerns in mind, and such devices are a minority. However, having said all that, the size and simplicity of a monolithic solution like that one is most tempting. I for one think I'd be willing to give it a chance. There are far worse things to have to redesign than the power supply, after all.
    Let us test the stock OBC consumption in off. I already unwelded all connectors from my stock unit, including screen and keyboard. Can someone power up the stock OBC with pin8 on and other pins floating and report the current??

  23. #473
    Join Date
    Apr 2004
    Location
    Orlando, FL
    Posts
    70
    My Cars
    '90 325i, '98 M3/4

    Crazy!

    You guys are great!
    I can just follow most of what you're doing, not that I could do it...

    Most of the functions you're planning sound incredibly valuable from a tuning/diagnostic standpoint.

    I'm still not sure how "GPS" would report on this display, turn-by-turn text or are we talking bluetooth screenshots to another device?

    One question... it seems the "killer app" here would be plug-in USB storage for playback of MP3 files through the factory CD43 with ID3 readout and controls on the OBC...is this in the works?

    Will it be possible to have button "modes" so that the buttons remap based on the app?

    I apologize if the the above was covered previously, I've subscribed to the thread for a while and check it sporadically...

    I would definitely be interested in a kit or maybe turnkey...and I'd bet that many others will as well at most any level of the feature set already proposed...

    Thanks,
    Casey

  24. #474
    Join Date
    Mar 2008
    Location
    Portland, OR, USA
    Posts
    106
    My Cars
    1999 M3 Conv.
    Quote Originally Posted by CSwain View Post
    You guys are great!
    Most of the functions you're planning sound incredibly valuable from a tuning/diagnostic standpoint.
    Please post any ideas. Now is the time to plan any changes.

    Quote Originally Posted by CSwain View Post
    I'm still not sure how "GPS" would report on this display, turn-by-turn text or are we talking bluetooth screenshots to another device?
    I was not thinking about that really.. Let me clarify my vision of the GPS. THe GPS module will give you a few bytes worth of data every second as follows:
    -geogaphical coordinates
    -exact time
    -altitude above sea level.
    -heading (like a compass, based on 2 datapoints)
    -speed, acceleration again based on 2 datapoints.

    GPS devices that you buy at a big box mart will have one of these inside, and a processor with a large memory that will calculate the routes, display maps and so on. I do not want to implement such algorithms in this project. My vision was to show in the OBC display the heading, the altitude above sea level and perhaps someone has some idea in terms of what to do with this data. We can funnel this data through the bluetooth serial port bridge into a cell phone or laptop, but in this project per se i was not planning any fancy rendering of maps or anythign similar.

    I was going to implement some simple speed limit map, so that the openOBC knows the speed limit based on the GPS coordinate, and then use this data to gate the radar detector alarm. I comit to make this simple functionality done, but anythign else is beyond what i was planning.

    The accelerometer will give you the instant acceleration. if you know the weight of the car, you can display the instantaneous power developed.

    Quote Originally Posted by CSwain View Post
    One question... it seems the "killer app" here would be plug-in USB storage for playback of MP3 files through the factory CD43 with ID3 readout and controls on the OBC...is this in the works?

    Will it be possible to have button "modes" so that the buttons remap based on the app?
    The buttons is no problem. Turning the openOBC into an mp3 player was not in my mind to be honest, but we are contemplating an expansion board, which has the serial bus SPI ot I2C to connect to most of these types of audio codec chips. You can buy a chip that does an mp3 player off a USB, i have seen that. Also it was mentioned digital synthesis of a hot female german voice. This could be done with some memory and a simple codec chip in the dauther board as well...

    your thoughts are most welcome.

  25. #475
    Join Date
    Apr 2007
    Location
    Yorba Linda, CA
    Posts
    3,781
    My Cars
    1999 TiAg M3, 2003 E46M3
    Quote Originally Posted by CSwain View Post
    You guys are great!
    I can just follow most of what you're doing, not that I could do it...

    Most of the functions you're planning sound incredibly valuable from a tuning/diagnostic standpoint.

    I'm still not sure how "GPS" would report on this display, turn-by-turn text or are we talking bluetooth screenshots to another device?

    One question... it seems the "killer app" here would be plug-in USB storage for playback of MP3 files through the factory CD43 with ID3 readout and controls on the OBC...is this in the works?

    Will it be possible to have button "modes" so that the buttons remap based on the app?

    I apologize if the the above was covered previously, I've subscribed to the thread for a while and check it sporadically...

    I would definitely be interested in a kit or maybe turnkey...and I'd bet that many others will as well at most any level of the feature set already proposed...

    Thanks,
    Casey
    Thanks, it has definitely been a fun project to be part of!

    As for the audio aspects, we aren't really planning on doing that, but like Mefis said, it's all possible. Someone mentioned grabbing an iBus wire from the CD43 to have the OBC display track names in more than 16 characters; that's quite possible since the X1071 connector in particular has a lot of unused pins in it.

    That reminds me -- in addition to a "daughterboard" it would be nice to extend some I/O out of the unused pins. So far I count 9 of them:

    X1070/17, 7
    X1071/18, 17, 16, 15, 12, 11, 10

    Spare pins can be ordered cheaply from AMP or BMW and added to the appropriate connectors in the vehicle. This would make for a very clean installation IMHO. If we exposed some of the MCU's analog inputs to these pins, it would be easy to connect external temp sensors for example. All we'd need onboard is the positive side of a voltage divider and then the sensor would provide the negative side. We could even have a jumper that allows the end user to set which side the OBC is biasing toward (ground or +5/+12v) so any number of sensors could be connected.

    Another interesting thing I am toying with is interfacing with the CAN bus between the DME and the EGS computer. The PIC I'm using has a built-in CAN module that could be easily interfaced to this. I wonder what sort of information can be queried on this bus?

    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

Page 19 of 79 FirstFirst ... 910111213141516171819202122232425262728294469 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •