[huramentzefix]

If the power supply for gas pedal disappears but it is a simple pot based thing and ground is still there the output voltage will be at ground level and fail safes will disconnect H-bridge effectively cutting power to the throttle motor. If the pedal is something else than pots then I don't know what will happen with the output voltage but if it's high impedance so effectively floating the R25 resistor will still pull down this input and the outcome will be same as above.

Although I do agree that having it powered on all the time is not the best idea in the world I'm guessing there is input pin with 12V after ignition in your ECU, isn't there? If not I guess P-MOSFET should also work fine...

Thanks DStage for your impressive work, you saved my day!!!

I will start testing your board V2.2 soon.

Persionally I think that closing the throttle in the event of a power loss is a hazard, and not a safety. Sometimes the streets are crowded and when I want to pull into a street from an intersection, the gaps can be small sometimes and I then have to floor it.
If then my throttle closes I might have a hard time getting the side window up and down?
Is there an option to leave the throttle where it is in the event of a wire-break or rather have it go full-throttle?
I'd rather cut injection via brake-switch. Just my personal thoughts...

[JHolland]

Persionally I think that closing the throttle in the event of a power loss is a hazard, and not a safety. Sometimes the streets are crowded and when I want to pull into a street from an intersection, the gaps can be small sometimes and I then have to floor it.
If then my throttle closes I might have a hard time getting the side window up and down?
Is there an option to leave the throttle where it is in the event of a wire-break or rather have it go full-throttle?
I'd rather cut injection via brake-switch. Just my personal thoughts...

The throttle should default to being slightly open, this is set by the springs in the throttle body. Allowing the throttle to revert to this point is the accepted method within the automotive industry, the vehicle still has enough propulsion to move away from a danger area but not so much that it can't be overcome by the brakes. You don't want to be arriving in a corner with the throttle stuck wide open with an automatic trans.

[DStage]

Persionally I think that closing the throttle in the event of a power loss is a hazard, and not a safety. Sometimes the streets are crowded and when I want to pull into a street from an intersection, the gaps can be small sometimes and I then have to floor it.
If then my throttle closes I might have a hard time getting the side window up and down?
Is there an option to leave the throttle where it is in the event of a wire-break or rather have it go full-throttle?
I'd rather cut injection via brake-switch. Just my personal thoughts...

The throttle should default to being slightly open, this is set by the springs in the throttle body. Allowing the throttle to revert to this point is the accepted method within the automotive industry, the vehicle still has enough propulsion to move away from a danger area but not so much that it can't be overcome by the brakes. You don't want to be arriving in a corner with the throttle stuck wide open with an automatic trans.

JHolland explained exactly what I was going to write. Throttle is not completely closed. When you read "closed" it means no power so it stays slightly open due to its mechanical construction. And I feel the same that I'd rather have idle than full throttle especially when you don't have clutch pedal.

BTW, you have a gas powered windows on your car? Cool! Unless this is some kind of expression I never heard on a gap between cars or it being a consequence of a crash you'd have for some reason due to such event
In case it's not an expression then I'll just say you can operate your windows just fine without the engine running, but it will be running at idle, so I do not anticipate problems

[DStage]

Awesome project Dstage, thank you!
I wanted to build it but I can't download the gerbers rar files on github.
Also I tried sending you an email with no luck.
Can you help us out please?

You had a problem with sending me an email on my gmail address? Strange... Also what kind of problem you had with downloading from github?
BTW, was it you that wrote me email on 09.04.2024? If so then I guess you no longer have the problem with email. gerbers and parts

[DStage]

First off, awesome work!

Thanks

I'm also an embedded software engineer professionally so I can actually contribute meaningfully to this project now that there's a digital controller involved!

No problem, consider yourself invited hehe.

I don't like that Z1 is placed in a position that cuts ACC_DIG off of the accelerator pedal position sensor (APPS)/TPS comparator circuitry

I think you've misunderstood parts of the circuit. The fail safe for gas pedal position is still there as it always was. Those comparators were never intended for checking MCU signal. I did have a though about additional comparator for that but it would have to be separate thing.

and relies wholly on the FAULT line. It's worse given that the FAULT line is driven by the Nano and not some sort of monitor circuit.

FAULT line doesn't drive anything. It is just an input for the MCU, it's not driven by the MCU. Not sure how you've concluded that when there's T8 in the way. So the fail safe for gas pedal position is untouched.

Let's talk about the comparator stuff. Is the intention that even during Nano operation that the TPS should still be compared to the APPS?

Either as I said you misunderstod something or I do not get which part you call "comparator". For me comparators U5D, U2D and U2C do the fail safe here. And the input circuitry of the PWM controller U1 isn't really a comparator but rather an amplifier, an error amplifier to be exact. Sort of similar but not the same.
Anyways, gas pedal position no longer goes to U1 in "map mode" so it's neither "compared" nor "amplified" there And the fail safe part doesn't compare those two signals to each other either. U5D takes care of the gas pedal position being to high or "overpressed" in other words shorted to 5V for example or open circuit. The U2C and U2D create a window comparator for TPS to check both shorts to GND and power as well as open circuit. Gas pedal short to ground is not checked as the result would be same anyway - closed throttle.
BTW, all this hasn't changed from v1.x, I think I've explained it in the User Manual and in the video.

Seems like more aggressive mapping could fault the circuit out in weird ways.

Such as? I'm still under impression you misunderstood which signal does what (or rather swapped them a bit).

I think this would override any digital comparison done with the TH_ADC line. Digital comparison is still a good thing to have, it just shouldn't be used as a failsafe.

And it's not, at least not primarily. In both "analogue mode" and "map mode" this line only serves a monitoring purpose but could be used for a kind of fail safe in "map mode" if one desires. There is no coparison in the MCU to anything at the moment. The output PWM is still purely analogue feature provided by U1 (ok, not purely as there are few flip-flops in the guts of U1 hehe).

I'd prefer to see some sort of switch circuit rather than Z1/Z2. Maybe a 2x1 mux?

That would be much, much worse in terms of safety and also how often anyone would want to change the mode?

If the Nano outright dies then it would just switch over to APPS input?

Sure, just how do you reliably know it died

As for the Nano FAULT line, I don't like that the single core processor is in charge of setting its own safety-critical fault line.

Well, as I said above, it's not. This is just an input.

I wonder if some sort of RCS circuit along side pulses on the FAULT line could be a decent analog way to make sure we're getting signals as often as expected?

Sorry, I did not get that at all. Did you mean "RCs" instead of "RCS"? But still don't get what kind of pulses, there are no pulses on FAULT line in normal operation (maybe it's like I presumed above you assumed this is somehow part of the PWM control).
Oh wait... I think I'm starting to get it. Pulses from the MCU averaged by RC circuit to have a voltage signal telling us if the MCU is still alive... OK, that might be a good idea actually. Sort of half digital half analogue watchdog Although to be implemented NOT on the FAULT line as this is just an input as I said Could be done relatively easily in conjunction with the existing fail safes with an additional op-amp (comparator). I'll think about it. I did have some ideas for fail safes around MCU but I scratched them all as they were complex and troublesome.

Another option could be either a second Nano as a redundancy/watchdog. At the very least, using something dual core like the ESP32 in addition to some sort of external circuit would be much better than what you've currently got.

Nano was chosen as it's one of the easiest to get modules. Rather than having two I'd prefer a small dual corm ARM but it would have to be available in JLC or as a module to fit the overall project theme. Let's remember I've only added MCU in the first place as people were asking for some additional features which I personally don't see as crucial. But it's not only for me, so...

Anyways, once these hardware concerns are cleared up or fixed I'd love to contribute to the throttle control software.

As you see in my replies I do not see to much of a problem unless I misunderstood something, but that's besides the point. The point is this is NOT a digital throttle controller despite having MCU (optional) on board The major function of getting the feedback signal from TPS and controlling the PWM signal for the throttle motor is still analogue here. There is just a digitized gas pedal signal as a sole function of the MCU. or sort of a "DSP" modification of the gas pedal signal in digital domain before it's feed back to the analogue domain. But there is no digital controller understood as part of a control theory.
Right from the beginning I was focused on making it analogue to avoid many of the microcontroller issues, some of which you've also mentioned. This doesn't mean I'm still a "purist" I did add this Nano even if not as a heart of the system after all. And actually I do see that some people are more focused on special, "modern" functions and not that concerns with potential safety issues (to be clear I'm not saying those should not be dealt with in digital system).
And I do see that would be better suited for digital controller. And by chance I have found an old (10 years+) Arduino based controller project in the abyss of the internet and even thought about reviving it / building upon it. I just had a short look at the code and it's certainly not a so so PID project put together in 5 minutes If you're interested perhaps we could take this train together as a separate alternative solution.

And I hope you don't take this feedback as an insult or rude criticism, like I said I'm hugely impressed and would 100% use this without the Nano in its current form. Just trying to offer a schematic review. Let me know if anything I mentioned doesn't make sense or I worded it poorly.

I do tend to be emotional about feedback and criticism but I do get your's intended as being helpful so I will handle it Please excuse the chaotic style of my replies - actually replied along the reading without knowing the full content Feel free to comment if I misunderstood something or were wrong about your understanding.

[DStage]

I did some thinking and compiled different ideas in my head. I came up with this renewed concept for ETC v3.0 so you can check early schematic version below.

This one is a hybrid of an analogue and digital solution. There's still TL494 here used for the throttle motor control loop by default but the same circuit would allow to omit it and build the control part entirely in the MCU if desired. For sure it is easier to use it for now as there's no worry about how fast the data has to be processed etc.

However, the analogue input circuitry is vastly simplified and actually only the filters are left. The principle of operation assumes all the calibration as well as short/broken connection fail safes are done in SW. Additionally second channel for both TPS and gas pedal can be used for extra safety features.

There is still a HW part to the fail safe mechanism but it's moved towards making sure the MCU did not fail instead. The part of schematic in the middle right below Arduino is the "analog watchdog" circuit. The idea is in the main loop of the program pin D4 (WD) is toggled each time the loop is executed. In normal operation this should mean the duty cycle on that pin should stay close to 50%.

This "PWM" signal is then averaged (filtered) by U5B and in a form of a voltage signal goes toward window comparator. If the program starts doing something weird like staying in an interrupt or MCU stops completely this signal will change it's value from ~2.5V in either direction and eventually will hit either one of low or high thresholds. When that happens the RS flip-flop composed of NAND gates U9C and U9D will latch the fault and disable H-bridge. The only 2 ways to recover from this situation is either "hitting the reset" by pulling "RST_IN" high or powering everything down.

In case the MCU is fine but it detects fault on input signals such as short to ground or VCC or some discrepancy between signal pairs (A and B) it can use the same mechanism to disable the output by blocking the WD toggle. User can read more details about the fault reason via UART (USB) before reseting.

The gas pedal is no longer provided directly to TL494 but rather always goes through the MCU just like the mapping option on v2.2. The filtered PWM signal goes as the second input to TL494 from Arduino and it is used for both mapping as well as calibrated signal. At the beginning user pushes the gas pedal and the throttle one by one so MCU can store th limit values. It can then use those values to recalculate the accelerator signal in a way it matches levels for the TPS and thus provides all needed calibration. Maybe not that robust as HW solution with potentiometers but surely more convenient for the user

MCU can also access the H-bridge via SPI to check it's status etc. In case of fully digital control H-bridge can be set using either SPI or DIR/PWM pins. The use of TLE9201 has its downsides one of which is significantly lower frequency set on TL494 but it also simplifies things and provides a smaller footprint.

Feel free to give your thoughts on this idea.