Put me down on the guinea pig list.
Sent from my iPad using BF.com
Great to hear about this again. I'm willing to sacrifice my obc too for the sake of testing. Based in Europe... so your design would go global first day
so this is moving... if you need a hand with the software... you can count me.
I also have an obc that I can sacrifice.
keep walking
Sent using Tapatalk 2
'97 M3
@ Benemorius: can you post a schematic here for us to see? Much thanks!
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 do believe that the mbed ide can be used. That's the idea anyway. The ide was pretty bare bones when I last saw it but the accessibility may well vastly outweigh any downsides to using it. I trust that the default mbed pin configurations can be overridden for custom boards and aside from that I can't see any other problems. I think that the inconvenience of setting up a toolchain for microprocessor development is the biggest barrier to people who would want to write/modify their own openobc firmware, so being able to just visit a web site and immediately start changing the source code should be a most welcome improvement.
Certainly I will post the schematic very shortly. At this moment I'm in the process of filling in some missing values while populating my first board. I expect I'll have it ready and posted by morning if not sooner. I think I'll postpone tidying it up for now in the interest of making it available immediately. It's not well organized so I'll post it in pdf format so that net names can be followed using the find feature.
I'm afraid that I didn't give a great deal of thought to power management, however I chose to forego the large power budget I had originally planned to have for addons so ultimately I don't think it will be much of a concern this time around. As I recall, most everything can be powered down in software with the exception of the voltage regulators. Quiescent current should be on the order of tens of milliamps with the micro in deep sleep. That's not great but it isn't terrible either.
Not a fan of purple, eh? I get my prototype boards from oshpark.com so they're always purple. If I were to do a larger run I suppose my first choice would be black.
Ok here's the schematic. It may still change but there's no reason not to go ahead and post it. There are still some extraneous net names lying around that don't actually go anywhere. Sorry for that. Like I said earlier control-f will be your friend for figuring out what goes where. Sorry for that too.
Also, I'm about half done populating the first board and all is well so far. I'm tempted to go ahead and try talking to the lcd for the obligatory photo but I'm determined to get it fully built as soon as possible so it will have to wait.
Purple is fine, I'm just pulling your leg... it's actually refreshing to see this vs. the standard "green" most PCBs come with.
I do like how your design is in industry-standard drill and plot files (assuming) vs. mine which was only made to work with ExpressPCB.com. This way we can have these boards made anywhere in the world at low cost, and pick-and-place auto-stuffing becomes a possibility (that QFN CPU chip scares me to solder!).
One thing on the schematic: The "lcd_BIASCLOCK" line, is this for clocking the LCD and adjusting the bias (contrast) in software (if R78B is populated)?
Also, the "AUDIO_AMP" netlist seems to lead to nowhere... were you planning on routing the LPC1768's DAC to this pin to provide audio output/feedback to the driver and/or outside world (i.e. alarm)?
What are your plans for the RF Transceiver you have built into the design? (https://www.sparkfun.com/products/10153?) Any possibility of adding a parallel set of pads to accomodate a bluetooth or GPS module in place of the RF device? It would be nice to have several options using that SPI port.
Again, awesome job on this and I can't wait to see the pics of the board connected to an actual OBC, displaying the well-deserved "hello world" message!
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
Yup the design files are standard so anyone can get them made anywhere. I'll post the files for this board as soon as I'm sure they aren't worthless. I should know tonight. QFN is a bit of a pain but it's really not so bad with solder paste and hot air. You can get a hot air station for under $100 these days so I'd encourage anyone interested to go ahead and pick one up. Using hot air after owning only a soldering iron is a bit like going from a honda to a bimmer. Once you try it you just can't go back
It is. The lcd doesn't care about the duty cycle of its clock signal and it seemed like a waste of a pin to not combine them. I have yet to actually characterize the voltage and current requirements of the lcd bias input or the temperature response of the lcd contrast so I intended to just leave it connected to 5v via R78A for now. It may or may not be entirely necessary to adjust the bias voltage but I didn't want to discount the possibility.One thing on the schematic: The "lcd_BIASCLOCK" line, is this for clocking the LCD and adjusting the bias (contrast) in software (if R78B is populated)?
I had intended to tap in to the stereo wiring for outputting speech or other audio alerts, but I hadn't finished investigating that. I was coming up short on pins at one point so while the DAC output is still routed to the AUDIO header, the AUDIO_AMP output (for turning on the car's amplifier) was scrapped.Also, the "AUDIO_AMP" netlist seems to lead to nowhere... were you planning on routing the LPC1768's DAC to this pin to provide audio output/feedback to the driver and/or outside world (i.e. alarm)?
Likely none at this point, but there was still room for it on the board so I left it in. I'll sort of be using my obc as my car alarm brain for a while until I can get that project spun off on its own and I had wanted to do away with the original radio transceiver as well, but I've since changed my mind. In any case, I don't really see a need to include it and I agree the space would be better used by something like bluetooth.What are your plans for the RF Transceiver you have built into the design? (https://www.sparkfun.com/products/10153?) Any possibility of adding a parallel set of pads to accomodate a bluetooth or GPS module in place of the RF device? It would be nice to have several options using that SPI port.
No promises, but you may not have to wait much longer. I'm on my way home right now to do just that.Again, awesome job on this and I can't wait to see the pics of the board connected to an actual OBC, displaying the well-deserved "hello world" message!
I haven't quite tested everything yet, but the lcd works at least.
AWESOME, GREAT JOB!!!
So were you able to use a .BIN image from the mbed.org online compiler for this, or did you use an offline compiler? Also, how do you get the code into the MCU flash; via USB, SDCard, or via the JTAG header?
EDIT: Nevermind, I just noticed the ribbon cable connected to the JTAG header in the image! It would be nice if we could employ a USB or SDCard bootloader that could suck in a new ROM image and copy it to the internal flash of the LPC1768.
I'm thinking not everyone will have access to a JTAG header at home! :P
Last edited by m2pc; 09-12-2012 at 01:21 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
Yes I'm using gcc and jtag at the moment. However I did intend for the mini usb port and ft232 chip to be used to enable programming with flash magic or similar, as well as flashing via an sd card and bootloader. Once we get some form of wireless connectivity added we'll be able to reprogram it while it's still in the car by writing a .bin file to the sd card and invoking the bootloader.
Last edited by benemorius; 09-12-2012 at 01:32 AM.
OH YEAH that shit is top notch, great job! Seeing progress like that has made me even more excited!
one more celebratory picture before I get back to work...
Speaking of which, it would be nice to document the setup of GCC toolchain on the openobc.org site and have everything people need to jump in and develop for this thing.
Before I forget, have you checked out the LPC1769 which is identical IIRC but has a CPU speed of 120 MHz?
Very nice! Is that a real measurement from the A/D input or is it taken from the diagnostic bus?
Last edited by m2pc; 09-12-2012 at 06:18 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
Hmm...if it got easier to develop on I could port over some code that interprets autometer oil pressure and oil temp sensors. (I also have some accelerometer code, but it needs more filters to not appear jittery.)
It would have to go through a 5V 1024 analog pin and probably need a 5V reference voltage. All that should be easy to set up.
I completely agree. There's a script running around out there which I believe goes by the name of "summon arm toolchain" which makes it dead simple to get a toolchain downloaded and configured. That plus a good how-to guide on the site should make things very easy for virtually anyone to jump in. Of course, there's the mbed compiler too. We'll figure out what's best for our purposes as we move forward. At the moment I'm bringing this prototype up with my existing gcc environment as that's the most efficient way for me to verify the design right now.
In fact the lpc1769 is what I'm populating these boards with. I had forgotten about the newer chips until now, but that is indeed what I'm using.
It's a real measurement from the integrated adc. (yes I do know I need a new battery)
It's going to be extremely easy to develop for the openobc, and you can take that to the bank. The analog inputs will be configurable to permit interfacing with a variety of different sensors, but the reference voltage must be less than 3.3 volts. This is why the resistive dividers on the inputs are configurable. Of course, the math in the code will still need to be different but there's no way around that.
I've successfully programmed the firmware using nothing but a usb cable and the free Flash Magic utility.
I still need to verify the rest of the vehicle inputs/outputs, but it's looking like this prototype is going to be a success with one unfortunate exception. After quite some trouble getting the accelerometer to straighten up onto its pads while soldering, I finally turned it over to see that I had gotten the footprint wrong in my haste. I failed to notice that there is not an equal number of pins on each side. Oh well. It will be corrected on the next design.
Sign me up I want one!
What is the estimated cost of the board?
Also whats up with the website?
Last edited by vollosso; 09-12-2012 at 09:41 PM. Reason: Automerged Doublepost
Arg, I hate when that happens! Oh well, at least you can get your silk screen included next time.
Benemorius would need to chime in on that; speaking of which, we need a real BOM (Bill of Materials) for this once finalized.
Working on getting that back online soon; the old Wiki was configured incorrectly and filled up with SPAM posts.
Last edited by m2pc; 09-12-2012 at 11:16 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
My goal for the cost is to keep it below $200, but it's very heavily dependent on a couple of things. First and foremost is production quantity. Economies of scale apply strongly to electronics - both the parts cost and the assembly cost. It is not an exaggeration to say that the unit cost of some parts can vary by multiple orders of magnitude between buying just one and buying a full reel. At some point we're going to need to get a good estimate of how many people want one so we can determine how best to meet the demand. The more interest there is, the cheaper it will be. As we get closer to the first production revision I'll recommend that a count be taken. We're not there yet.
The other big factor is how many and which expensive options we decide to include. Things like wifi, bluetooth, gps, gsm... these are not cheap. A while ago it was suggested that we could take advantage of the usb host support on the microprocessor which could allow us to use extremely cheap off-the-shelf usb devices intended for use with computers. These devices are so cheap because they are produced in massive consumer-level quantities and we could not even hope to match their price point any other way. You can get usb wifi and bluetooth adapters for just a few bucks these days on ebay, amazon, and the like.
This would not only reduce the total cost of a fully optioned-out openobc, but will naturally make these features inherently optional since each person would simply buy their own usb devices and plug them in. Going this route will require more software development for the usb devices but it's a fantastic idea and I'd really love to see it happen. I've included usb host support in this prototype design and I'm really hoping that we can get some of the people who have offered their coding skills to help make it happen. I'll do a few more runs of a fixed up prototype design if necessary to get prototypes out to those who can help with software.
Small update from me: The website is back online!
http://www.openobc.org/
Not much content yet, but we have a solid base upon which to add more later.
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 curious what's the reason for USB host?
Also will the processor be able to translate the values(already present values, accelerometer, inputs) to usb or serial fast enough for decent datalogging?
I believe Benemorius hit this one on the head when he mentioned being able to use existing "consumer" USB devices, such as WiFi adapters, Bluetooth radios, etc. Basically any USB client could connect via this connector.
As for data logging, we could either use the internal SDCard connector, or use the USB host header to a traditional USB socket (BMW has some for the E9x series that can be adapted IIRC). In that case, you could use a USB flash drive to store logged data.
Regarding speed of transfer, the values could be cached locally in RAM or on-chip FLASH and then offloaded to an external device in a standard format (CSV, HTML, etc) for data logging purposes.
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
@m2pc
What was the latest story with the lin drivers you were looking at for the diagnostic interface? I'd like to go ahead and move away from discretes wherever possible in the next revision.
Bookmarks