This is awesome!
For the last 2 months I’ve been testing my own custom remote based on stm32 and ELRS (didn’t want to risk writing my own RF link code). I haven’t implemented telemetry yet.
How fast is it handling failsaves?
The main reason I’ve made my own remote, was that all flipsky and uni1 remotes have very slow recovery after losing the connection, and that caused me multiple full throttle runaways when riding in the city.
The main reason I’ve made my own remote, was that all flipsky and uni1 remotes have very slow recovery after losing the connection, and that caused me multiple full throttle runaways when riding in the city.
Same here! I had a lot of scares with flipsky remotes and decided to take matters into my own hands.
How fast is it handling failsaves?
I would tell you if had any 
In all seriousness I set my target refresh rate to 50Hz and in the rare instances that I lost a telemetry package (which updates much slower at 4Hz), I just couldn’t feel the tiniest blip in throttle response. The LoRa module I’m using is an absolute overkill for the distances we use in esk8, but I’m not taking any risks.
Failsafe behavior (that I have tested even if it hasn’t happened in the wild) is the following: RX emits a neutral throttle position and suspends TM sends until signal is regained (which I think it’s the only sane alternative)
I like your case design very much btw, that remote is not going anywhere!
Yea, that’s the way to do it 
The way I tested it - I piled a bunch of 2.4ghz devices on top of my board to cause failsaves. BTW is yours 2.4?
How wide is your PCB? My case has about 25mm width on the inside, I’m going to release the files once I test and somewhat finalize it.
Do you have a spare serial output to connect a screen?
Love the testing method lol. I got into an elevator and moved through the building while my GF recorded the board behavior on her phone, but definitely not as conclusive as yours
How wide is your PCB?
PCB currently sits at 23.9mm.
Do you have a spare serial output to connect a screen?
Nope, the ESP32C3 on the TX is maxed out. At any rate that’s the point of the Unfancy, do one thing and do it great!
I have to say, the RX has some free pins now that’s a separate PCB. Might be open to explore adding a screen to it Davega style, but always on the board side.
Could I suggest a different behavior?
Instead of a hard jump to zero, I think the preferred behavior would be a 200~500ms ramp to zero. Would make the remote failure less likely to cause a crash under hard acceleration, I think.
But this is the perspective from a racer, who spends a lot of their time riding under acceleration or braking😂
Not exactly a typical use case haha
This is what i would hope for, a nice soft backing down to neutral. If some sort of hepatic feedback could also trigger or beeping to indicate signal loss would be nice too as it would help to quickly let the rider know what the situation is and take the appropriate actions like letting throttle go to neutral and aiming for a good roll out / foot break / bail out or whatever is best
My Tynee does this, and it’s great. Highly recommend.
Yay scope creepage 
This is the case!
Ramping down would be easy, but that’s also implemented in the VESC code so I’ve never had the need (I’m not a racer though, so I usually leave the defaults). As far as scope creep goes, this one is easily doable
Totally fair and reasonable, tbh I forgot vesc does that😂
We(racers) normally lower the positive/negative ramping times to like <0.02s so we get more responsive control
I don’t think that’s just a racer thing, I’ve never actually been able to go to a race but I’ve always used super low ramp times.
I would have to do some testing and check how those settings would interact under different conditions…
This the same reason why the Unfancy does not implement throttle curves, I’d rather have that on the one place (VESC). However it’s true that a failsafe is a condition that can only be detected by the remote, at least in PPM mode.
I should also check out the UART protocol since I have exposed those pads on the new RX too. Aaaah, many things to do.
Software for the RX has been cleaned up, and it also has WiFi now.
Real time SNR and RSSI measurements 
This is the way.
Holy shit, did we both went on parental leave at the same time or what. Like a clockwork I also got time to revive my board after initial kick stomach for first years of parenting. Anyhow, I am rebuilding my board and I was about to redesign the case, but it seems like you went step further and reworked entire project. Looking forward to updates, especially dual thumb version with separate brake.
Couple of questions:
Will you support ESC telemetry or is it still going to be simple PPM remote with voltage monitor as it was before?
Is the hardware in mature enough state that it can be tested? I would love to give remote re-design a shot. A step file of main board and thumb sticks would also probably work just fine.
Hey hey! Welcome back, fellow parenthood survivor 
ATM I want to keep the philosophy the same. I have exposed an UART on the RX side though, but the remote itself will just have voltage monitoring.
99% there! There’s like 2 small bugfixes on the TX side that I still have to test (waiting for some zener diodes to arrive) and I wanted to try my hand at adding a connector to de RX, but it should be ready too. The PCB dimensions are not going to change, so here you go! (Step file is also way more detailed now)
Not 100% sold on LED positioning though
My printer is finishing an RC candidate of the dual trigger version as I write this
Also:
Reworked most of the RF code last night because I was very unhappy with how unreadable it was. Went in a completely different direction, but it is MUCH simplified. Also spent a lot of time microbenchmarking stuff to ensure this version is even more reliable. Timings on this thing are TIGHT now. Like finger in my ass submarine screws tight:
Is this pushed to github?
Yes, all of this is on the feature/v3 branch GitHub - Thunkar/UnfancyRemote at feature/v3
Docs and CAD designs (except for the PCBv3.step file) are not updated though. Another important change is that I switched from the Arduino IDE to platformIO. Specifically I’m using VSCode + PioArduino plugin (the latter is a fork of platformIO that supports the latest ESP32 Arduino SDK)
A few things on this version that vastly outperform the old one:
