Ok, the idea I’ve been hashing around for about a year involves engine data acquisition for older vehicles (non OBD equipped). To over-simplify, I’d like to monitor a 12V square wave output from an MSD ignition module (the tachometer output) to measure RPMs, as well as 4 0-5VDC sensor lines (Air-Fuel Ratio, Exhaust Gas Temp, etc) in order to log/graph the values.
I was all set working on some C code in Ubuntu linux to utilize the parallel port for I/O when the laptop bit the dust. Of course, “modern” laptops no longer contain LPT ports. So, I abandoned it for a while, but now it’s back and I’d like to pursue a USB solution. But, I think I’m out of my element here.
I’ve got a block diagram of what I was envisioning for the LPT-based solution, and the C source I’ve got so far, if someone would care to take a look.
Purpose here is for personal use (my 1967 Mustang) and scholarship.
If interested, I can also be reached at:
dougstang67 (at) hotmail (dot) com
Thanks!
EDIT: Uploaded diagram to PhotoBucket:
http://i274.photobucket.com/albums/jj26 … AQ/DAQ.png
look at the UBW - http://www.sparkfun.com/commerce/produc … cts_id=762
follow the links to the UBW home page.
eckertd,
Yes, the UBW could do exactly what you want. You could eliminate every chip in your diagram, as the UBW can time incoming digital signals (and count them - for your Tach signal) and digitize 0-5V analog input signals (10 bit even).
You’d probably want to take the current 1.4.3 Firmware D source code and modify it slightly - the A/D functions are fine and you can probably leave them as is, but you’ll want to write a little code to do the counting of the Tach signal. It will be very straightforward. You talk to the UBW over a USB COM port, so you can use any language on the PC you’re comfortable with to communicate with your UBW.
*Brian
The Auto environment is harsh. I recommend you do some signal conditioning before the board sees the inputs. I would also protect the inputs from extreme voltage and reversed battery. I’d also look into using extended temperature components as a car can get really hot.
I really appreciate the input. It sounds like this may actually be possible!
I ordered a UBW from SparkFun and can’t wait to get started.
Brian, you’re so matter-of-fact with that…just modify the firmware a little! :lol:
I may be in a little over my head with this, but I learn quicky and should be able to tread water in no time. Is there a documentation collection on-line I can look at in advance?
–Doug
Yup. There’s one .c file that has all of the currently implemented commands. http://www.schmalzhaus.com/UBW/FW/D_143/user/user.c
You can download a zip file of the entire project from here:
http://www.schmalzhaus.com/UBW/FW/D_143/D_143.zip
You’ll want to have the latest MPLAB and C18 compiler from Microchip installed. Then you can poke around in the source code and get a feel for how things are currently set up, make some changes, see if they compile, all before your UBW arrives.
For explanations of how the various commands work from a user’s perspective (i.e. the protocol across the virtual COM port) see here
http://www.schmalzhaus.com/UBW/Doc/Firm … _v143.html
That should get you started. There’s a whole forum of questions and answers if you look at viewforum.php?f=19
*Brian
EmbeddedMan:
You’ll want to have the latest MPLAB and C18 compiler from Microchip installed. Then you can poke around in the source code and get a feel for how things are currently set up, make some changes, see if they compile, all before your UBW arrives.
Yikes! $495 for the non-student/demo (60-day) license. :shock:
I think I may have to aggregate the tach pulses externally (binary counter as in diagram), then query/read/reset via the UBW. Looks like the A/D circuitry from my initial diagram can certainly be deleted.
Thanks for the doc links, I had actually found user.c poking around the website. The FirmwareDDocumentation is VERY helpful!
–Doug
eckertd,
I just use the student version for all of my UBW work. There’s no reason you can’t do the same. You don’t have to pay anything for the student version, it compiles everything just fine, and there is no time limit.
And $495 for a commercial compiler is not all that much - many are $10K or more.
*Brian
You’re right, $495 isn’t a whole lot compared to other compilers (Ada!), but it’s way out of budget for my little time-waster. 
I’ll give it a shot.
Have a great weekend all!
Should this thread be moved to “USB Development”?
I was reading the FirmwareD v1.4.3 document and I have a question. I see that “I” return packets are terminated with a , are “A” return packets as well?
I was thinking of setting sub-second I & A timers (same rate via “T” command) and having a process read the output stream into a memory-mapped file. Another process(es) would be responsible for parsing the data and populating individual data files and/or displaying to GUI (for a near-real-time view).
Was also entertaining the idea of using an external binary counter to aggregate the tach pulses. This way, the only firmware modification I’d have to make would be to set a pin hi/lo to the counter’s reset pin after an “I” return-packet is sent.
Still could use thoughts/ideas on droppng the 12V square wave from the tach to about 5V :?
eckertd,
Sure, I think the USB forum is a better place if you choose to use the UBW for your project.
Yes, the A packets are terminated the same way as the I packet.
Your system will work, as long as things don’t move to fast. (I.e if you are trying to watch 100KHz signals, it won’t work. 10Hz signals will work fine.)
As far as the external counter, my reaction is that the software would only need to be very slightly modified to do exactly what you want, so why add extra hardware? In fact, let me take a crack at seeing if I can’t throw up a counter function into the firmware for you just to see how hard it really would be.
*Brian
Brian,
My UBW is already on the way, hope to see it by end of the week. Can this thread be migrated, or shall I just start a new one in the USB forum?
Thanks for the return packet info. It’ll sure make parsing a little easier.
I like the idea of starting the I&A counters and having the UBW stream the values (I was figuring in the 10-100Hz range, depending the on the capabilities of the receiver). And, yeah, adding the 8-bit counter is more of a “brute force” way to get it done. But, I just installed MPLAB C18 & IDE, and it’s a lot to digest when combined with the FW source - it’s a little overwhelming. :oops:
