VESC - Flipsky 75100 V2 with Bafang Display and T15/T17 BB-Torque Sensor

sirtrancealot said:
so there is some form of paddle assist?
Click to expand...
The VESC has a native support for a quadrature PAS already, it can be selected in the VESC Tool.
There are different working modes, cadence dependent assist or constant torque (like the power levels of a Kunteng)

See the screenshots in #9

There are solutions for a standard 3 wire PAS by lisp scripting also. But lisp scripting seems to deter many users.
https://endless-sphere.com/sphere/threads/finally-pas-on-vesc-with-3-wire-sensor.124707/
 
Last edited:
stancecoke said:
The VESC has a native support for a quadrature PAS already, it can be selected in the VESC Tool.
There are different working modes, cadence dependent assist or constant torque (like the power levels of a Kunteng)

See the screenshots in #9

There are solutions for a standard 3 wire PAS by lisp scripting also. But lisp scripting seems to deter many users.
https://endless-sphere.com/sphere/threads/finally-pas-on-vesc-with-3-wire-sensor.124707/
Click to expand...
Thanks for the rapid answer :) i have one more question: i have the flipsky 75100 pro v2 which doesnt seem to have a second uart connection.. how would you get around that for the speed sensor and brake lever?
Thanks, it took me a couple off days but i got the firmware updated so almost ready to test! Considering i started off a complete noob a couple of days ago
 
stancecoke said:
I've just added this function on the last free input line, UART2 Tx.
github.com

Add brake sensor support on UART2 Tx · stancecoke/VESC_BLDC@0153792

The VESC motor control firmware. Contribute to stancecoke/VESC_BLDC development by creating an account on GitHub.
github.com github.com
It could be used as a gear sensor input also, but currently it stops the motor only as long as the UART2 Tx line is pulled to GND.

regards
stancecoke

Flipsky%20wiring.PNG
Click to expand...
This hack actually prevents compilation of anything else than the flipsky 75_100_V2 code changed by stancecoke. You have to comment it out to compile a different firmware. On the other hand the tq sensor hack compiles fine with any firmware - tested with a spintend ubox single 100 and a trampa vesc
 
What config is required in the vesc to enable the display ? I'm getting error 30 and no serial data stream as if eveything was just shut down.
 
qwerkus said:
What config is required in the vesc to enable the display ?
Click to expand...
If you use my precompiled hex file, it works directly after flashing with a Flipsky 75100.

If you are using a different hardware, there will be a different pin definition for the UART Rx and Tx pins, or you missed something in porting the code to your hardware.
 
stancecoke said:
If you use my precompiled hex file, it works directly after flashing with a Flipsky 75100.

If you are using a different hardware, there will be a different pin definition for the UART Rx and Tx pins, or you missed something in porting the code to your hardware.
Click to expand...
Nope, my port is not ready yet so I wanted to give your changes a go again, but all I get is error 30 on the display. Everything is still on the test bench, vesc, t17, sw102 and motor connected - yet nothing. I did not use the precompiled hex though - git cloned the code and compile it locally. Note that the vesctool keeps complaining about the lack for compatibility since I flashed your firmware. I tried BETA and 6.05 vesc-tool in both case motor auto detection doesn't work because it's not the exact matching firmware so I hat do enter everything manually.

EDIT: Tried the precompiled file; same deal: error 30
 
Last edited:
I had same issue, i tried fsesc flipsky 75100, and fsesc flipsky 75100 pro, I used precompilied hex file from project but all the time I had error 30, I tried to compile new hex but there werent on the make list (I found just fsesc 75200 or 75300). Now I'm waiting for delivery new sw102 and makerbase 75100 qnd I will try with new display and new controller.
 
Last edited:
stancecoke said:
See #59, it works with this commit of the VESC Tool only.
But I can't understand why the communication fails for you. It works flawlessly for me, as you can see in the YouTube video....
Click to expand...
What's the min. setup I need to debug the display: only vesc (+power source) and display, or does a motor and the T17 need to be attached ?
 
qwerkus said:
What's the min. setup I need to debug the display: only vesc (+power source)
Click to expand...
Yes, I tested it yesterday evening. I get no error and the battery indicator changes with different voltages from the lab power supply.

Maybe the wrong VESC Tool version writes something weird into the VESC memory. I had to do a full chip erase several times and flash directly to the chip with a STLink to get rid of not working settings from the VESC Tool. :oop:
 
Last edited:
stancecoke said:
Yes, I tested it yesterday evening. I get no error and the battery indicator changes with different voltages from the lab power supply.

Maybe the wrong VESC Tool version writes something weird into the VESC memory. I had to do a full chip erase several times and flash directly to the chip with a STLink to get rid of not working settings from the VESC Tool. :oop:
Click to expand...
This is very interesting - thank you very much for the input!

My spintend project with the t17 and kt display is stalled because I can't get a signal over the rx pin. It worked fine a week ago and now nothing. Maybe that bafang error 30 is related and there is indeed a bug somewhere in the flash process of the vesc tool on third party hw?

I found the swd header on the flipsky - very handy for such a otherwise cheap controller! stm32cubide is setup and I have one of those stlinkv2 usb dongles + stlink. Before I start erasing and potentially brick the flipsky, anything I should be paying attention to ? Does the raw bin include the bootloader ?
 
Last edited:
qwerkus said:
Before I start erasing and potentially brick the flipsky, anything I should be paying attention to ? Does the raw bin include the bootloader ?
Click to expand...
It is save to flash by the STLink, the hex/bin files include the bootloader.
But make sure, that you make a "full chip erase" with the STM32 Utility (or other tools), to clean the pages, that are used as EEPROM. Otherwise the old setting will still be there.
 
stancecoke said:
It is save to flash by the STLink, the hex/bin files include the bootloader.
But make sure, that you make a "full chip erase" with the STM32 Utility (or other tools), to clean the pages, that are used as EEPROM. Otherwise the old setting will still be there.
Click to expand...
Did it today, erased 3x times and flashed. Good new is the stlink i got works, bad news is still error 30. Maybe I could try to connect the display over the nrf uart header ?
 
If I wanted to run VESC+BBSHD with the stock display, is this the best project for me? I don't have a torque sensor, I'm just looking to ride with the thumb throttle. Maybe instead of the torque sensor the shift sensor can be used? (not that much shifting needs to be done, just so I don't cause unnecessary wear).

What are the options if I want to have two modes, "street" and "race" (legal and not-so-legal)? Currently if I start my bike with the brake lever engaged, the speed is unlocked. An external switch would be OK too, I guess ADC2 could be used for that? Or enabling flashlight in the Bafang display.

Is switching my BMS output on/off sufficient enough for turning this controller on/off?

Does the linked Flipsky come with an integrated bluetooth? The aliexpress specs page isn't quite clear on that, I think it says it *supports* a BT UART module, but is it possible to use it when the UART2 port is already in use?

There's also a Makerbase VESC 75100 for significantly cheaper (51€ vs 79€), what's the difference?

Are there any other resources related to modifying a BBSHD with a VESC? I'm quite new to custom controllers so I'd like to be the most prepared before attempting this. For example the hall sensor inputs are empty in your diagram but I do think the BBSHD has hall sensors, so I guess users are expected to just know to connect them :)?

Currently running BBSHD with shunt modded (50A) stock controller (open source fw) and a 15S battery, looking to get a bit more oomph :-D
 
Last edited:
bindi said:
If I wanted to run VESC+BBSHD with the stock display, is this the best project for me?
Click to expand...
I don't know, if it's the best, when I read from others, that they can't get their display work. For me it's working 🤷‍♂️

I have not drawn the motor connection in the diagram. Neither the phase wires nor the hall sensor wires.
The Flipsky 75100 has no BT integrated, but of course you can attach a BT module to the UART connector.
 
bindi said:
But the COMM (RX/TX) is already attached to the display, and UART2 (RX2/TX2) is used by the speed sensor and the brake switch?
Click to expand...
Why do you want to use the display and the BT module at the same time? You have to setup the system only once, by the USB connector, or by the BT module. 🤷‍♂️
 
You're saying there's never going to be any problems ever? xD I see lots of VESC threads about debugging and logging and testing out different parameters, I don't intend on changing the wiring each time there's a problem.

People are also saying the BT / Android app is *really* useful.
 
stancecoke said:
?! You have to connect it exactly like in the diagram in the first post of this thread. Be aware, that the diagram shows the controller side (male connector)
Click to expand...
Just another data point, I recently tried with your firmware on my Flipsky 75100 V2 Pro following this thread, but I also get Err 30. My logic analyzer shows the display sending out serial data as it should, but there is nothing at all coming from the Flipsky hardware. I've tried flashing both the .bin and .hex with no luck.
 
stancecoke said:
Can you check the BAUD rate? Normally Bafang uses 1200 BAUD, but somewhere I read, that newer displays are using a higher rate...
Click to expand...
Yeah, the display is transmitting at 1200 Baud. It might be a few days until I get around to testing again, but I'll capture the messages the display is sending out.
 
stuffman said:
but I'll capture the messages the display is sending out.
Click to expand...
Would be great! See #84.
Maybe your display sends an unknown command and the Luna Cycle algorithm can't catch it. I remember, there was one command commented out, and it was the same behaviour, communication just stopped completely. We would to have add a routine, that manages unknown commands....
 
stancecoke said:
Would be great! See #84.
Maybe your display sends an unknown command and the Luna Cycle algorithm can't catch it. I remember, there was one command commented out, and it was the same behaviour, communication just stopped completely. We would to have add a routine, that manages unknown commands....
Click to expand...
Definitely getting some strange commands along with the defined ones:

DisplaySerial

Hopefully this can provide some insight!
 
You must log in or register to reply here.
Back
Top