How strong is the connection as the current problem with most remotes is that they’re either butt ugly , or are susceptible to interference.
A plain Firefly with only LED’s and a multi-button would be nice
There is a ESP8266 version, is that better? I think someone made a ESP8266 remote before
esp8266 is the older version. ESP32 is the new version of this controller and this dev board has battery/charger/wireless/oled/few buttons. Perhaps hall sensor and case is all whats needed.
I agree stability needs to be tested. My feeling is that using wifi/tcp is a bad choice but UDP should work. The ESPNow is probably even better. I managed to find some reports from RC world.
More testing is needed, hence looking for like-minded people to do it together.
1 Like
This is funny, but ESP32 even includes a hall sensor!!!
1 Like
Nice sorry I didn’t know that ESP32 was the new version 
The dimensions of the pcb, are they a bit too tall?
edit doesnt matter
I’m in
I have built my remote using ESP32. Tried ESP-Now, Wifi, BLE but they were all a bit slow (BLE connection was a pain, but worked). Ended up using an ESP32 with nRF24L01. More wires but a lot more reliable.
ESP32 has two cores which I HIGHLY recommend getting you head around. Google “ESP32 FreeRTOS” maybe. I might see if I can find you a link somewhere.
RTOS/dual cores means that you can have one core (or thread?) reading buttons etc (timing critical) and the other core talking to the board… completely independantly.
I had real issues with how much stuff the ESP32 was having to do, and I was reading a digital encoder at the same time.
You are using MCU resources incorrectly… 8-bit AVR can do all that stuff without even sweating.
P.S. How are you splitting load between cores?
One core had interrupt handlers on two pins reading a digital encoder. The other core was sending data through the nRF24L01.
I don’t think I was doing anything incorrectly. It was about timing-critical tasks. If the MCU was busy updating a display/sending data then it was missing encoder pulses.
1 Like
I’ll admit that for “trigger” style remotes that dual-core (FreeRTOS) might be overkill. Still think it’s elegant though.
1 Like
Just to bring in the context, 8051 handles W16 engine, with 4 precision rotary encoders, 16 injectors (PWM based) over 20 sensors communicate through CAN and final nail everything was fit inside 64K rom, 2 external interrupts, and just 2 timers 
Check your code for blocks, something is blocking interrupts I don’t remember if ESP32 has jtag or etc debugger to see what your code is doing.
P.S. don’t use those Arduino style SDK those SDK are just for simple simple task
1 Like
I understand just 5% of what you guys say…but sounds very interesting…continue reading 
3 Likes
Sure. You might be right. I’m a c# developer, not a c++ dev. Dual cores works for me… I like the idea of abstracting tasks away from each other… especially in a hardware sense.
p.s. you’re probably right re: Arduino SDK. I fairly short of time so Arduino is just going to have to work for now.
2 Likes
It’s easy to develop something on ready made platform
Also I think my computer in my Mark48 project is overkill compared to your remote
1 Like
Also lets not forget Apolo 11 Main CPU 
Agree it’s strange you had performance issues.
What did you use encoder for? Did you try to use internal hall sensor for trigger? It’s just adc conversion.
I want to play with ESP now. Someone on arduino forum reported less than ms for packet send/receive cycle …
I was going to write a post about the encoder idea but I am using the encoder as the throttle, pulses increment/decrement a counter and the remote talks to the board as a ‘nunchuk’ remote … essentially a position-less throttle I guess.
Might not be the best solution, a few design/safety decisions had to be figured out, but cruising/throttle response is super smooth.
I actually just completed my recently build doing exactly this, except with a pair of ESP8266s. Nunchuck talks I2C to remote box w/Feather Huzzah ESP8266 in it. That in turn talks WiFi to board’s ESP8266 which checks data packets via CRC, then relays the info to the VESC via UART.
1 Like
How is it working for you, Caanon? Responsive, no lags over wifi?
Not sure what you mean by CRC? Do you use tcp socket?
@cannon, if you already using TCP/IP package is not worth double check the integrity of the message as underlying network layer does it for you. It’s more for low level communications like UART, CAN, SPI, I2C, Raw RF and etc.
1 Like