Bluetooth development guide

Acklavidian · May 24, 2018, 12:19pm

I was considering making a JavaScript app for vesc configuration and monitoring over Bluetooth. I don’t have much experience with bluetooth/serial interfaces. However I have successfully connected to the vesc but I don’t know what instructions I can send. Where could I find this documentation?

egzplicit · May 24, 2018, 12:42pm

What platform?

Acklavidian · May 24, 2018, 1:06pm

I guess I would start off by aiming for browser. Then explore node and nativescript if that didn’t work out.

Acklavidian · May 24, 2018, 4:20pm

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:

Acklavidian · May 24, 2018, 4:27pm

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.
Create an app with a more maintainable code base via expanding it’s developer accessibility through easier technologies like JavaScript and reduce duplication of efforts by using code once run anywhere tech. Eg. No more desktop/mobile split.

Acklavidian · May 24, 2018, 4:28pm

@Ackmaniac any insight would be greatly appreciated.

Mathias · May 24, 2018, 5:38pm

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.

cryo · May 24, 2018, 7:00pm

The vesc communicates through UART interface.

Have a look at this for what commands to send:

github.com

vedderb/bldc/blob/master/commands.c

/*
	Copyright 2016 - 2019 Benjamin Vedder	[email protected]

	This file is part of the VESC firmware.

	The VESC firmware is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    The VESC firmware is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

#include "commands.h"

This file has been truncated. show original

lock · May 25, 2018, 2:44am

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).