Teensy 3.5 powered turbine FADEC for land speed record attempt

[noisymime]

As an offshoot of the work I've done with the Speeduino ECU, I've been working the last few months to adapt the project into a FADEC turbine controller rather than piston engine controller. This is for use in a turbine powered streamliner, Turbinator II, that is currently the fastest wheel driven vehicle with a 2 way average speed of 458MPH.

It's been a bit of a mad scramble to get the hardware designed and tested, but the team is now at the point of being ready to run things in the car and will be heading to Bonnevile over the next week in the hope of breaking the 500MPH mark (Which it has done previously, but not with a return run).

The unit is powered by a Teensy 3.5 and primarily controls the fueling for the turbine as well as managing the startup sequence and providing an array of engine protection functions.

Forgive the terrible pics, but I keep forgetting to take any decent ones in the scramble




Bare units straight from PCBA



Board with connectors and Teensy mounted in enclosure



Unit being mounted in the car


The hardware is pretty rough, but between crazy long manufacturing times due to IC shortages and a somewhat moving target in terms of requirements, I'm pretty happy with the outcome so far and everything appears to be functioning as expected. There's certainly a few quality of life things that can be added for future revisions, but this will do everything needed for this run.

Hopefully things go as planned over the next 2 weeks, but either way I'll report back with how things go.

[noisymime]

Here's the car with things up and running today

https://www.facebook.com/1485949169/...1004675483519/

[noisymime]

Well has been a week of mixed results with this project. Overall the electronics side of things worked pretty well. Some noise related issues that are likely wiring related, but overall the Teensy based turbine controller performed a treat.

Unfortunately due to a number of issues on the car it wasn't able to make our test pass until the third and final day of World Finals at Bonneville. There wasn't time to make a full 5 mile pass as as there was too much that needed shakedown testing on the shorter 3 mile run first.But that run was very successful!

The car was able to run the fastest 1st, 2nd and 3rd mile speeds in the history of Bonneville Land Speed Racing, which dates back to the 1920s.
Some of the major data points:
Peak GPS speed 447.9mph
3 mile average of 420mph
Fuel consumption peaked at 2100 pounds per hour, resulting in a shaft horsepower of 4185.

All with an engine controlled by a Teensy 3.5

[tschrama]

Incredible!!! A teensy controlling 4185 horsepower ��

[noisymime]

Thought I'd give a bit of a heads up for anyone interested. This car will be at Bonneville Speedweek from August 6th and again aiming for a new world record (C'mon 500mph!) in its class (Fastest wheel drive car). Will be running the same hardware as last year, that is a Teensy 3.5 powered FADEC controlling the 4000+hp jet engine, but with some significant changes on the firmware front. 3 units are set up and identically configured to allow for hot swap if needed, with parts available for another 2 if everything somehow goes to crap.



For anyone curious about it, here's a quick video of the (1 and only) run from 2021.

[joepasquariello]

Very cool. Can you tell us a little about the hardware and software? I'm curious what is the control frequency, how many analog I/O, whether you are using on-board ADC or external, etc.

[noisymime]

Very cool. Can you tell us a little about the hardware and software? I'm curious what is the control frequency, how many analog I/O, whether you are using on-board ADC or external, etc.

Hardware is based on the Speeduino ECUs I've done, with these using the same circuit designs for power regulation, RPM inputs, CAN, analog inputs and general purpose inputs/outputs. The fuel outputs are quite different though and there is the addition of a pair of MAX31855 based EGT inputs. The analog inputs use the onboard ADC with the signals (A mix of 5v transducers and resistive) being filtered, run through an OpAmp and then clamped. They also run off their own precision referenced regulator rather than the main one.

The main control loop runs at about 19Khz with the SD logging on, which is plenty fast enough for what's needed here. It's basically looking up a main 16x16 fuel table with a few other tables used for compensation of various elements. Compared to an automotive ECU it's quite simple, but it does also have a whole heap of engine safety checking, particularly during the (6 stage) startup sequence, to avoid any damage to the turbine. Even brief over temp and over speed events can be catastrophic (aka $$$$$$ expensive) so need to be avoided under all circumstances.

[joepasquariello]

Hardware is based on the Speeduino ECUs I've done, with these using the same circuit designs for power regulation, RPM inputs, CAN, analog inputs and general purpose inputs/outputs. The fuel outputs are quite different though and there is the addition of a pair of MAX31855 based EGT inputs. The analog inputs use the onboard ADC with the signals (A mix of 5v transducers and resistive) being filtered, run through an OpAmp and then clamped. They also run off their own precision referenced regulator rather than the main one.

The main control loop runs at about 19Khz with the SD logging on, which is plenty fast enough for what's needed here. It's basically looking up a main 16x16 fuel table with a few other tables used for compensation of various elements. Compared to an automotive ECU it's quite simple, but it does also have a whole heap of engine safety checking, particularly during the (6 stage) startup sequence, to avoid any damage to the turbine. Even brief over temp and over speed events can be catastrophic (aka $$$$$$ expensive) so need to be avoided under all circumstances.

Thanks for the insights. Just a great application and must be a lot of fun to see it all work. There are some recent threads discussing best practice for SD logging, and that's something I need to do in my application which runs at about 10 kHz. If you are logging data at relatively high frequency, I'm curious about your data buffer/write strategy and what frequency of data you've been able to log.

[noisymime]

Thanks for the insights. Just a great application and must be a lot of fun to see it all work. There are some recent threads discussing best practice for SD logging, and that's something I need to do in my application which runs at about 10 kHz. If you are logging data at relatively high frequency, I'm curious about your data buffer/write strategy and what frequency of data you've been able to log.

Logging to the SD is only at 30hz with about 110 bytes per entry (Lots of packed bytes), so it’s not too much of a problem in this case. We’ve tried at 100hz and there was also no issue. Using the SDFat library + preallocation + ringbuffer seemed to make for a very nice combination that results in essentially no blocking or other impacts to the critical functions.

We only need fairly low speed logging though, so I can’t really comment on things requiring over 100hz logs.

[joepasquariello]

Logging to the SD is only at 30hz with about 110 bytes per entry (Lots of packed bytes), so it’s not too much of a problem in this case. We’ve tried at 100hz and there was also no issue. Using the SDFat library + preallocation + ringbuffer seemed to make for a very nice combination that results in essentially no blocking or other impacts to the critical functions.

We only need fairly low speed logging though, so I can’t really comment on things requiring over 100hz logs.

Thanks very much for the info. I've seen preallocation mentioned in that other thread, so I'll have to read about it. Good luck at Salt Lake, and let us know how it goes.