Speeduino is now on Github Sponsors (Rather than Patreon): https://github.com/sponsors/noisymime
For discussion of Speeduino compatible boards designed / built by other members of the forum and for guidance around making such a board
User avatar
By PSIG
#38805
pazi88 wrote:
Sun Oct 27, 2019 7:03 pm
OEM's seem to incorporate active current sensing by the processor and prevent this kind thing in ecu code, but not sure how to do that for speeduino.
It would or could be a single section of a Power Distribution Module, though that's a bit of overkill for simple protection IMO. Installing a little spade connector header for common ATM or ATC-style circuit breakers is a mid-level protection example that is simple and takes little space. However, protection should be provided by the user at the correct location to protect the entire circuit, and should not need to be added as a separate device inside the components. To be blunt, if a user doesn't want to have stuff damaged by any failure of anything, they should be taking the standard steps necessary to protect it. :roll: Is that not reasonable?

David
By pazi88
#38924
I tried to do lot of stress testing with assembled m52 PnP speeduino using real components, but I really can't get the traces to burn or even hot. Also even with big spark gap and the coils/spark plugs close to ecu, I couldn't cause any noise to speeduino inputs. I probed around the ecu with scope and all is clean. So there shouldn't be any ignition related noise with this design when assembled correctly.
Image

I had the setup running high RPM for hours and tried different dwell settings. With 1-3ms dwell there is basically nothing happening the ecu stays cold. And no wonder, because for example 6000 RPM and 2ms dwell was only 18% duty for the coils. But then with higher dwells the duty for the coils gets high really fast because it's wasted spark. Like here, this is over 50% duty for the coils:
Image

Image

Leaving the system running like that for couple of hours warms up the ecu case quite a bit, so in hot engine bay in e36 for example it could be possible to overheat the thing :?: So high dwell (4ms), hot engine bay and constant high RPM could maybe cause the traces to burn.But there shouldn't be any reason to run dwell that high. I for example run 1.5ms dwell in my m52 turbo and that makes 560hp at the crank using e85. Then if the coil(s) are shorted, it seems that it's really possible to burn the traces. It doesn't require much to get those smoking. Lastly even with good condition coils, the traces (and coil) gets destroyed immediately if the IGBT body touches the case. Like for example in this case when there was manufacturing fault in the IGBT which did lead the IGBT body to touch the case through insulation:
Image

But well in any case. I would recommend using reasonable dwell settings with this PnP ecu to avoid possible problems. I changed the dwell from 2ms to 1.5ms in base tune, because that should work in most cases.

It also seems that even the 4.7nF cap for C25 isn't small enough for 60-2 trigger wheel. The speeduino 0.4.3 design uses originally 10nF cap, and when calculated with the 1k resistor in the line that should be plenty enough for 60-2 trigger wheel. It works nicely with simulated signal from speedystim for example. But with real trigger wheel and hall sensor, you don't get that nice and even square wave that you get with simulator. And in reality, because there is 1k pull-up to 5v, the voltage to high state goes through 2k ohms worth of resistors. Which makes the signal rise time way too slow and there will be problems from 6000 RPM upwards. So that's why I changed to 4.7nF cap originally. But with high RPM and the trigger wheel vibrating slightly, the pulses from the teeth can still get short enough to cause problems. So after testing with real trigger wheel and hall sensor, I ended up using 1nF cap for C25. That gives nice and robust signal for the mega. I did change that for the BOM files.
User avatar
By exvils
#39333
i had my trigger filter set to medium and it worked fine.. i will try changing the cap..
About the dwell time - dwell isnt the issue, its old coils i think. Mine pnp unit/mosfets didnt heat up at all, everything was working fine, and then coils failed while running on oem ecu, so driver decided to swap it to speedy and you know the aftermath :D
I noticed that someone had build here speedy ecu with teensy, that used heat/current limiting transistors. So i was thinking if it could be utilized on pnp unit (tho i know it has like 6-8 pins and there is no space for traces - and probably capabilities on mega to run them)
By pazi88
#39334
Yeah with shorted coils, you are going to have problems :D

I looked about those IGBT's but it's not easy to include those to the PCB, because there is no to220 package available of those. Especially now when I have new more crowded design coming :roll:
By Jamppo
#39338
One properly sized fuse per coil should be enough to protect ecu and tell user that something is not correct if they start blowing.
By pazi88
#40173
It's 2020, so good time to step up a notch. Here's rev2.0 of the m52 design too:
Image

This rev2.0 is mostly identical to rev1.x ones, but this also supports 6-cyl fully sequential at hardware level. There is also few smaller changes, like more clearance to ignition traces, and added header for reset control.

And the 6-sequential support wouldn't be anything without software support, so here's branch that allows 6-cyl fully sequential with this pcb design: https://github.com/pazi88/speeduino/tre ... ential_BMW

Thanks for Ileeezi for making that possible. But remember that the code is still just experimental, so there is no guarantee that it works 100%. Here's the code running from speedystim:
Image

The files for PCB are available at github:
https://github.com/pazi88/Speeduino-M5x ... 0documents

Note that there is two options as for BOM and also few solder jumpers. The normal BOM works with the current official speeduino firmware just like rev. 1.x PCBs did. But you also need to solder the jumpers on the PCB. The sequential BOM works with that custom firmware and then the solder jumpers are left unconnected. You can't mix and match those, or the PCB will not work properly. So if you are making one, be extra careful.

Hopefully the 6-cyl sequential will be supported in official firmware in future, so I could get rid of the "legacy" BOM and extra jumpers. Or that doesn't even require the 6-cyl sequential support. Just the new bmwPnP board definition, semi sequential for injection and wasted cop for ignition is enough for that.

Oh and one thing. In order to use the sequential there is one more complication. The stock cam sensor needs to be changed to m52tu/m54 hall version for example. And to power that the jumper on the pcb needs to be set at 12v.
User avatar
By My.Yeremenko
#41061
Hey. if I understood correctly, to start sequentially, do I need to set the JP7 jumper to 12v, then change the native M52 cam sensor to cam sensor from m52tu / m54? I also noticed that you have a note in your specification file for “m52 in sequence”: “Note! The Green ones are only installed if hall crank sensor is used, instead of stock vr-sensor (s). In that case the vr-conditioner is not installed at all "but there is no green mark in the table.
By pazi88
#41063
My.Yeremenko wrote:
Fri Feb 21, 2020 9:51 pm
Hey. if I understood correctly, to start sequentially, do I need to set the JP7 jumper to 12v, then change the native M52 cam sensor to cam sensor from m52tu / m54?
True. The original m52 cam sensor is strange frequency type which uses phase modulation and that's why m52tu / m54 intake cam is needed for example. I recommend those, because those are almost direct swap. And the operating voltage is 12v which can be provided by jp7.
My.Yeremenko wrote:
Fri Feb 21, 2020 9:51 pm
I also noticed that you have a note in your specification file for “m52 in sequence”: “Note! The Green ones are only installed if hall crank sensor is used, instead of stock vr-sensor (s). In that case the vr-conditioner is not installed at all "but there is no green mark in the table.
Sorry that was mistake. I used m50 BOM as base, and forgot to remove that. m52 pcb doesn't even have vr-conditionr option.
By titiz
#41262
Hello everyone, I have a question,
I'm mounting an m52b30 and wish to install your speeduino pazzi mount, and thank you for your sharing and involvement. If I use the M54 crankshaft sensor, I must drill into the block and place it, which is in the block (same as S52 us because M54b30 crankshaft), it is identical to the pinout for the speeduino, is there a modification?
Because I know it is more stable, especially in laps after 4500 rpm. Thank you .
By pazi88
#41263
titiz wrote:
Mon Mar 02, 2020 8:25 am
Hello everyone, I have a question,
I'm mounting an m52b30 and wish to install your speeduino pazzi mount, and thank you for your sharing and involvement. If I use the M54 crankshaft sensor, I must drill into the block and place it, which is in the block (same as S52 us because M54b30 crankshaft), it is identical to the pinout for the speeduino, is there a modification?
Because I know it is more stable, especially in laps after 4500 rpm. Thank you .
Yes that can be done without problem. But you will probaply see zero difference from that. The crank mounted trigger wheel is only done to acheive better missfire and rough running detection than with trigger wheel mounted to rubber damper. It's not needed for ignition/injection timing accurasy.

Anyways you will need to buy 12514592703 wiring harness adapter to run rear mounted cps in ms41 that came with front mounted cps or make that yourself.
Image
  • 1
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
Decoders - What do you want to see?

It is completely possible to just do it though. T[…]

Alrighty, had some time over the weekend and its w[…]

Perhaps post your tune. And a log of it cranking/r[…]

Hi JHolland Thanks for the comment. This gives me[…]

Still can't find what you're looking for?