[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.