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
If I read this thread correctly you’re handling encoder signals as interrupts which is bogging down the Microcontroller and makes it possible to miss pulses when interrupts are deactivated.
It would be better to employ hardware (timer/counter registers) to keep count so you never miss a pulse. Every Microcontroller has these (it also used them to keep track of time with a pulsing crystal)
On a teensy (nxp Microcontroller) I used for a university project they were called flextimers and could even decode quadrature signals flawlessly and since it’s hardware it’s costing you zero computing time to handle encoder input.
If you look up the manual of manufacturer (usually 2000-3000 pages) of the Microcontroller you will usually find descriptions and application notes on how to do this.
If you still need interupts to handle certain encoder positions you can usually lower the maximum count of the register to a certain integer so the counter with reset on reaching this number. This will trigger an overflow interupts which can then be handled in your code.
I’m on my phone right now but will look into the esp32 manual and point you to the right page
1 Like
@Kug3lis Doesn’t mean I trust the TCP/IP stack code running underneath 
Espressif’s code has gotten better in the last few years, but I’ve hit a number of facepalm-worthy bugs in their SDKs in the past that I’d rather err on the side of caution.
1 Like
But CRC gives you same face palm protection as espressif could give 
EDIT: also you code shouldn’t depend on one packet 
You should send at least 10 updates and take some kind of average or etc otherwise you can have spikes on duty which can kill your esc mosfet drivers
@dimach Pretty well, actually. You need to call setNoDelay to disable the Nagle algorithm, otherwise it waits for a larger packet size before broadcasting.
1 Like
@Kug3lis Erm… not if you ensure the CRC function is adequately unit tested? And I think you’re confusing “packet” with “sample”; you can transmit multiple samples in a single packet.
Still, agreed that the signal does need to be smoothed: I Kalman filter the received signal board-side before sending it to the VESC.
1 Like
Nah, I am just saying that CRC is just CRC and I do not confuse packet with sample, in my demo code I am sending values 100th/s to receiver and there doing all calculation of actual value, my code can lose signal, drop packets, invalid packets and etc without a single problem occurring in the end signal.
So I just calculate throttle position based on calculation and dump live values to the receiver as fast as possible. In the receiver side, I get at least 20 packets, get all the values to apply filtration and safety features and then just send that value to the output. It works nicely on a breadboard, but I think I will be switching to B5 with game controller service or etc using NRF52 MCU
I have worked with many communication protocols, mostly over UART, RS485, RF in industrial applications, so I never trust a packet you wouldn’t believe how much trash you can pick up in 5m cable in industrial application.
Unfortunately the ESP32 Has no fancy counter module to do for instance quadruture signals straight of the box according to the reference manual.
However, i did find this thread on the esp32 forum if you’re interested in pursuing this
1 Like
I’ve been working on a open source electric skateboard platform for a few years now and have designed a encoder based remote based on the DA14580 and DA14583 currently linked up to the skateboard controller running esp32 via Bluetooth, I currently use it as a daily driver, connection is stable but the encryption and pairing isn’t sorted out yet.
2 Likes
Here’s an earlier prototype based on the DA14580 with external flash, I’m happy to share the code and schematics, however it’s still beta ish. Response times are around 50ms I think. It’s using the BLE 4.2 protocol so it’s possible to use a 90mAH battery.
1 Like
What do you use for receiver? ESP32 I assume. How do you power it?
I need to find 10S -> 3.3v converter. Must of them don’t go above 36v.
your esc normally provides 5V
1 Like
The VCC on the VESC Board should give you 3.3V as the STM32F4 processor on the VESC runs on 3.3v.
Schematic from VESC below, This regulator which takes the regulated 5v generated from the DRV8301 is capable of handling 800ma, which should be enough to power the ESP32
1 Like
Yeah, so the receiver is a ESP32 and talks to the VESC via UART. On my own setup I use the LT8640 which provides power to the VESC micro-controllers and the ESP32s and can handle up to 42v input and outputs 3.3v up-to 5A.
I have a custom VESC board with a LIPO charger, LT8640 and 2 VESCs, I might create a separate post to see if anyone is interested to test the whole platform.
3 Likes
This is impressive. Do you have PCB built? I’m not that advanced in EE hence I’m looking for easier option)
I’ve tested built in hall sensor in ESP32 and it works ok. So perhaps that dev board, 3d printed case and couple of magnets is all what’s needed for transmitter.
Thanks, I don’t think a hall sensor is a good idea for this application, you can’t detect the direction the wheel is going in. The resolution will also not be great, you would need really small magnets and/or a really big wheel. Much better to stick with a rotatory encoder, like the ones used in computer mice.
How are your soldering skills? I can send you a couple PCBs for the price that it cost to make + shipping. You would need to solder your own components.
You can then either design your own enclosure or I can get a set printed for you, this will require industrial SLA/SLS printers (I got this done in China), even the SLA printer from Form Labs is not accurate enough and you end up needing to do lots of sanding.
I bought the ESP board, just never got down to putting everything together… If you can do the coding I can try to do up the remote casing… (see my DIY trigger remote thread)
1 Like
Thanks for the offer. Are there many small components? My fingers are too large for SMD components, but I have decent soldering station.
I still hope to create something that can be easily put together and if I can pull this off with this devboard it could be easy to replicate.
From my testing if you use two magnets of opposite polarity you can position them above the chip so it gives positive and negative reading depending on the direction. I hope to do more testing next week.