Industrial engine electronic management system development - HBA style

[rmeyers]

This does point to two possible negatives of Speeduino:
a) We would be dependent on others to approve our code and include it in future Speeduino updates. View attachment 77196

It seems that all of the embedded code is licensed under the GPL V2. As such, you can never be cut off from the code. Start your own GitHub or GitLab project and compile and test your own code. You of course would have to change the name.

 

[jbiplane]

I quoted production of Speeduino assembled PCBA in China.
4...10 prototype units od 0.4.4woud be ~120USD each
100 would be ~50 each

For speeduino exist smaller and simpler boards: https://github.com/turboedge/SpeedyBoards

One of speeduino contributors DC WERX proposal
The ua4c is a better option as it would offer 4 fuel and 4 ignition channels as opposed to 2 on the no2c. The ua4c has more inputs and outputs aswell.
The ua4c fully assembled is $110 USD and $130 with aluminium Hammond enclosure. The no2c is $130 fully assembled . Add $18 USD if you want an arduino included with any of them.

 

[jbiplane]

The good way is a bit rework speeduino cutting of arduino board + place PCBA on throttle body excluding many wires.

Says one Portugal guy made much smaller (but completelly compatible) boards



His comments. With the new year comes a new product from ATLAB. Making a tradition of exceptionally compact PCBs I proudly announce a fully capable standalone ECU capable of driving up to 8 cylinders, VR conditioner on board, built in Bluetooth and much more. The size is only 96x60mm!!
The price: just like the board is tiny. Just 175€ ! Based on open source Speeduino project by Josh Stewart !

Whis (or other speeduino) guy can make reduced version of speeduino board cutting of many thingies for local comunity and allow you concentrate on other components.

 

[Hot Wings]

6) While the Speeduino effort/community will be very useful to OpenAeroEFI, even if it goes belly-up it won't doom the effort here. I imagine we'd just continue using the last, best version of the Speeduino executable file and soldier on. Maybe the same holds true for TunerStudio. ]

This is a problem for all things electronic. I still need a computer running XP to use some hardware that would cost quite a lot to replace. All we can do is make the software as modular as we can with good documentation. Keep the hardware as generic as we can. Compared to Speeduino this project will likely always have fewer people/resources.

I quoted production of Speeduino assembled PCBA in China.
4...10 prototype units od 0.4.4woud be ~120USD each
100 would be ~50 each

Thanks! That is very helpful information.

I've been trying to figure out if surface mount or through hole was a more logical path for this project. The average person can't solder surface mount components. Surface mount then requires a completed board. The cost would be more but it sure does make the boards smaller. Surface mount also means that we can completely bypass Arduino hardware and just design an Arduino compatible device with upgraded chip specifications.*

$5000 is more than I would like to risk unless I was pretty sure I could at least break even on the deal. Sounds like a job for Kickstarter?

Through hole should still be an option for those that may want to build their own?

*the typical Arduino chip set is generally of unknown heritage and use the lower temperature rated versions.

 

[Vigilant1]

I've been trying to figure out if surface mount or through hole was a more logical path for this project. The average person can't solder surface mount components. Surface mount then requires a completed board. The cost would be more but it sure does make the boards smaller. Surface mount also means that we can completely bypass Arduino hardware and just design an Arduino compatible device with upgraded chip specifications.*
. . . .
*the typical Arduino chip set is generally of unknown heritage and use the lower temperature rated versions.

Looking for a way to avoid hand assembly of a Speeduino board: Is there a way to trust/certify that one of the existing mfgrs is using (legitimate) chips/components with specs appropriate for our use? Speeduino sells empty Speeduino PCBs, can we buy baggies of legit/good parts and have them wave soldered somewhere local in small batches? Maybe work with the Portugese ATLAB guy in Valery's post: Use his board, he does the assembly, we work together to figure out how best to assure high-quality components are on that board. We may be running lawnmower engines, but they ain't on lawnmowers anymore.

Thinking just about the Arduino board (much bigger market than Speeduino)--is there a known reputable manufacturer of ones with high quality parts and an audit-trail through their supply chain to the retailer?

As far as size--is this critical? I'm guessing no one will have any trouble finding room in their plane for even the largest Speeduino board. More space = (potentially) better cooling of components?

 

[Hot Wings]

Is there a way to trust/certify that one of the existing mfgrs is using (legitimate) chips/components with specs appropriate for our use? << >>

As far as size--is this critical? I'm guessing no one will have any trouble finding room in their plane for even the largest Speeduino board. More space = (potentially) better cooling of components?

Trust? It's about all we have without having a guy on site for QC. If we buy the parts form one of the standard US suppliers we have a pretty good chance of getting genuine parts but the cost is greater.
<< >>
Size really isn't critical but the smaller the better. With surface mount I think we can keep things down to about the size of 2 decks of cards. The through hole boards for a similar project ended up being about the size of a standard calculator. One of the biggest real estate hogs, for me, has been the connectors to the outside world.

Related: Manifold Absolute Pressure sensor. On the electronics board with a tube running to the manifold, or mounted on the engine with just the 0-5Volt signal going to the board?

Mass flow sensor rather than, or in addition to, MAP and TPS? Using a 3D printed combination injector housing and sensor mount something like this mass flow sensor ($<20) might work?

 

[Vigilant1]

Trust? It's about all we have without having a guy on site for QC. If we buy the parts form one of the standard US suppliers we have a pretty good chance of getting genuine parts but the cost is greater.

Well, are there places that will wave solder a PCB for us if we come through their door with a PCB and all the component leads already shoved through the holes?
<< >>

One of the biggest real estate hogs, for me, has been the connectors to the outside world.

I think connectors are also one of the biggest potential failure points. (at the board, and at the sensor/the coil-injector)

Related: Manifold Absolute Pressure sensor. On the electronics board with a tube running to the manifold, or mounted on the engine with just the 0-5Volt signal going to the board?

Dunno. The inlet manifold should be a relatively cool spot even on this air-cooled engine, but these engines vibrate a lot. I'm not sure that mounting electronics to them is the best way to go.

Mass flow sensor rather than, or in addition to, MAP and TPS? Using a 3D printed combination injector housing and sensor mount something like this mass flow sensor ($<20) might work?

Are we off the Speeduino reservation now? I didn't see any support for a MAF on their site, but I didn't dig deep.
Heretical thought: A MAF used with a "stock" Arduino (get a genuine one in a version with enough memory for the code and mixture maps) could be a low-budget, high-reliability, open-loop "Redneck EFI Deluxe." The MAF (one per cyl) + a TPS does everything the "governor" knob does in the Redneck design. Keep the manual mixture control knob (knobs--one per injector) for fine tuning in flight via EGT (for extra credit, we could add an EGT sensor to the inputs and use it to do the fine-tuning without pilot action, so a total of 4 sensors (2x EGT). But, we'd probably want to keep the knobs to allow manual trimming if desired. No need for anything Speeduino (no Speeduino boards, no Speeduino GitHub back-and-forth, etc.) It's just our local, modest, focused project and we write and own the tiny, clean code. We wouldn't try (as Speeduino does) to include compatibility with a lot of sensors and injectors: We only need to be sure it works well with one widely-available and high-quality model of each thing. The Redneck EFI author said there's an empty spot for a second injector on the Arduino he used, ones with a larger number of digital input and output pins are available now--enough for a 4 cylinder engine I'm pretty sure (if someone wants that). No ignition, no CANBUS, no WIFI (unless we want it)--just a low parts count, a low hardware bill, compact code, and a very vanilla goal: reliable fuel delivery to the engine. No frills. I'm just putting it out there . . .

A big-picture question that may affect a lot of things: Will A) a single higher-cost OpenAero EFI (with near-MILSPEC connectors, high-cost parts assembled in a small-batch, high-cost way, etc) give us better Mean Time Between Engine Stoppage than B) two units built using OTS components and selectable with the flip of a switch? It sounds like the cost of both options is maybe going to about the same. B would be quicker to implement, less hassle over time ("Hi, I'm back with more boards for soldering!"), less programmatic overhead (buy stock OTS finished boards as they are needed, no need to order a big batch of parts to (eventually) build finished boards). If we guard against a cause of failure that could kill both units (dirty power/overvoltage, shared sensors, etc), I suspect B might even have higher total-system reliability.

 

[Vigilant1]

I'm hoping that the uneven induction timing of the V-twin isn't a reason to abandon batch injection and go to sequential injection. IIRC, Ross uses batch injection with the SDS systems, and he finds that sequential offers no advantages in airplanes. Would the induction geometry of a little V-twin or (especially) it's uneven induction rhythm require us to consider sequential? I hope not.

 

[rv6ejguy]

Depending on manifold runner arrangement and length, you may or may not have issues with batch firing on this engine configuration. You'll certainly need one injector per cylinder though.

You guys haven't addressed noise concerns at all. If you study most established ECUs, you'll see a lot of components on the PCBs to negate these effects and a ton in software. This is a really big deal and especially so in aircraft applications.

Some of the comments here don't make sense on something being designed for this application. It's straying away from low cost, simple, reliable.

 

[Hot Wings]

It's straying away from low cost, simple, reliable.

We can't have all three. Low cost and simple is already provided by the OEMs. Un-intuitively reliability does sometimes require complexity. The recent discussion about the new 737 Max's system where some postulated that reading from only 1 AOA sensor could cause problems demonstrates this.

 

[Hot Wings]

Well, are there places that will wave solder a PCB for me if I trot through their door with a PCB and all the component leads already shoved through the holes?
<< >>

Are we off the Speeduino reservation now? << >>
A big-picture question that may affect a lot of things: Will A) a single higher-cost OpenAero EFI (with near-MILSPEC connectors, high-cost parts assembled in a small-batch, high-cost way, etc) give us better Mean Time Between Engine Stoppage than B) two units built using OTS components and selectable with the flip of a switch?

<< >>
The last time I actually saw a wave solder setup was while I was still in junior high. I guess it's still done commercially? But for the amount of soldering needed it's only a long evening by hand for the through hole version.

<< >>
MAF is not part of the Speeduino core, but could be integrated into the software. I'm not aware of any off the shelf mass flow sensors that are appropriate for a <50hp engine. This would have to be a from scratch option but it might be worth it in the long run?

<< >>
I think the only way to know which way to go is to design and get some quotes. Machine placed and soldered surface mount should be better than hand soldering through hole. We will have to have some electronics mounted to the engine in the form of sensors. Those can be had off the shelf in automotive grade. The thing that bothers me, personally, is the temperature rating of the average Arduino board. The MCUs are generally of the 85C rating. The cost difference between those and 105C is on the order of$0.25 for the ones I've priced. I'd like to go to 125C rated chips but so far I haven't found direct substitutes.

I'm hoping that the uneven induction timing of the V-twin isn't a reason to abandon batch injection and go to sequential injection. IIRC, Ross uses batch injection with the SDS systems, and he finds that sequential offers no advantages in airplanes. Would the induction geometry of a little V-twin or (especially) it's uneven induction rhythm require us to consider sequential? I hope not.

I'd not worry about sequential vs batch. There is plenty of computing power left for us to use sequential. From a hardware view there is little difference. So it makes sense to avoid the uneven fire problem from the start and develop using sequential? There a lot of things we can do that sound like, and could be, unnecessary extras. As long as it's in software is costs us nothing but development time. Automatic sensor calibration and health check at start up is one example.

 

[nerobro]

I love where speeduino is going. I'm sad I only discovered it now, and here.

So... I have a proposal too. Lets go "even simpler". Airplane engines are nearly ideal for simple FI setups. Airplane injection has been around since.. what.. the late 1930s? That should tell you how simple this can go.

But I"m going to re-read the whole thread before I do a bit of a brain dump.

 

[blane.c]

This is fairly minimal.

 

[Vigilant1]

<< >>

I'd not worry about sequential vs batch. There is plenty of computing power left for us to use sequential. From a hardware view there is little difference. So it makes sense to avoid the uneven fire problem from the start and develop using sequential?

I don't think it is just software and processing. We can't know what the valves are doing using only the CAS, since the crank goes around twice for a complete engine cycle. If we want the period between injection and intake valve opening to be the same for each cylinder (which is the only reason to do sequential), then I think we'd need to add >another< sensor for camshaft position. Or, if the reporting interval and latency of a pressure/flow sensor (MAF or MAP) was right and if one were placed in each runner I suppose we could figure things out from that, rather than using a camshaft position sensor. I know very little about them. Uggh. If sequential adds any hardware (e.g. camshaft position sensor) or results in programming functions that reduce reliability (e.g. comparisons between two sensors, so now both sensors are mission essential), then it would seem more attractive to just do batch injection. If batch injection results in differences in mixture between the two cylinders, it's straightforward to deal with that by adjusting the injector duration at the time. There are likely to be differences between the cylinders anyway not related to this "how long does the fuel sit in the runner" factor, so just making sure we can address that (a simple trim pot on the panel so the pilot can make the EGTs the same?) will be a flexible approach.

There a lot of things we can do that sound like, and could be, unnecessary extras. As long as it's in software is costs us nothing but development time. Automatic sensor calibration and health check at start up is one example.

Just an observation: In the 1970s and 1980s, the C-5 Galaxy was infamous for its poor mission readiness rate. It was broken a lot. It was an incredibly complex airplane with an interdependency and integration of systems that was remarkable. The system that was on the plane to help find and log problems so they could be fixed was known as the Malfunction Detection Analysis and Recording System (MADAR, and later MADAR II). As it turns out, the MADAR system itself was one of the most troublesome and unreliable systems on the plane. At least in that case, stacking on more technology to address the problems caused by technological complexity wasn't especially effective. But, every case is different.

 

[blane.c]

Why an additional sensor on the camshaft? Why not "the" sensor on the camshaft?

 

[blane.c]

If the trigger is on the crankshaft for two strokes and on the camshaft for four strokes then other than that is if you need to adjust timing for a "V" engine, between two stroke and four stroke systems as far as timing goes.

 

[Hot Wings]

I don't think it is just software and processing. We can't know what the valves are doing using only the CAS, since the crank goes around twice for a complete engine cycle. If we want the period between injection and intake valve opening to be the same for each cylinder (which is the only reason to do sequential), then I think we'd need to add >another< sensor for camshaft position.

There are ways to do this with a single sensor, but for an add on system it's not practical. But a cam sensor is something to be considered. On one of the other sites they were using the MAP to log the cam position by detecting the intake pressure changes. I don't know how well it works but it shows that there are clever ways to do things. If it weren't for the retrofit consideration I'd make the cam sensor my primary rotation sensor. This could also make hand starting on the first blade practical.

Yes, I agree that false positives are almost as much a problem as not detecting a fault. I don't know any of the details of the system mentioned but using the 0-5 volt signals that are common has always bothered me. There is way too much chance of signal corruption with poor contacts. 4-20mA is far more tolerant when dealing with analog data over any significant distance, but we have to work with what we have available for sensors.

Why an additional sensor on the camshaft? Why not "the" sensor on the camshaft?

Because getting access to the camshaft means drilling/machining holes for most of the industrial engines. Bolting a toothed wheel to the crank is much easier. This is one of the reasons I'm partial to converting the vertical engines to HZ. The oil pump on these is generally run from the camshaft and this gives us external access to the camshaft with bolt on parts.

 

[blane.c]

Maybe in setup it asks single cylinder or twin and if twin it asks opposite or "V" and if "V" it asks for degree difference?

 

[blane.c]

Usually valve covers are accessible and house either a camshaft or rocker-shaft either will suit our purpose. If you drill a hole thru the valve cover into the round end "center" of either a rocker-shaft or a camshaft and epoxy or press fit a dowel long enough to come out the end of the cover and affix the sensor, put an appropriate seal in the hole and around the dowel?

 

[nerobro]

Why does it matter? I'd just put the pickups on the flywheel. You'll end up with two squirts per intake event.... enjoy your "multi fire" injection.