I still think it is - I only noticed the behavior on a heavy car with a huge motor. My suspicion is there's just enough voltage sag on heavy pulls to cause the rx to get stuck in a loop where the rx reboots and sends garbage to the esc that gets interpreted as full throttle, causing voltage sag, causing another reboot, etc.

Or imagine a chassis slap that jostles/damages the circuit board in just the right way to reboot, or your servo fails and starts shorting the BEC. Point is, it's pretty darn easy to imagine a scenario that causes the rx to reboot when you wouldn't want it to and how that can trigger an external reaction in the car that causes the rx to reboot again.

Are the hardware engineers not part of the open source project? Perhaps you're getting hung up on my use of the word dev. I use that as a generic catch all for anyone working on the project which would include hardware engineers. Regardless of semantics, the people contributing to the project and the management process (or lack thereof) allowed a receiver to built on hardware that, IMO, is fundamentally incompatible with the intended function of being a PWM receiver. Just because it's an open source project it doesn't mean they can't be held accountable for the decisions they make.

Receiver brownout is the root cause in that case. If the receiver reboots mid run you've already lost control of the vehicle.

A hard slap causing physical damage to the board? Or an electrical short? Again, that's a root cause. Receiver damage or power loss is already a loss of control of the vehicle.

Does the car go full throttle out of control when you turn it on? If not then the initialisation garbage is not the root cause. The only failure mode I've heard it cause is that it switches some servos into programming mode.

It does work. Sort of. At least on my Kraton 6s EXB (SPMSR6200A). Using the external 4-in-1 module with DSMR. But the telemetry will keep cutting in and out. https://github.com/pascallanger/DIY-...ule/issues/992


https://cimg4.ibsrv.net/gimg/www.rct...f79d98f8e3.jpg
https://cimg6.ibsrv.net/gimg/www.rct...c88fc6068f.jpg

I wouldn't consider those the root cause - namely because those are common enough occurrences that a well made receiver should be expected to handle those sorts of events without causing a car to run off out of control. I'd consider the root cause to be a design that is not rugged enough to handle the rigors of surface vehicle use.

How exactly is a receiver supposed to handle a loss of power or a short?

Going through the initialisation procedure during a device reboot is a symptom. A receiver should not be rebooting at all during a run.

You still haven't answered if the ESC does a full throttle runaway when turning it on. If you can't reproduce it on the bench then that initialisation output isn't causing it.

don't blast garbage to the pwm pins on bootup. the car should just stop, sit, and do nothing when the rx fails. any other failure state is, imo, unacceptable.

And yes, before i sold this garbage radio my car would occasionally freak out on power up.

They know exactly what causes it, they wrote a neat little piece of code to make it go away. It's on the github for your reading enjoyment. It has nothing to do with brownouts or whacking it hard ( calm down there buddy ).

Got a link for that? According to the devs, that garbage blast is a hardware level function that can not be disabled.

https://github.com/ExpressLRS/Expres...scussions/2913

And as I said previously - getting something so fundamental to the operation of an RX completely wrong is, IMO, inexcusable. Even supposing they can fix this issue, how can they be trusted not to make another such fundamental mistake in design in the future?

You do understand that the startup " jitter" and the runaway issue are two different things right?

More hyperbole, damn dude if you lived by your convictions you would have to live in a grass and earth stacked hut.

My speculation is the startup jitter, in the right circumstances, is causing the runaways. If you'd been trying to actually read and comprehend what I wrote, you'd understand that by now.

I was using the firmware that had the "fix" for the signal dropouts and runaways. My car was still running away.

"How can I trust them not to make another firmware or design change that causes runaways" is a perfectly valid question to ask of a product that shipped with a design and firmware that caused runaways. Clearly "trust me bro" is enough for you. It's not for me. If only I could be that naive, life would be much less stressful.

I cancelled my order for this radio, I'll keep what I have I guess. Heard to many stories about runaways.

Speculation is not evidence but you've been claiming it's the root cause with certainty. You keep ignoring the fact that a startup sequence should only ever happen at startup. It is not normal for a receiver to reboot during a run.

You can try a different ELRS receiver based on ESP32, not all of them spit out the initialisation garbage.

So you want me to " trust you bro ", just checking to see if that is what you are saying.

I understand the devs have found the issue, can repeat it in testing and can show their work.....and the jitter and runaway are two completely different things.

If I keep this up I'll eventually have enough posts to place the link up with the git hub for the run-away reason/fix.

If I'm not understanding you correctly, please somebody else let me know, all that hyperbole does not present well while looking for factual information in this topic.

You keep saying the devs found the issue. Where's the link to the GitHub with the issue and the fix.

ROFLMAO