I guess I would start off by aiming for browser. Then explore node and nativescript if that didn’t work out.
It seems that some people may not be taking me seriously as they think my assumption that Bluetooth from a browser means is idiotic and is reflective of my lacking in ability. So it may come as a surprise to some developers but the browser is capable of a Bluetooth connection. However, I can’t say for sure if it’s as sophisticated as we might need. Nodejs has libraries for Bluetooth connection as well so that was my second choice. Also Nativescript has some tools Bluetooth as well but also some swift/java/objective c bindings could be used. However I would say that I would prefer desktop access. Potential tools/technologies:
My goal would be to create a tool that:
- Works for me over Bluetooth. As right now neither desktop app works over Bluetooth. And I have the latest Android which seems to break alot of the mobile apps available for the Android platform.
@Ackmaniac any insight would be greatly appreciated.
The VESC tool itself works via Bluetooth. https://vesc-project.com/node/234 I’m already using nrf to connect VESC tool to both my FOCboxes (it can connect to the other controllers via CAN) from both my laptop and my phone. Works like a charm. It’s available on Benjamins github: What it still misses is switching between configuration modes, and a decent realtime data display. But the job you’re describing is already 95% done.
The vesc communicates through UART interface.
Have a look at this for what commands to send:
Noooo, surely not . Ok on first reading kinda yes, but then I remembered browsers have access to pretty much everything else (mic, camera, accelerometer, GPS) these days so it sounded entirely plausible.
Web-bluetooth support seems limited to Bluetooth LE which is fine, but it also seems somewhat restricted to Chrome. Not great, but Chrome has decent market share these days. Knowing Apple, I’m not sure you could ever expect to see support implemented in mobile Safari.
The link that cryo posted includes the implementation/definition of the ‘higher level’ (payload) VESC communication protocol. It’s important to note this may change in any firmware update. The lower level is described in one of Vedder’s blog posts. It’s quite elegant in its simplicity.
- One Start byte (value 2 for short packets and 3 for long packets)
- One or two bytes specifying the packet length
- The payload of the packet
- Two bytes with a CRC checksum on the payload
- One stop byte (value 3)
I don’t think you need justification for doing this; if you want to do it, then do it . But I can see several advantages in addition to what you’ve already listed.
- Given the choice between a browser based tool, and a desktop tool, I’d probably go for the browser these days. Mainly just convenience.
- If you reimplemented (not port, proper cleanroom implementation) the VESC communication protocol you’d probably be ok to release it under a less restrictive license (MIT, etc).
- Could be good for a remote support tool. I understand Enertion diagnose problems via a remote desktop tool (urgh).