Arduino LH Jetronic interface: live data + MicroSD logging + ELM327

Sorry, I haven't had as much time as expected to work on this project in the last few days, and haven't had time to fully follow all the recent discussions.

I'm still planning on using simple RC circuits, and a couple high-speed switching diodes for inductive clamps, to monitor the EZK/ECU signals. I'd like to keep the added loading on the EZK/ECU signals to only ~10uA to ~50uA, or ~200K ohms to 1M ohm (definitely high impedance). I need to trace the EZK Tq/Load signal driver to see if higher loading can be used since it's the fastest signal of the bunch. I also need to trace the IGN driver because I'd like to measure exact ignition advance, and may need lower RC delay for the desired accuracy.

For grounding, the Arduino board needs to connect only to ground in the EZK, or only to ground in the ECU. Any other connection may add a bad ground loop that might affect normal engine control.

For high speed timing measurements in the Arduino, you need to setup custom PCINT PinChangeINTerrupt code. This will trigger an interrupt routine whenever the logic level of one of the enabled pins changes. The interrupt routine then needs to keep track of the previous and current state to figure out which pin changed.

Here's what I have for the older IGN setup/interrupt code:

[in setup section]
// Setup high speed digital inputs
pinMode(4, INPUT); // IGN sparkAdv

// Setup interrupt handlers for high speed signals: rpm (tach), vss, load, inj, spark
PCICR |= 0x04; PCMSK2 = 0x10; // IGN: pin D4, PCINT2_vect (D0-D7)

[in interrupt routine section]
//********************Interrupt Service Routines***********************
// For good info on setting up interrupts, including the pin change interrupts that aren't
// directly supported by the Arduino library, see: http://www.gammon.com.au/interrupts

// Interrupt Service Routine for pin D4, IGN input, PCINT2_vect (D0-D7)
// - enabled via direct interrupt register config in setup() section
// - triggers on both edges of IGN signal
// - Dwell is pulse width
// - Advance is updated here using falling RPM signal edge captured by RPM ISR

ISR(PCINT2_vect) // Pin change interrupt for pins D0-D7 (only D4 enabled)
{
boolean edge;
unsigned long edge_time;

// get interrupt edge and current time
edge_time = micros();
edge = digitalRead(4);

// Measure ignition dwell time as rising to falling pulse width (coil changes when signal is high)
// Measure ignition advance as previous falling RPM edge to falling ign edge
if(edge) {
ign_rise_edge = edge_time;
} else {
ignPeriod = edge_time - ign_rise_edge;
ign_fall_edge = edge_time;
advance = edge_time - rpm_fall_edge;
ign_int_flg = true; // set flag to indicate new ign dwell and advance measurements
}
ign_ints_processed++;
}

Click to expand...

I'm still looking at the Arduino capabilities and how to monitor all the signals. I think it will work well, and that I can possibly leave the I2C SDA/SCL pins unused if someone wants to use them for expansion in the future (such as the Sparkfun Qwiic interface).

@bobxyz: When you were talking about PinChangeINTerrupt I was thinking you were meaning about the https://github.com/NicoHood/PinChangeInterrupt library but from your snipplet I've understood that you are talking about a different thing and you want to use directly the registers.
I've not written yet any code that uses them but I read something about and I agree with you that could be the right method to get more interrupt enabled pins. (This is the link to the article I'm talking about: https://thewanderingengineer.com/2014/08/11/arduino-pin-change-interrupts/)
In your snipplet I saw that you have used the function digitalRead() to read the status of a single pin, digitalRead() is not too much fast and if used to read the status of many pins inside the ISR its delay could became an minor issue. Do you have already searched for a faster way? It should be possibile to read the status of a pin reading the whole port as a byte and applying on it a bitmask instead of using digitalRead().


@142 guy: I don't understand what you mean with As an example, if injectorSignal goes HIGH just after you execute "int injectorSignal = digitalRead(INPUT_PIN_ECU_INJECTORS_SIGNAL); " you won't capture the state change until the next time you run through that part of the code loop.
Did you thinked that the function injectorsSignalChange() is called from the main loop as a polling?
No, both injectorsSignalChange() and tqSignalRise() are ISRs and not normal functions.
Since injectorsSignalChange() is an ISR is impossibile that the injectors signal falls down and rises up again in less than 5?s (or a bit more), also when engine is at idle the pulse width of the injectors is near 2000?s.
The slownes of the function digitalRead() is a limit in measuring very short pulses width with high precision but I don't think that is this my main problem to solve.
Infact I've better re-analyzed the Tq signal recordings I took two weeks ago with my oscilloscope and I found another issue.
I was thinking that the pulse of Tq and injectors were always in sync, in other words I was thinking that:
- at t0 injectors pulse signal falls down
- at t0 + approx 130?s Tq pulse signal rises up
- at t0 + 130?s + 20?s...250?s Tq pulse signal falls down
- at t0 + 2000?s...8000?s injectors pulse rises up
This is wrong because when the rpm and load increases the sync of the two signals change and there are situations when there is an overlapping.
For example the injectors signal could fall down when the Tq was yet high and according to my code the call to injectorsSignalChange() will be delayed until tqSignalRise() ends. I found also that also the sync of the Tq rise changes.
If I had more interrupt pins availabe I would never have calculated the rpms from the count of the Tq pulses instead of the rpm pulses and above all
written a busy wait inside an ISR. I did it to quickly test the performances of the optoisolator and believing that it could works, after all also the pulseIn() function do a similar thing to measure a pulse length.
This could drive to an error in the measure of the injectors pulse that could reach up to 250?s and is not acceptable.
Pin Change Interrupts, as suggested by bobxyz, could help me to rewrite the code and to fix the problem, but I whould also to find the alternative to the digitalRead() function.


A bit off-topic: I also would like to add the the ignition advance measure, but I'm dreaming a totally different way from getting the crank signal from EZK. I believe that it could be possibile to detect the TDC by analyzing the AMM signal oscillations and I want to take more scope measures using AC coupling to better study it.
May be that it will drive me to dead-end road, but a few years ago I made a similar experiment using my oscilloscope and I was able to measure the ignition advance with a reasonable precision looking the current oscillations produced by the alternator that can show you when the piston reaches TDC and BDC (when there is the piston stroke the current produced is a bit more since the cranck shaft is accelerating, on the opposite, when the piston is compressing the crankshaft slow down a bit)
Also the air mass is not a continuosus flux but if you are able to zoom the signal just enough you can see that is alternating, in sync with the pistons that suck the air. One of the most difficult thing in doing this is that the amplitude of the signal changes not only with the load but also with the rpms as you have seen I'm a novice in designing electronic circuits.

I had not read your code and had read into your comments that you were using the digital read inside the main loop. If you are doing the digital read inside the ISR then you have eliminated the timing issue that I raised.

A comment on your idea about using the AMM signal to detect TDC. I don't have any experience with AMM devices, just MAP sensors. With a common plenum intake manifold the pressure fluctuations pretty much disappear once the engine speed is above 1500 RPM. During engine cranking the cylinder filling events are very easy to spot; but, once the engine fires and comes up to idle speed it would be very difficult to reliably identify the cylinder filling events. Even when the cylinder events are easy to spot I think it would be difficult to get a precise measurement on TDC. The magnitude of the fluctuations will depend on the volume of your intake plenum with a smaller volume making the measurement easier.

If you have a high tooth count wheel on the crankshaft (36 tooth would be ideal) at idle it will be very easy to pick up the engine speed variations that occur at idle. I can do this with what is the equivalent of the 12 tooth wheel that I have. I have never checked to see what the speed variations look like as the engine speed increases because the stored energy in the flywheel increases which tends to smooth out the variations. Clearly a 36 tooth would be better than a 12 tooth wheel. OBDII compliant ECUs use crankshaft speed detection to detect individual cylinder misfires so it would appear to be possible; but, a complete misfire probably results in a much larger speed delta than that caused by the compression of the intake charge. That said, OBDII crankshaft speed misfire detection systems are a little notorious for their reliable signal measurement and to avoid false error codes typically require 3 detection events in a trip before they will trigger the CEL continuously.

I believe that Saab's Trionic engine management package used their ion sense cylinder pressure management system to detect #1 TDC firing in place of a cam position sensor; but, I don't believe that they used it as a precision measurement (exactly TDC).

142 guy said:

I had not read your code and had read into your comments that you were using the digital read inside the main loop. If you are doing the digital read inside the ISR then you have eliminated the timing issue that I raised.

A comment on your idea about using the AMM signal to detect TDC. I don't have any experience with AMM devices, just MAP sensors. With a common plenum intake manifold the pressure fluctuations pretty much disappear once the engine speed is above 1500 RPM. During engine cranking the cylinder filling events are very easy to spot; but, once the engine fires and comes up to idle speed it would be very difficult to reliably identify the cylinder filling events. Even when the cylinder events are easy to spot I think it would be difficult to get a precise measurement on TDC. The magnitude of the fluctuations will depend on the volume of your intake plenum with a smaller volume making the measurement easier.

If you have a high tooth count wheel on the crankshaft (36 tooth would be ideal) at idle it will be very easy to pick up the engine speed variations that occur at idle. I can do this with what is the equivalent of the 12 tooth wheel that I have. I have never checked to see what the speed variations look like as the engine speed increases because the stored energy in the flywheel increases which tends to smooth out the variations. Clearly a 36 tooth would be better than a 12 tooth wheel. OBDII compliant ECUs use crankshaft speed detection to detect individual cylinder misfires so it would appear to be possible; but, a complete misfire probably results in a much larger speed delta than that caused by the compression of the intake charge. That said, OBDII crankshaft speed misfire detection systems are a little notorious for their reliable signal measurement and to avoid false error codes typically require 3 detection events in a trip before they will trigger the CEL continuously.

I believe that Saab's Trionic engine management package used their ion sense cylinder pressure management system to detect #1 TDC firing in place of a cam position sensor; but, I don't believe that they used it as a precision measurement (exactly TDC).

Click to expand...

I know Toyota COPs have a feedback wire that are used to detect misfires, not exactly sure how, perhaps a piezo sensor in the COP?

I'm making progress on the design, but am not quite there yet. Here's what the schematics look like currently (click for bigger):


For the initial boards, I picked a 15-pin Dsub connector to bring the EZK/ECU signals onto the board. A short wiring harness then splits this into 2x 9-pin connectors, 1 for EZK and 1 for ECU/extras. The resistor/capacitor/diode circuits in the schematics are about right, but the exact component values may change. I also expect to move some of the port assignments around once I get to layout.

The latest choice for an Arduino is a Leonardo 16MHz 5volt 32U4 board. I think I can fit all the Monitor circuits onto a daughterboard (aka shield) of about the same size if I use SMT parts (assembled by JLCPCB).

I thought I was close to done, but then realized that the Leonardo/32U4 microcontroller has NO hysteresis on the input pins, plus weird input voltage levels. The original Uno/328P boards have reasonable input hysteresis and levels. Without the hysteresis, the inputs will be _very_ sensitive to the slightest electrical noise. I'm really surprised that Arduino would pick a chip without any input hysteresis for hobbyist use. WTF were they thinking.

At this point, I'm trying to decide if I want to go back to a Uno/328P Arduino that has better noise immunity but doesn't include the 2nd serial port, or if I should just add an external schmidt trigger buffer chip to the schematics and move on.

Let me know if there are any [brief] questions or comments. If anyone is interested in more direct access, I think I can setup a Group on easyeda.com and add others to the project (you'll need to setup an account and PM me your user name, or maybe email).

VB242 said:

I know Toyota COPs have a feedback wire that are used to detect misfires, not exactly sure how, perhaps a piezo sensor in the COP?

Click to expand...

Cars have have one of two misfire detection systems, or both. One looks at crankshaft speed fluctuations and the other monitors ignition coil output voltage. I have an Acura and it has two complete sets of P codes for misfires, one triggered by the signal (or lack of signal) from the ignition coil , the other triggered by monitoring the crankshaft speed. The Acura I have has COPs; but, they are passive COPs and the misfire monitoring circuit is just a voltage divider that generates a voltage pulse when the ignition coil fires. That pulse goes to an external misfire detection module which generates a conditioned signal for the ECU. The ECU initiates a spark trigger for the coil and probably waits for the signal from the misfire detection module to confirm that the coil did fire. If there is no confirmation signal it probably sets a P code. That system will only detect misfires caused by an ignition failure, not misfires cause by a fuel mixture problem or other problems. The crankshaft speed monitor will pick up misfires due to all causes, including stuff that are not legitimate misfires if the software is set too sensitive.

bobxyz said:

I thought I was close to done, but then realized that the Leonardo/32U4 microcontroller has NO hysteresis on the input pins, plus weird input voltage levels. The original Uno/328P boards have reasonable input hysteresis and levels. Without the hysteresis, the inputs will be _very_ sensitive to the slightest electrical noise. I'm really surprised that Arduino would pick a chip without any input hysteresis for hobbyist use. WTF were they thinking.

Click to expand...

I'm using an Arduino Mega 2560 but from the manual also the Atmega16U4/32U4 have Schmitt triggers on digital inputs (see chapter 13.2 Ports as General Digital I/O)
https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf



In the while I've totally destroyed my board and rebuilt it using diodes to clamp the spikes and some LM339 comparators instead of optoisolators to change the voltage level. For the analog signals I still used OpAmps powered at 5V + some filters.
At the bench it works but I'm still not yet satisfied, infact I'm worried by the LM339 sinced it doesn't like negative voltages lower than -0.3V, and this is less of what I can cut using diodes.
Also the input impedance it's driving me crazy since I would like to have it much grather as possibile but this is in conflict with the need to have a good voltage precision (especially with OpAmps that handle analog signals for ECT, AMM, O2 sensor and battery voltage).
I started with resistors of 1MΩ but now I'm using only 10kΩ in series with the input pins of both OpAmps and Comparators thanks the high input impedance of OpAmps and Comparators.

I'm better studing it and the "Application design manual"...

Yesterday evening I wrote my first code that uses pin change interrupts and registers and it worked (I had also to fix the conflict with my code that was due to the dependency to the library SoftwareSerial that I don't use at runtime), now that I learned how it works it is easy, but the code is much more cryptical to read since it requires to enter more deeply into the hardware

In the next days I will rewrite also the other signals handling routines and I will made some measures to see how much is faster than digitalRead()...

This is the new code to measure injectors pulse width:



...

// PCINT16 alias PK0 alias A8

// Configure PCINT16 as an input using the Data Direction Register K (DDRK)
DDRK &= ~_BV(PCINT16);

// Disable the pull-up resistor on PCINT16 using the Port K Data Register (PORTK)
PORTK &= ~_BV(PCINT16);

// Enable pin change interrupt on the PCINT16 pin using Pin Change Mask Register 2 (PCMSK2)
PCMSK2 = _BV(PCINT16);

// Enable pin change interrupt 2 using the Pin Change Interrrupt Control Register (PCICR)
PCICR |= _BV(PCIE2);

// Enable interrupts
sei();

...

ISR(PCINT2_vect) {

unsigned long enterTime = micros();
uint8_t injectorPinStatus = PINK & _BV(PINK0); // Read PK0 using the Port K Pin Input Register (PINK)
if (prevInjectorsStatus != injectorPinStatus) {

if (injectorPinStatus) {

// injectors off
if (lastInjectorsActivationMicros > 0) {

injectorsTonMicros = enterTime - lastInjectorsActivationMicros;​

}
lastInjectorsActivationMicros = 0;​

}
else {

// injectors on
lastInjectorsActivationMicros = enterTime;​

}

prevInjectorsStatus = injectorPinStatus;​

}​

}



...

I am a clumsy C programmer; but, my understanding is that time functions should not be used within the ISR. In your ISR, you are initializing entertime using the micros() function. The micros() function returns the number of microseconds since the board started running the current code. The information I recall is that when called within an ISR micros() can provide erratic results once the operating time exceeds 2 milliseconds.

Since I have never tried using micros() within an ISR, I don't know what the nature of this erratic behavior is. If the problem is that it returns a time with an error of a few microseconds that may not be significant when evaluating the accuracy of the injector pulse width. Perhaps you are aware of the micros() problem and have determined that is not a problem for what you are doing.

I didn't check explicitly; but, it looks like you have dealt with the micros() overflow problem.

I think is not a problem of be a great C/C++ programmer, is to have a deep knowledge of the arduino architecture.
The micros() function relies on an HarwareTimer and HarwareTimers throw a software interrupt every time they run into overflow to increment a counter (necessary to know how much time has elapsed from the boot).
I think that using micros() inside a ISR could suffer problems if called more times since if the HarwareTimer runs into overflow between one call and the other the second call will return a time that precedes the one returned by the first call since the counter increment will be deplayed after the ISR ends.
If micros() is called only once at the beginning of a fast ISR I don't think it could be a real problem.
I was better reading the documentation and one problem using micros() is that on most arduino boards it has a precision of 4μs and this could explain why, also after having rebuild my interface using comparators instead of optoisolators, the minimum pulse width of a Tq pulse I can measure is still approx to 10μs.
May be that modifying the prescaler of the timers it is possibile to improve the precision but before doing a such thing I have to study much better the consequences since the timers are used also by other functions and/or libraries.
Consider that I'm still learning day by day new things about arduino and I could change my point of view in the future, but I also have to say that to measure injectors pulses (or engine rpm) the micros() function inside a ISR seems to work fine (and also for measuring the Tq signal, also if with a moderate precision). For other signals like IAC or vehicle speed I think that a ISR is not the proper solution and I believe that it could be better to call pulseWidth() with a short timeout inside a polling loop (the same to sample analog signals).

Status: I'm still looking at options to use an Arduino Leonardo 32U4 cpu with external buffer circuits to give good hysteresis and noise tolerance. I want to stay with the 32U4 so that I can use a hardware serial port for the HC-05 Bluetooth board. It's not a max baud rate issue, but I don't trust the standard "software serial library" to work well with my extra interrupt code. Writing good and glitch-free interrupt code can be difficult, and I've seen problems sharing interrupts with common LCD graphics and CAN bus libraries.

Hysteresis: The some of the Atmel/Microchip AVR datasheets included graphs of hysteresis, some don't. Without a graph, you can still infer the hysteresis from the charts of Vih and Vol levels (see Pin Threshold section). The Uno 328P datasheet shows ~500mV of hysteresis (Vih,typ - Vil,typ), which gives good noise immunity. The Leonardo 32U4 shows only ~25mV, which gives almost no noise tolerance. Your Mega board's 2560 cpu has ~400mV of hysteresis, which is good.

More Status: I've pretty much given up on the option of having a 100% thru-hole PCB -- the added signal buffering takes too many parts. I'm hoping that the JCLpcb SMT assembly has high quality because I really struggle with any SMT work. The latest plans are to use dual 5v schmitt trigger buffers, 74LVC2G17 in a SOT-363 pkg, with +/- clamp diodes to provide hysteresis and level-shift the inputs. You can get dual series schottky barrier diodes in a SOT-323 pkg (BAT54SWT), so there should be plenty of room. For the initial PCBs, I'd like to use the UNO/Leonardo R3 shield form factor. I think this will plug onto your Mega board too (but you may need some jumper wires because some of the pin change interrupts are on different pins).

Clamping undershoot: To clamp signals with a minimum voltage difference, look for a "schottky barrier diode". These will typically clamp at a bit less then 0.3v at low currents. I forget the common thru-hole part numbers.

Interrupts: Once you're comfortable with the pin-change interrupts, you can use them to measure any pulse parameters directly. After you're setup and understand how to measure one pin, the rest are just slight modifications. Besides, I'm not sure if the pulseIn() function will play nicely with other interrupt-driven code.

Micros(): I forget where I found the documentation, but the micros() function should be fine to use within an interrupt routine. There might be problems if you have very long interrupt code. If it's too long, your routine has disabled interrupts, and the micros() code can't execute its counter rollover interrupt code until your routine is done.

Normally, you don't want to add any unmatched sei() interrupt enables to your main code. Generally, if you need interrupts disabled in main code, you do a: cli(); <short code>; sei(); . Remember, the Arduino environment is already using interrupts (for timing and for serial) and that you need to share nicely.

Status Du Jour: Design, parts selection, and schematics are good. Initial PCB sizing, to match an Arduino Leonardo R3 Shield, and placement seem fine. Learning the layout tools and routing is underway. The EasyEDA tools include a slick 3D viewer. I'm sure glad I'm not doing the SMT assembly (and I've already picked the biggest available packages). The 3D picture here is close to the actual board size of 2.1"x2.7" (or at least it is on my screen).



-Bob

Regards
Hubert

I stayed up late last night and finished off the PCB design. Sent my money off to 深圳市嘉立创科技发展有限公司 and the stuffed boards are finally underway.

I gotta say, I'm still in shock at the prices:
- $5 for 10 blank PCBs (on special)
- $8.50 for mfg setup and solder paste stencil
- 2x $3 for "Extended" parts that they need to hand load (versus "Basic" parts that are already loaded for the pick&place machine)
- $7 for hand soldering the DB-15 connectors (I didn't have any in my parts stash, so why not)
- ~$1.50 per board in parts - roughly:
-- a penny for each R and C
-- a nickle for diodes and small logic gates
-- $0.20 for the 5v regulator
-- $0.35 for the DB-15 connector
- $13 for 2-4day DHL shipping
- -$10 new customer discount code
----------
$45 for 10 [mostly] assembled PCBs (shown ~2x, actual size is 2.1" x 2.7")




I still remember being happy years ago with 3 blank boards for $99, and hundreds of dollars for short run SMT assembly. Wow, how this has all changed.

The boards should be here in a couple weeks. If anyone wants one, send me a message. It would probably be best to wait until I do some basic testing and get the initial software working first. You'll need an Arduino Leonardo, some 0.1" headers, a MPX MAP sensor [optional], a HC-05 bluetooth module [initially optional] and some DB-9 connectors (or other) for wiring to the EZK/ECU boxes.

-Bob

bobxyz said:

I stayed up late last night and finished off the PCB design. Sent my money off to 深圳市嘉立创科技发展有限公司 and the stuffed boards are finally underway.

I gotta say, I'm still in shock at the prices:
- $5 for 10 blank PCBs (on special)
- $8.50 for mfg setup and solder paste stencil
- 2x $3 for "Extended" parts that they need to hand load (versus "Basic" parts that are already loaded for the pick&place machine)
- $7 for hand soldering the DB-15 connectors (I didn't have any in my parts stash, so why not)
- ~$1.50 per board in parts - roughly:
-- a penny for each R and C
-- a nickle for diodes and small logic gates
-- $0.20 for the 5v regulator
-- $0.35 for the DB-15 connector
- $13 for 2-4day DHL shipping
- -$10 new customer discount code
----------
$45 for 10 [mostly] assembled PCBs (shown ~2x, actual size is 2.1" x 2.7")




I still remember being happy years ago with 3 blank boards for $99, and hundreds of dollars for short run SMT assembly. Wow, how this has all changed.

The boards should be here in a couple weeks. If anyone wants one, send me a message. It would probably be best to wait until I do some basic testing and get the initial software working first. You'll need an Arduino Leonardo, some 0.1" headers, a MPX MAP sensor [optional], a HC-05 bluetooth module [initially optional] and some DB-9 connectors (or other) for wiring to the EZK/ECU boxes.

-Bob

Click to expand...

Beautiful work!
Regards
Hubert

Thumb up Bob, congratulations for the progresses
I paused my works after having rebuilt the prototype board, at the moment I'm still waiting for some schottky diodes from aliexpress and since holidays are coming I think I will restart works after them.
For the 3D picture of the board, also Kikad has this feature and I find it really great!

hk 40 said:

Ive followed this with much interest and great respect. I just want to ask why you guys are using such boring displays.​

Click to expand...

apollokid said:

Thumb up Bob, congratulations for the progresses
I paused my works after having rebuilt the prototype board, at the moment I'm still waiting for some schottky diodes from aliexpress and since holidays are coming I think I will restart works after them.
For the 3D picture of the board, also Kikad has this feature and I find it really great!


Hubert, you are right, character displays are a bit old today but I started my project without a screen at all since the goal was only to see live data on the smartphone using Torque by creating a sort of bluetooth ELM327 adapter.
When RPMS, vehicle speed, o2 sensor and coolant temperature were already working I decided to add a screen with a touchpad to be able to see live data also without connecting the phone (very useful for SW development) and then the SD adapter to be able also to save the data directly on a microSD.

Click to expand...

No critiques just suggestions. You don't have to explain why you did things your way. What u are doing is really great and with your computing skills you can make the smart screen do all kinds of wonderful thing. The vacuum florescent displays are very bright with small pitch they can do smart serial and parallel DMA. You can section of different parts of the screen for different visualizations. Nailing the functionality down first was certainly priority and that makes sense. Here are a few screens that I know will integrate with Arduino MCUs. They are much cheaper than Noritakes but you lose some of the SMART functionality however they still have a small pitch and will look great. Thank you for responding to the suggestion Apollo! Once I get all the hardware figured out for the boost controller I may need your "c" computing skill as the basic port is high level and slower.. The knock spectrum analyzer may still require DSP. TI has a few chips Im looking at. Anders has created fairly detailed schematics. If I can find the mics output aft of the analog filters I may be able to tap in there and avoid Digital sound processing since I know that's already done in the Analog domain of the unit which appears to be mostly op amp filters and signal amplification.

The stuffed boards showed yesterday and they look nice! I'm really impressed - the design files were uploaded late a week ago Wednesday (5/26), and I have 10 fab'd and assembled boards in hand (6/4), from China, in just under 9 days. (click pics for full size)



So far, I've just applied power and all seems fine. I did find a couple minor booboos already (one of the Arduino mouting holes is 0.1" off, and one of the DB-15 mounting pins hits the Arduino power jack), but that's what prototypes are for. I'll update this thread once I have time to wire up the board to my benchtop LH/EZK setup and do some basic checks.

NICE!!!!

Regards
Hubert

I check back every week hoping there might be updates.

Yeah, that bobxyz guy can be a real slacker when work/family/Summer intervene. I'll see if I can kick his butt to put together an update in the next few days.