Ok then when you use the app then try to only see the data of the slave when you ride. Because it can be too much for the master to provide the realtime data to the remote and the app at the same time. When you only capture the data of the slave it is no problem. Don’t think that this is your problem but it is worth a try.
And you should also check the data when you brake. Because maybe the Firefly ESC sees too high current at low currents. Easy to do with the app by using the video function.
BTW maybe you can make a video with the app and provide it here. By that i could tell you much better what is going on in detail. That’s what the feature is there for.
Sorry I am not following. So I have to disable the option “connect by CAN to ID 0”? But if I do that I won’t be able to change the modes afterwards, right? In the past I had the module connected to the slave too with vesc 4.12 and didn’t have this problem. I think it’s really the VESC.
Sadly i don’t know in which frequence the remote is capturing the realtime data. So it could cause issues. But that is easy to test by just simply doing a ride without the app. If the issue is still there then that is not the root cause.
the receiver uses 115200 baud rate. or well the receiver is sending at 115200, while the remote itself is 9600. To be able to receive data on the remote display I need to set it at 115200 at the master UART level. I had the same behaviour also with the nano x remote, if that can helps.
Have you tried it without the Bluetooth module? Really strange…
no the bluetooth module was always connected but I do not understand why it can be a problem with the module. I will try all the combination possible.
The Bluetooth module can only be a issue if it asks the master for the realtimedata and the remote does the same as well. Baudrates do not matter. BUt if the Nano X had the same behavior then it isn’t the root cause. I guess the ESC detects the wrong data but that can be clarified with a video where we can see the realtime data.
1 Like
ok I will make it and post it. I hope on bench test is gonna be fine otherwise I will crash trying to make it 
No need to do crazy rides. Just simply do full brakes where it acts weird and let us know at whichsecond of the video you did so.
before one of my flipsky vesc broke i had one motor which brakes and one which doesnt.i think the master didnt if i rember correct.
but i didnt find something about this behavior either
Damn I unpacked them like 2 days ago. They both brakes but in case of gently brakes the slave in my case is keeping spinning like that . Only in FOC not in BLDC though.
yeh but when I rode it this morning you can not feel that behaviour. The brakes are just really weak. the only way to see this behaviour is during bench testing.
Is “Send status via CAN” active on the slave?
I think yes since the bluetooth works and I can change the modes on both the vesc, but to be honest I do not remember. I will check this evening. I write down all the different tests I need to do it. Thanks for the help
1 Like
Ok so here the video after increasing the motor min and the battery min. It definetely does the trick now the brakes are ok
Do you see something weird? One thing I am not sure is the duty that never reach 0 even when I engage the braking. In this case still bluetooth connected to the slave and then connect by CAN to ID 0 enable. So we are looking to the master data. Tried afterward and the weird behavior still there but when you ride you don’t notice it.
Then remove the connect to CAN ID 0 in the app to se slave data e see what happen and here the master motor now keep acceleration when I am braking.
Probably the second test doesn’t tell anything. Should I simply remove the Bluetooth signal from the slave and see if that helps? Or also remove the UART signal from the master VESC for the remote.
And to answer to your other question send status over can is active at the slave side.
Real voltage at the end of the ride was 48.7V.
Here a bit of telemetry data from this morinig Dropbox - 2018-10-25_10-01-47_Avenger_X_esc_Data.csv - Simplify your life Cube Archive
Screenshot of the results
I see that the regenerative current didn’t exceed -10A so seems ok.
Hi! So here the screenshots: Master:
Slave (bluetooth connected)
Do you see something weird? Anyhow tired to rise the setting and indeed now it brakes again -60A/-11A did the trick! Thx The weird behaviour still there.
If the “master motor still spinning on low brake” issue is still present, try swapping “Send CAN status” for both vescs. Master should have True and slave should have False. Then also turn off traction control. To be honest everything looks fine and your motor shouldn’t be spinning at low brake… it should be stopped, but see if that helps?
Well based on what I know if you use @Ackmaniac firmware and the Bluetooth is connected to the slave then the slave vesc has to be with send status over CAN active while master not. For the spinning during brakes is either the motor connected to the slave or both together.
@Ackmaniac I was also thinking at maybe connect the Bluetooth to the master VESC and move only the UART cable from the receiver to the slave vesc. The remote has a ppm signal part that would be on the master and the real data would take from the slave. In this way the master won’t have to deal with double data transferring but only through the Bluetooth.