I agree with everything in this comment. Thanks for adding the second part to the video for the rest of us.

The boring stuff is actually the "nerdy" stuff us geeks like Us mechanic/computer nerds are actually really stoked about this stuff...believe it or not

​@@haydenc2742 exactly

@@haydenc2742 Not only do we like it, but I'm impressed with the clear explanation for those who've never used interrupt-driven code.

He's broken it down so well into steps that it makes it easier to grasp what's going on. The big deal with modern computer controls is they're monitoring lots of channels and making changes based off a lot of information, and all those interactions can make things a lot more confusing. CAN still escapes my diagnostic skills and equipment. Lol just causes me grief, thankfully I'm not a tech at a shop, I'm a company mechanic and we don't have too many newer rigs.

They just want you to think it's so complex, so you bring it to them for repairs. Money, money, money.

@@fredv7487 a lot of the information that the system uses is locked, hidden away from access by non licensed scantools and it really makes it tough sometimes. All I want to know is if a solenoid is being commanded to do something and I can't even do that. It's a multi-facetted issue but overall your statement is correct. They don't want us working on them

Don't be fooled. The arduino here is doing next to nothing in comparison to a modern ECU. Sorry

​@@surewhynot6259but it is comparable to a 80s-90s ECU, like a Motronic or a Digifant.

Thanks!

I had the same suggestion with the teensy for sensor input there is even premade lib made for measuring input frequency. Cool to see you watch this channel too I love your other videos.

Those are the best type!

Glad I could help

O2 signal simulators used to be available to "fix" the check engine light, Sadly they are hard to find these days.

I had the same thought and posted it in a separate comment. Hopefully Jimbo sees these.

The thing you have to consider is that this micro controllers has an 8 bit cpu that is running at 16Mhz (consider the cheapest, slowest x86 PC runs at 1.1Ghz and has a data width of 64 bits). Frequency calculation takes quite a bit of processing time. If he was running an esp32 (32 bits at 240Mhz) there would be more time for tach inputs. With the method Jimbo is using he can get the analog voltage with just 2 cpu clock cycles(its probably more like 6 cycles but that breaks my narrative) reading one of the internal 10bit ADCs. All the the scaling to units of measure is done in the external DAC (the electronic frequency gizmo). No cpu math needed to get a relative speed. It doesn't have to be 100% accurate, it has to fast and close enough. If the processor was a bit faster then your timer method would work well.

​@@georgehooper429 "Frequency calculation" takes essentially no CPU time at all if you use the device properly. A timer/counter is a peripheral that utilizes zero CPU cycles unless and until the interrupt condition is met. Whether a counter incrementing on an external signal or a timer incrementing/decrementing on the system clock, the CPU itself is not involved until the interrupt triggering circuits are satisfied and the interrupt is triggered. The ADC actually operates in a similar way; You tell it to take a sample by setting the appropriate bit in the control register, and the CPU does other things until the ADC triggers an interrupt that the sampling/conversion is complete. The CPU then has to stop what it's doing and move the result out of the ADC's data register before doing anything else or risk the data getting overwritten. Alternatively you can put the ADC into free-running mode where it's constantly sampling and will trigger an interrupt every time a new conversion event is finished, or configure the ADC to sample and convert based on a timer or other trigger event with no CPU intervention. Again, if you're smart and pick a good time base for your sampling frequency, the counter/timer method is equivalent in terms of CPU utilization; The "math" is simply a bit shift left which is 1 CPU cycle. If you're smarter still, you can probably skip that "math" and just use the unscaled value as-is since it's just a constant, and if all you care about is relative magnitude then 0-32 in steps of 1 is exactly as good as 0-256 in steps of 8 if you don't need the full precision (as an example). Using an external DAC also works, clearly, but as mentioned in the video introduces another layer of imprecision as it converts pulses to analog that then needs to be converted back to digital. Squeezing the data through a 0-5v window, plus likely environmental noise, loses precision. Good enough is good enough, though...

A lot of folks seem to forget that the arduino is also driving two stepper motors. The core of the program is focused of moving those steppers as fast as possible. Doing direct frequency measurements on the RPM and vehicle speed would absorb too much time using standard code. And yes, I'm aware it can be done with advanced code.

Just like the rest of Jimbo's overkill, even using interrupts is too complex, inefficient and requires too much programming. The Arduino's ATmega328 has counter/timers that will do the whole job in just a few lines of code - and hugely accurately and quickly. His use of extra hardware, particularly those frequency-to-voltage converters, really messes with my OCD. Converting a digital frequency to a voltage and then converting it back to a digital value is just crazy. Also, Atmel AVRs inputs will trigger at about 1.0 - 1.3V, so the transistor/half-bridge was also unnecessary. The inputs also have schmitt triggers, so that will deal with noise. At the end of the day, Jimbo could have solved the coal-burning problem by opening up the governor and removing a spring to disable it - instead of all the servos, sensors and electronics. But his videos are nevertheless entertaining!

Pretty cool

Thanks for that!

Glad it was helpful!