Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 10 of 10

Thread: Teensy 3.5 powered turbine FADEC for land speed record attempt

  1. #1

    Teensy 3.5 powered turbine FADEC for land speed record attempt

    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

    Click image for larger version. 

Name:	236201374_989563118495574_6154632236084214280_n.jpg 
Views:	54 
Size:	87.4 KB 
ID:	25986
    Click image for larger version. 

Name:	239406725_533240374419005_3346313794364139420_n.jpg 
Views:	39 
Size:	174.0 KB 
ID:	25988

    Bare units straight from PCBA

    Click image for larger version. 

Name:	236408786_1283101088785060_5309538028201356524_n.jpg 
Views:	58 
Size:	96.2 KB 
ID:	25987

    Board with connectors and Teensy mounted in enclosure

    Click image for larger version. 

Name:	242742767_880100836268716_3611769623964978107_n.jpg 
Views:	45 
Size:	94.9 KB 
ID:	25985

    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.

  2. #2
    Here's the car with things up and running today

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

  3. #3
    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

    Click image for larger version. 

Name:	244000031_10227207101311786_2537541471345118934_n.jpg 
Views:	37 
Size:	80.0 KB 
ID:	26046
    Click image for larger version. 

Name:	244318325_10227207028749972_8072989200173216436_n.jpg 
Views:	39 
Size:	33.6 KB 
ID:	26047

  4. #4
    Senior Member
    Join Date
    May 2019
    Posts
    133
    Incredible!!! A teensy controlling 4185 horsepower ��

  5. #5
    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.

    Click image for larger version. 

Name:	294348917_10228967294915526_2186504974558269639_n.jpg 
Views:	19 
Size:	184.0 KB 
ID:	29004

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

  6. #6
    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.

  7. #7
    Quote Originally Posted by joepasquariello View Post
    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.

  8. #8
    Quote Originally Posted by noisymime View Post
    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.

  9. #9
    Quote Originally Posted by joepasquariello View Post
    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.

  10. #10
    Quote Originally Posted by noisymime View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •