Are you in destructive thinking mode?
The MCU logic is designed to prevent these kinds of things. The controller will not accept programming if it is already running normally. You need to shut off the controller, turn on the programming mode and power it up. When it starts up in the programming mode, it will be listening to the handshake from the programmer but will not run until you disable the programming mode. It's a good idea to restart the controller after the programming is done, even though I found it is not necessary: the controller will run the moment you turn off the programming mode. Since parameters are written to MCU registers, it is technically possible to change them while the motor is running but that increases the risk of unpredictable results that can compromise safety. It is not really necessary either.
Bluetooth is simply a connection link to a separate MCU that I install on the controller side. The motor will run fine with a BT connection established and the MCU has more than enough bandwidth to collect and process speed, current, voltage, temperature and what not readings. The hardware is designed around the ability to do that and much more. It's just a matter of putting the right software in place. I am in fact working on it.
I have a couple of working var.regen prototypes that are circuit based which I am not planning to release into production. Once going smartphone route, I realized this can be implemented more efficiently and with much more flexibility in the software. So, I've recreated the logic in the code and, based on the initial testing, it works well plus it's easier to tweak and tune it (like on the go via the app as well). The challenge with the var regen is to pick a sweet spot where the motor-generated current is not too high where it can kill the battery pack. This is quite a variable that will be unique to every particular motor/battery pack combo. So, there needs to be an easy way to limit the current for var.regen like we do for the forward current on the controller. Just to give you an idea, my bike motor (QS205) generates up to 30 amps at 100v, that is 3kw of juice that is pumped back to the pack. That's fine with my pack as it's designed to take this much, but that much current can quickly destroy smaller packs, I mean destroy in in spectacular way with fireworks. Now that I am more or less done with the programming functionality, I'll focus more on the var.regen and hope to turn it around pretty quickly.
FluxZoom wrote:Did you ever try to press the program button with the motor turning? Does the motor still turn when connected via bluetooth?
Any plan to create a way to read things like speed and power consumption using this bluetooth setup?
Hows the variable regenerative braking feature coming along?