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 🤘
This is literally all I need for a turbo and not the extra bloat I won’t use with mega squirt and still cheaper than their unassembled kit. Being said perfect for running any engine swap, might need new ecu harness plug to wire if a can’t make the sensors match but this is still cheaper literally like someone else said he is a god amongst men, making this level of product at a price thats making me think I should by multiple just proves it!
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!
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.
Hey there I am just here to say I appreciate your hard work, I got the speeduino v4.3 running my 99 Tacoma (3rzfe) and am excited to find a project that I can m use this dropbear in.
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
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… 😂
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
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.
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?
It's mainly for ease of programming, you don't have to care as much about resources. Additionaly it may be little more precise (it won't be that noticable though), and as you've propably seen there is a web page UI, hosting a server uses (relativly) lots of processing power
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
@ you did not mention pneumatic valve control (the most unique part of my approach. I'm thinking the outputs for fuel COULD be used from a second unit to control the valves.
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.
@@Spudz76The creator of rusEFI is of Russian origin, but has moved to the US if im not wrong. Would someone still be banned from working with him when he lives in the US?
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?
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 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?
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...
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).
so calm for being a god amongst men
Thanks for adding a built in VR conditioner, makes setup that little bit easier
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 🤘
Order placed immediately, with equal enthusiasm and so much patience while waiting years for this moment!
Wow! Thanks Josh, this is Awesome 👌
This is an amazing jump forward with the system ! congrats on the new release, cant wait to see it being used in builds soon
Great stuff, excellent progression... got another project in mind for this.
I love that these options are available.
This is literally all I need for a turbo and not the extra bloat I won’t use with mega squirt and still cheaper than their unassembled kit. Being said perfect for running any engine swap, might need new ecu harness plug to wire if a can’t make the sensors match but this is still cheaper literally like someone else said he is a god amongst men, making this level of product at a price thats making me think I should by multiple just proves it!
It just keeps getting better!
this is very cool, when I get started on my project car I'm definitely going to pick one of these up for it.
Can't thank you enough for all the hard work 🎉🎉🎉 you really open up a great deal of possibilities for the community! Cheers from Costa Rica!
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!
This all sounds awesome fantastic work!
Being in the embedded Linux realm a lot, "Dropbear" is confusing because that's a lightweight SSH daemon.
awesome work!
Nice. Good luck with the new version.
Awesome. Would love to see a mini version for small engine. Maybe just 2 injector and ignition.
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.
Hell Yes. Hoping for this to happen.
Hey there I am just here to say I appreciate your hard work, I got the speeduino v4.3 running my 99 Tacoma (3rzfe) and am excited to find a project that I can m use this dropbear in.
Very cool, keep up the good work❤
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
Or offer an adapter board to switch the existing mega daughterboards to Teensy ?
Any opinion on this point Josh ?
@@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
Awesome! Great work!
I'm ordering one of these as soon as someone makes a 2 plug miata harness adapter.
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… 😂
Very likely that 12 cylinder support will be coming in the future for these 👍
@@Speeduino That’s great news looking forward to it!!!
Legend.
alright! bring it back!
Great news! Will the updated schematics be released on Github or other by any chance?
Thak's dude 🎉
Is the wiring pin out the same as the v1? I have a v1 and would like to upgrade to the WiFi function
Yep sure is, you can swap out a V1 for one of these with no wiring changes
Somebody didn't watch the whole video...
Please look into making throttle by wire board
There's some work in progress at the moment to add support for some 3rd party DBW controllers. Hopefully included for the next major release. 👍
@@Speeduino that's very exciting.
@@Speeduino That is extremely cool ! That is the only feature, that SD\DP lacks for me, i'll follow the development more closely.
Just bought a db v1 from my aviation teacher, should be a good match for a 4efte... us aussie build sick stuff🤙
I just bought a V2 for me 4efe+t build! Feel free to reach out if you want to collab on getting the 4e set up
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
❤
With the increased speed would controlling a V12 be available?
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
It's in the video description. I just bought one, Have 2 of V1 as well.
The link to the store for these is in the video description, but just let me know if you have any issues ordering 👍
@@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.
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?
It's mainly for ease of programming, you don't have to care as much about resources. Additionaly it may be little more precise (it won't be that noticable though), and as you've propably seen there is a web page UI, hosting a server uses (relativly) lots of processing power
What happened to the teensy ARM adapter from mega2560??
are you going to be restocking the website anytime sonn? most things say out of stock
Yhats great i want to get one one of these days
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
@ you did not mention pneumatic valve control (the most unique part of my approach. I'm thinking the outputs for fuel COULD be used from a second unit to control the valves.
where can I find information on the esp32 dash firmware. just got some esp32, would like to play with them while waiting for my dropbear v2.
There's not too much in the way of documentation yet, but checkout github.com/speeduino/AirBear
About 4:00 is where ya see who he’s telling you will have ability to pick up the data it’s broadcasting.
I was wondering. Will you sell pre wired conversion cables for cars or schematic? This will make it sell more?
Is there a usable input for knock sensors and knock control strategies?
Open source ECU is a fantastic idea. So maybe the rusEFI and Speeduino project should collaborat?
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.
@@Spudz76The creator of rusEFI is of Russian origin, but has moved to the US if im not wrong. Would someone still be banned from working with him when he lives in the US?
Hmmmm. Interesting. Im looking for a solution to control ignition and do data logging on a procharged blow through bbc. I'll keep this in mind.
you are a fucking legend!!!!!!!
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?
It’s a full 8+8 channels of sequential for fuel and ignition 👍
@@Speeduino Nice, just ordered one. Thanks
so can i upgrade my dropbare v1 to new micro processor
Is this ecu compatible with 6 cylinder applications for eg. Rb30?
Absolutely, it supports full sequential fuel and ignition for up to 8 cylinder engines.
By any chance is there any shop in Europe that might end up selling the ecu ?
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
Drive by wire throttle body control coming?
I've been waiting to get my hands on a drop bear, thank you sir
Are they available to ship to UK?
Sure are!
What’s the point , contacted all the suppliers and not a single response from any business in any country yet .
Plenty of space for Hybrid control now then ...😜
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.
Speed sensors and accelerometer inputs for timing retard / fuel maps? This can help with traction issues.
DBW Throttle control yet?
Testing with interfacing to some external DBW controllers at the moment.
will the dropbear v2 hardware be open source?
It sure will! Once I can get a few units out the door to help cover the R&D, I'll release the design files as with the v1
@@Speeduino awesome, that's incredibly kind of you!
thanks so much in the name of the community!
Speeduino Dropbear V2
$420.00
Good timing, i was just thinking about speeduino this week
On board datalog supported?
Yes, there’s logging to SD card on these units. You just need to add a card and you’re good to go
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?
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...
600mhz is definitely not the fastest processor in a aftermarket ecu, Bosch Motorosport, Cosworth Electronics, Mclaren Electronics etc etc.
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
@GunniGST ms7 is dual core 1ghz.. also wonder how many drop bears you could buy for the cost of one..
@@garyhowe88 my bad must have been thinking about something else.
The bosch and speeduino don't operate in overlapping circles
@@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).
You lost me when you said it has wifi and Bluetooth, that gives remote access maybe by a militous actor and a MAC address to be tracked by others.
You are a FKN RTRD
It can be disabled or completely disconnected the power pins for those modules.
You can simply unplug it from the motherboard really easy
Yeah because there will be so many of those within 30 feet, that even know what a Speeduino is.
No worries, as soon as they see "DropBear" they gonna yell "Ahhhh, Dropbear! run for it!" Hahaha!
👍👍👍