[info] Frankenso - ECU shield compatible with OEM case / official

[AndreyB]

do you see this ripple with the sensor disconnected from the board? btw, what sort of cable you use to connect the sensor?

I would need to double-check but I think I only see this with the harness disconnected. I am using the stock harness which has these NCA shields(?) which I hope are connected to my GND in the ECU

[Nobody]

Couple of thoughts…

The 40hz noise seems way too low for harmonics, but likely all that logic analyzer can catch (very likely root cause it at a much higher frequency). Guessing you do not have oscilloscope? If you have one, then start probing and you should be able to isolate.

Start at power supply and work your way forward. Look at caps, those can be damaged while hand soldering. Do you have all grounds connect to a “STAR”? Try tacking on additional capacitance, both power supply and VR input (VR only to isolate PS or input). Temporarily short VR inputs together and see if noise is still present, if so them PCB related.

Maybe try twisted pairs if you cannot extent shielded cable (this will knock down noise a bit). Remember shielded cable should only be grounded on one end.

[kb1gtt]

I think I see it in the RPM signal as well as when the sensor is not connected. This is why I think power supply ripple. It doesn't take much ripple to cause the output to change. However it was also kind of odd that the pulses seemed to match the falling edge of the RPM signal.

I'd like to learn what the coil pickup measure for resistance. I think we'll see each sensor has a different resistance.

[Nobody]

Yes I noticed noise in capture too.

Given the CPU likely consumes less than 100ma wonder if switcher does not have enough load to be stable? I've seen this too many times. Maybe a add parasitic load and see if it improves.

[AndreyB]

Non-fatal issue: VDD pins for discovery are connected to +5, not +3 which makes some really funny issues (thanks ST it does not burn the discovery instantly). You would to remove three VDD pins from the 25x2 header before soldering, I had to cut the VDD pins from discovery as a fast solution.

[kb1gtt]

This is corrected in R0.2, which should be posted before to long. If anyone makes the PCB, let us now and we' can make sure you have the most recent files. We don't plan to release R0.2 until we have done more testing, but can make an intermediate release if it there is MFG interests.

[Sudo]

Not sure if you've taken into account of the initial 10uF limitation on USB power. I will take a look at the schematic later tonight.

[kb1gtt]

Errrr, 10uF limit? Any suggested reading about this? I'm assuming there is a current limit vs time issue. I'm guessing that over 10uF typically violates the limits. However I've not seen documentation about such current limitations. I'd like to learn more. For example, I could limit the current inrush with a series resistor, or a PTC fuse. I wonder what approaches can be taken to allow more than 10uF.

C1003 on page 9 will get charged when the USB is plugged in, and is 220uF, so we likely have an issue there. Under the knownissues.txt file I have a note to include a jumper to disable C1003.

[Sudo]

Yes, it has to do with inrush current. The general rule is that maximum load perceived by the USB power rail prior to enumeration of a 500mA device needs to be below 10uF || 44 ohms. But once enumerated to a 500mA device, you can switch on the addition load. I usually solve this problem by using a FET to switch on remaining loads with soft start circuit or apply a PWM prior to switching it on 100% duty cycle. I've violated this spec several times and it still worked, but I can't say to a what extent. It may all depends on the USB upstream hardware you are using.

Take a look at the USB 2.0 spec. Chapter 7.2.4.1.

http://www.usb.org/developers/docs/usb20_docs/#usb20spec

[kb1gtt]

I learn something every day. Thanks for the suggestion on how to correct this potential issue and thanks for pointing me to the chapter in 650 page USB spec.

[AndreyB]

tiny issue: current LCD mounting holes are too small for the Chinese M3 stand-offs, need to be just a bit larger.

[kb1gtt]

Added to know issues list, we'll make sure this gets resolved in R0.2

[abecedarian]

If the difference is only a few 0.001" and there aren't any close-by traces, maybe see about locating M3 thread-cutting screws. They'll 'ream' the hole slightly and have standard machine thread pitch of 0.5. Fastenal might be one source.

[kb1gtt]

Per the USB inrush thing, I see PG7 section 2.4.2. http://www.ftdichip.com/Support/Documents/AppNotes/AN_146_USB_Hardware_Design_Guidelines_for_FTDI_ICs.pdf then from here https://www.sparkfun.com/datasheets/IC/FT232R_v104.pdf pg 8 table 1, I see that the default is for PWREN to be on pin 14. I'm adding the PMOSFET now, as well I'm going to add those USB LED's, ferrite, and additional ESD protection.

Hmmm, should I include a diode between Vusb and Vmcu? Such that the 5V switcher doesn't back feed the USB power? Unless someone specifies differently I'll be adding a diode to do this.

Hmmm, I see we can also isolate the USB as noted in this app note, this would be a handy way to avoid ground loop issues. http://www.ftdichip.com/Support/Documents/AppNotes/AN_143_RS232_RS422_RS485_Auto_Sensing%20_and_Isolation_Design.pdf To me this seems kind of pricy, so I guess we'll ignore the isolation thing for now. Most people are using laptops and engines that are isolated via rubber tires, so GND loops will be minimal to begin with.

[Sudo]

Diode to the USB power is a good idea. I've use ideal diode IC to reduce the voltage drop to 'OR' USB power with other sources. But you may not need it if you don't care about the diode drop.

http://www.linear.com/product/LTC4411

[kb1gtt]

I like the low loss diode thing, but I think cost would be an issue for some that are looking to keep the budge low. $3.85 for a diode is a bit much. At .7V and .5A, we are dealing with aprox .34W. Also that's not in normal use, that's just when powered via USB, which is generally when tuning. So I think for $3+ the typical user would prefer the lower cost / good enough option.

Thanks for the link, I was not aware of such a diode. Good find.

[AndreyB]

SD card pinout is wrong
Should be

but it is


No trivial way to fix this, no SD card for v 0.1

[AndreyB]

TTL USB port is also messed up. Should be

but it is


No TTL USB port on v 0.1

[AndreyB]

Well, I needed some good news today so I've soldered the 20x4 screen:

[kb1gtt]

I agree that the SD is a real pain to hack and make it work. Basically you would have to lift the SD card pins and install small wires to cross it over, which is a real pain when dealing with such small components. This and several other items have been addressed in the R0.2. Once this is further validated, R0.2 will be pushed to the SF repo. For now keep the feedback coming and I'll keep making the updates.

[AndreyB]

For a hack to make it kind of workable, one would need to pull pins from the 25x2 before soldering them in (7 pins so far: three VCC pins should be removed, MISO/MOSI pins and UART pins). This way one can solder a wire from the back of the board to the top of the discovery if it snapped into the 25x2 headers.

Anyways, some more feedback
1) can we please flip CAM/CRANK positive and negative on the connector to make it compatible with OBD-I Honda? I know you can flip it logically but I want the signals to be same as with real ECU

2) can we please add a 2nd VR chip? that's for 3rd channel needed by Honda. Not sure if we want this, but we should think about it.

3) we need to move JP212 further away from LCD mounting hole. The nut is too close to the pads, this looks scary

4) what do we have for VTEC solenoid? See http://rusefi.com/forum/viewtopic.php?f=3&t=621#p9766 - 2 amps source. Would we have to run a couple of our smaller mosfets in parallel?

5) kind of related to #4: do we want to separate VP lines of our three hi-side mosfers? This case we gain more flexibility by making some +5 and some +12.

[AndreyB]

ICM output on my Honda is open drain, I am using one of the VNS14NV04 channels to control the ignition control module. The ICM applies +12v to this mosfet. You've seen it working on that horriblly-running Honda video.

Today this VNS14NV04 has failed. Is this my typical luck or am I doing something wrong?

[kb1gtt]

My first guesses would include, over current and more energy absorbed by the voltage clamp than this chip can absorb. I would expect the over temperature would catch these, so my next finger to point would be a failed ICM. I'll look into the magical coffee stain and see if I can make some more predictions.

[AndreyB]

Another observation from today "tune day" with @: noise on the CKP line:

http://i.imgur.com/uP0qKe7.png and http://i.imgur.com/0qNs7Tp.png

The logs are available @ https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/1995_accord/Sunday_aug_17_2014/ - you would need to place them into 'out' subfolder next to the dev console jar. Latest version has some zooming improvements.

[Nobody]

.

[AndreyB]

If you are trying to directly drive a coil with that MOSFET...

I think that's not an issue - there is a ICM (ignition control module, whatever it is) between the MOSFET and the coil

[kb1gtt]

There is an ignitor which Honda called and ICM. The ICM is part of the distributor cap and is pulled low via transistor. I don't know if the OEM has a voltage clamp or not. My guess is that a properly operating ICM bounces between 12V and gnd. The primary side of the coil which needs to sustain the 400 to 500V kick is on the other side of the ICM.

I think his ICM and coil are failing.

[kb1gtt]

Oh, also I think this because I had a Honda CRV which had a very similar setup and it failed very much like what russian has explained. With that CRV I found the plug gaps grew to large which was due to a lack of maintenance and erosion. I seem to recall the gap was supposed to be .037 and grew to .044ish. The ICM then needed to absorb a larger kick back voltage spike, which was to much heat for the ICM. The ICM eventually failed to clamp the primary voltage to safe limits, which then caused the coil to over voltage and burn out. I fixed it by replacing the plugs, coil(s), and ICM. I had first tried to change just the coil, which I then burnt out as the ICM was failing to keep it safe. So I then had to replace both ICM and coil and that fixed it completely.

[AndreyB]

Let's take a step back. We know that there is '40Hz noise induced by the TCM', maybe once we resolve that noise we would also resolve the 'another noise while TCM is disconnected'?

So, TCM goes back on. My multimeter tells me that "Shift sol ctrl" wires - A3 & A5 on this diagram - are producing a 40Hz signal. I guess that's the noise source.

Now - how does it get into our VR wires? I've double-checked my capacitors - C101-C102-C103-C104 are all there. Is this schematic asking for larger caps? Any caps to GND? Any other ideas?



Oh, here is now the noise looks like:

that's with ignition on, engine not running.

[Nobody]

How is it wired and anything going to ECU? It is very likely a PWM to control shift pressure and that's it's base frequency. The other output is for torque converter lockup, that is usually ECU driven in light load situations. If your having problems that are derived from TCM sitting idle, then well...

As mentioned before, you really need an oscilloscope to correctly chase gremlins. It may still be power supply as previously noted.