LETS FREAKING GO! I like the price number you set 😆 I'll be saving up to get one. Good job and congrats Josh. Its been one heck of a road and I'm glad to be here for it 🤘
Great work Josh, it would be cool to split the firmware to develoo more feature on the teensy now. I feel like the progect is slowed down by the mega memory and speed
@@felixhoussay There was an adapter board for the Teensy 3.5, but I haven't adapted it to the 4.1 as there was never much interest in them. It has a few challenges doing it that way but you can get most of the benefits of the Teensy 4.1 (Including SD logging etc).
@@joshstewart2131 well if the forward becomes limited, and there’s a technical possibility, that might be interesting though. I guess the most challenging part is the 5v-> 3.3v ? And also physically fit everything (SD, expansion I/O, your nice new WiFi/BLE etc) on a mega footprint
For sure, got my attention!. Since the disruption, NXP stopped the line on the MK64FX512. T4.0/4.1 with it's MIMXRT1062 is still alive and thank the maker! Greatly interested in a stable schematic for the V2. I'd like to build up a custom ECU without some of the "modules". Big Thanks!
Hey. Maybe this is a dumb question, but what are the advantages of a Tennsy based speeduino? I currently have an Arduino Mega based Speeduino that I built myself from a parts kit and it's working great, but I'm just curious what the advantages of the Teensy based boards are. I know the Teensy processor is _a lot_ faster than the Arduino Mega, but what does that actually do for you in an ECU like this?
Mostly the supply chain thing. The microcontroller chip has to be obtainable, right? More speed means better timing accuracy through faster reaction, and/or more channels, and was mostly a side effect of slower ones being unobtainium or more expensive, and while you're redesigning, why not go fastest currently available within the budget even if it has nothing to process sometimes.
having made an ECU from scratch on a pic12f683, all 8 pins of it, in 8bit... on 4MHz, having to deal with timers, and the data in registers due to the clock rate... nothing. its flexing pointlessly. theres no point resolving a crank signal to 16 bit and having to deal with the extra processes. no point having injection times in 16 bit, and finding prescalers and postscalers are inadequate, finding register overflows, the dozens of extra steps required to deal with 16 bit mathematics at the machine level... at 12,000RPM, you have 5mS per revolution. at 4MHz clock, or an instruction every uSec, theres 20,000 clock cycles between revolution. 40,000 clocks between "four stroke cycles". on teh opposite extreme, one has to figure out a way to get uber fast processors to "twiddle their thumbs" as at idle, average 1200RPM, you have 400,000 clock cycles. if a register overflows in that period, you have to have a second register. so when you perform calculations that second register has to be invoked. you then get results that span 3 four registers... and all that data has to be dealt with... just one extra bit in a second register can require a hundred more lines of instructions to wade through. then theres interrupts, work flow, routines.. hard to explain without a thesis on programming in assembly language, the closest to raw hex/binary that the device, ANY device, is actually operating on.... forget the pypy, the C++, try programing an ECU in assembly. that chip doesnt know what its doing. its just running through code as dictated by data on various inputs, spitting out appropriate outputs. in my case, i started at 8MHz, the fastest my choice of device could do without external oscillators. was a nightmare, every scaler worked at its limit and still getting constant overflows. 1MHz was adequate but then the injection resolution suffered. 4MHz was that nice middle position where i didnt overflow too much, the one register that does overflow conveniently works as a "low rpm" or "min cranking speed" limit as it simply throws an interrupt if it exceeds a certain count, or about 200RPM...
@@paradiselost9946 You would be INCREDIBLY limited on a MCU like the pic12f683. You only have a single 16-bit timer and trying to run even only 4 channels (2 ign + 2 fuel) of interrupts with an accuracy of say 4uS is going to be a pretty big strain at 4Mhz. The overflows really aren't the concern, you can handle them within your scheduler , the problem is the lack of speed to actually do the steps your need in that time. You can get away with on a mega2560 at 16Mhz because you're got a heap of timer channels to use (Eg 12x 16 bit timer channels), but at 4Mhz with only a single channels you're severely limited on what you can achieve. That's not even starting to look at things like SD logging, auxiliary PWMs, more channels etc.
@@joshstewart2131 3 timers, one 16 bit, and that 9th bit signifies idle, 10th bit for "min RPM". no need for dealing with 16 bit data or calculations other than as a flag. that directly relates to overflows and clock rates. one cylinder, with off board dedicated CDI, fully programmable... one injector channel, one crank signal, one MAP sensor... all that is actually needed. pushed the limits of what a 12f683 can do, but as things progressed, almost like it was intended specifically for what i was doing. SD logging? some people love flashing screens and scrolling through endless reams of data... i prefer having a running engine. as theres only one or two single cylinder units on the market, and i have one of them and not one part of that kit still works... i felt it more fun to build something from teh ground up that i understand, and i can fix if and when it needs it. plus the idea had been lurking in my head for way too long waiting for me to get my butt into action. and try as i would, i cant figure out how to implement my own crank signal into speeduino firmware. no toothed wheels, or messing with cam sensors, either... theres ways to do it differently. admittedly, if tuning and calibration and ASM on MPLAB wasnt so daunting for the average user, id be selling them... one day it might get a better chip with that flashy LCD screen and some buttons...
This is awesome news, with the extra processing headroom would it be possible to support a v12 on a single ECU? Perhaps some form of master slave arrangement on the hardware side to get enough I/O? Slowly working towards my custom V12 so it’ll be a while before I’m ready for an ECU giving time to investigate options. Would love to use speeduino as I’m a bit of an arduino-aholic… 😂
Part of the challenge with that is that dropping this to only 4 or 2 channels doesn’t actually remove all that many components. There’s a few for sure, but it doesn’t drop the cost or the size all that much to do so unfortunately
You can still use it just don't activate the unused driver channels. Same deal as how 74LS logic might have 4 gates per chip but there is no 1 gate chip so you just use it anyway and don't wire the other 3. And if there were a 1 gate chip it would cost more anyway.
Maybe this is a stupid question, but what are the benefits of having an extremely fast processer ECU, compared a normal ECU like a Megasquirt or something. Is it noticeable? Any performance effect?
this is a great achievement my friend, I hope we will see you with better projects in the future Will you share the pcb data of this project with us in the future? so that we can do it ourselves
I started to design my own board based n the T4.1 sine I wanted independent control of each injector and spark. I see that the new V2 ecu has 8injectors and 8 spark outputs are they sequential independently controlled? or are they driven from 4 outputs from the ecu each?
Due to Executive Order in the US any open source project must ban all Russians (Linux kernel just deleted all Russians out of the Maintainers list... even if it leaves important things orphaned), so although Speeduino is not a US-based project if it collabs with Russians they would lose all their US collaborators (assuming there are some) and probably also would be banned from sale to US buyers.
is the teensy 4.1 compatible with the old dropbear v1 board? say the teensy 3.5 in my v1 dropbear dies, for whatever reason, would i be able to swap in a teensy 4.1?
Unfortunately not, that was one of the reasons a whole new board design was needed. Most of the pins are compatible, but not all of them. I’ve run a car with a 4.1 in a Dropbear v1, but you lose some of the analog inputs and the CAN connection
I have a bit of an unusual project, but I'm interested in using a Speeduino as a starting point (I might need 2?). Ford V8, wasted spark is not an option, 3-valve pneumatic control using programmable solenoids, must also drive engine speed (via gear selection). That's probably more than one unit can handle, requiring more IO connections. Of course it will need to handle multiple modes (affecting engine and transmission operation). Is this a reasonably easy direction to go (I'm more interested in programming than electronics design work).
All of that’s fine with the exception of the transmission control. These units can do 8 channel sequential fuel and ignition, so that’s not an issue, but there’s currently no transmission control directly with Speeduino
Sir I have been trying to buy a drop bear since before the test units went out and still haven't found somewhere to give my money 😂 please give us a link where I can buy a few 😂 i have 5 personal cars that need them and 3 customers that would like them
@@Speeduino thank you I stopped trying after about a yr of trying the email this page is new to me. Buying one now 😃 iv had good luck with it on a friends car and my daily is a 2000s build with a autronic smc which is great but outdated and under optioned. Plus I'm tired of having all these boxes behind the dash for boost control and more.
I really want a way to directly support you, but nothing has really ever fit the bill for me. I'm hoping one day you make a daughter board with all ign/inj drivers etc onboard and i can just design a pnp pcb which fits my stock ecu case with oem connector, and use your daughter board as the main brain. It would make creating new pnp ecus so easy and directly support yourself for all your efforts.
Stealthing as in hiding within the original ECU casing may be viewed as illegal in some places and could complicate things, even if just providing things in a format that might make it easier for an end-user to break laws with. When governments can't effectively inspect and enforce each end-user (which they can't, especially if it's hiding in an original casing and spoofing OBD responses) then they will stomp on anyone they can construe as mainstream facilitators.
@@Spudz76 that is wildly specific to probably one country or state in the whole world that does that or cares about it. In that case you probably can't put new dust caps on your wheels either as it'll be illegal too. For the rest of the world, it's just a purely convenience factor, it fits nicely in OEM case and uses OEM harness and connector without any changes. No one cares about obd where these are being used.
I don't want to disregard your work as Speeduinos have been brilliant for me. However, when i built my first speeduino my only thought was that the hardware was pretty easy to come up with (0.4.3). A few mosfets, a few mosfet drivers, and some chips handling the data. And of course all the basic stuff like pulldowns and bypass caps. How long does it take you to design and test these boards?
Details are pretty scarce from what I could see, so happy to be corrected on that if you have any hard info on the MCUs that they're using. A few I've seen have similar speed co-processors for comms or logging, but use a more standard speed MCU for the engine control functions themselves.
@@Speeduino Bosch uses OEM MCUs in the latest MS7 for instance, so in the 3Ghz+ range. These ones I mentioned also use FPGAs for timing control vs running timing control in the MCU. 600mhz allows Speeduino to grow alot so I think fw expansion should not be a problem any time soon
@@garyhowe88a lot of dropbears V2's, those Racing ECUs are not for low budget racing cars (the guys who uses MOTECs, Haltech, Emtron etc), BOSCH, Cosworth electrinics, Life Racing, etcc are for very top end racing teams. Speeduino are democratizing the stand alone market, taking a fresh step ahead as megasquirt had done until today but with a real OpenSource approach (speeduino).
