TSDZ2 OSF for all displays, VLCD5-VLCD6-XH18, LCD3, 860C-850C-SW102.

Supra said:
..anything i can do about the low sensitivity ?
Best is ofcourse a hardware calibration of the sensor.
But first you can try to improve something a bit within the settings.
mbrusa responded here already for such a problem with low sensitive torque sensor.

"Calibration of "Torque adc offset" and "Torque adc max", is used to define the working range, in your case it is essential to do it. Unfortunately, however, when the range is limited, the value of "Torque adc offset" is unstable, a correction may be necessary, you have to try to increase the value. "

It means that if there is some drift (by temperature or so) of the torque values, this has more influence with less sensitive sensors and you need some fiddling with higher torque adc offset value (210...220) to get a better response.
 
Lii said:
mbrusa said:
Lii said:
Hello everyone! I also installed this version on my bike. And now I'm trying to adjust a non-linear increase in power according to the torque sensor. I want the power to increase not linearly, without sudden jumps. But so far I have not succeeded. I have calibrated the torque sensor: I have set the offset (220) and the maximum value (280). But even after calibrating the sensor, the power rises too sharply and therefore the maximum assistance level has to be reduced. I have a VLCD6 display. Is there a way to make the torque sensor response non-linear? I want less assistance with less pedal pressure, more support with hard pedal pressure. How do I tune non-linearity?
What mode are you using?
I checked your setup, you have soooo high assistance parameters, probably caused by the limited range of the torque sensor.
It is difficult for me to test under the same conditions.

You say v20.1C.3-NEW is less powerful with the same parameters.
It doesn't matter, just configure it to have the same performance.
Also consider the advantages of the v20.1C3-NEW version, immediate response when restarting (no lag), quieter engine and lower consumption.

As for the linearity question, the problem is still the limited range of the torque sensor.
The best solution is hardware calibration.
You write "the power increases too abruptly and therefore the maximum level of assistance must be reduced" and then "I want less assistance with less pedal pressure, more support with strong pedal pressure", I didn't quite understand what you want to achieve.
However, to have less power with little push on the pedals, try increasing the offset value, 230/240 instead of 220.
You should also get more power with more push on the pedals, but the power increase will be more abrupt.
You also have to review the Power and Torque assistance parameters, they seem disproportionate to me.
 
Well I'm too embarrassed to say what i did wrong, but ive got it going really well now. Took it for a ride and plenty of power, with nice control for climbing over rock gardens. Very happy, thanks for the advice, and gratitude to the developers.
mbrusa pm me your address and ill send you a bottle of West Australian Margaret River wine.
 
Supra said:
Well I'm too embarrassed to say what i did wrong, but ive got it going really well now. ....
:thumb:
Fine that it works for you now, but you really don't want to tell us what it was?
Even if it's just as a hint for someone in a similar situation.
 
Street mode, maybe?

Elinx said:
Supra said:
Well I'm too embarrassed to say what i did wrong, but ive got it going really well now. ....
:thumb:
Fine that it works for you now, but you really don't want to tell us what it was?
Even if it's just as a hint for someone in a similar situation.
 
I have managed to compile/build the motor source code using VS Code, Win 10 etc. The main.ihx file matches the TSDZ2-v20.1C.3-860C.hex file in the releases folder. So I'm feeling pretty pleased with myself. :lol:

Just a question for those with loads more experience: Is it possible to get sdcc to output to a different folder rather than the source folder. It doesn't really matter I suppose, but I must have ODC (edit: even OCD!!!) as I just want everything compartmentalised and tidy!

I've looked at the SDCC documentation and couldn't see a -o option!!

Gordon
 
mbrusa said:
Lii said:
mbrusa said:
Lii said:
Hello everyone! I also installed this .....
What mode are you using?
I checked your setup, you have soooo high assistance parameters, probably caused by the limited range of the torque sensor.
It is difficult for me to test under the same conditions.

You say v20.1C.3-NEW is less powerful with the same parameters.
It doesn't matter, just configure it to have the same performance.
Also consider the advantages of the v20.1C3-NEW version, immediate response when restarting (no lag), quieter engine and lower consumption.

As for the linearity .......

Hello mbrusa, I am insecure. I installed v20.1C3. Is it correct that the v20.1C3 NEW only has advantages for standard displays? Or should I also use this version on my 860C display?
 
mbrusa said:
Hi mallesepp, v20.1C.3-NEW is for stock display only.
The advantages listed are over v20.1C.1.
Now the versions, as far as the motor is concerned, are all identical.
For the 860C I am testing new features, mainly on the display.
I have to finish the trial period...
Thanks a million for your work mbrusa!
 
Hi, probably @mbrusa

I'm trying to get the build to work for the 850C display on windows (I know, you said you had difficulties) but maybe you have some insights now?

Anyway the key point is being in the C:\Users\Gordon\Downloads\Color_LCD_860C-master\firmware\860C_850C\src folder and from a command line doing make

I'm getting the following error:
Code:
...
WARNING | using display version: 850C_BOOTLOADER
FIND: Parameter format not correct
FIND: Parameter format not correct
arm-none-eabi-gcc -MT _build/../../common/src/fault.o -MD -MP -MF .deps/../../common/src/fault.d -DDISPLAY_850C -DUSE_WITH_BOOTLOADER -I./GD32F10x_standard_peripheral/Include -I./ -I./spl/CMSIS -I./spl/CMSIS/inc -I./spl/inc -DUSE_FULL_ASSERT -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections -l libgcc  -fno-builtin -std=c99 --specs=nano.specs --specs=nosys.specs -Wall  -I../../common/include -DVERSION_STRING=\"0.20.1C-2\" -DTSDZ2_FIRMWARE_MAJOR=\"0\" -DTSDZ2_FIRMWARE_MINOR=\"20\"   -c -o _build/../../common/src/fault.o ../../common/src/fault.c
In file included from ../../common/src/fault.c:1:
../../common/include/screen.h:8:10: fatal error: main.h: No such file or directory
    8 | #include "main.h"
      |          ^~~~~~~~
compilation terminated.
make: *** [Makefile:170: _build/../../common/src/fault.o] Error 1
The system cannot find the file specified.

In the ../../common/include/ folder there is no main.h file, it is in the C:\Users\Gordon\Downloads\Color_LCD_860C-master\firmware\860C_850C\src folder though.

For some reason the compiler isn't finding the include file.

I'll worry about those FIND commands later (it's because there are no .o files for the linker - because they aren't compiled yet. Bit of a strange thing?...

I know you can explicitly identify folders that the compiler should search, but did you do this on the linux side or did it just work.

Was this the issue you were having in windows?

I guess my next step will be to go to my old wsl setup, but would like to work with pure windows as I now have many things working including nrf bluetooth stuff in pure windows.
 
CFLAGS += -std=c99 --specs=nano.specs --specs=nosys.specs -Wall -I../../common/include

looks okay? I assume compiler sees the header files in its own folder!
 
May have been mentioned before but while the 850c is pretty good it's not really bright enough for easy viewing in bright daylight. In fact on sunny days it it pretty much useless except maybe to view the assist number if you squint and get close. The 860c is much much better and not that much more expensive. I have an 850c for sale cheap if anyone wants it.

gfmoore said:
Hi, probably @mbrusa

I'm trying to get the build to work for the 850C display on windows (I know, you said you had difficulties) but maybe you have some insights now?
 
I just flashed the latest version (6891be1) on a new TSDZ2 with a stock VLCD5 display and I'm noticing that the power is cutting out somewhere around 15mph. I am wondering if it's possible that I have street mode turned on or something? I thought I had disabled it in the configurator, and I can't figure out how to control it from the display (is it even possible to modify from the display without "Set parameters on startup" enabled?).

I have another TSDZ2 running this firmware with an 860C and it's running fine so I know this thing has more power to give. This is my first time using a VLCD5. Let me know if you have any ideas. Here is a copy of the settings file I used to flash: https://hastebin.com/eyavorocur.yaml


Thanks!
 
Yes "Street mode" is disabled, but you have set "Max speed (offroad mode)" to 15mph.
This is what limits the power when you hit 15 miles per hour.
If you want to go further you have to set a higher limit.
Or, by enabling "Set max speed from display" you can set the speed limit on the display like the stock firmware.
 
mbrusa said:
Yes "Street mode" is disabled, but you have set "Max speed (offroad mode)" to 15mph.
This is what limits the power when you hit 15 miles per hour.

Wow, how did I miss that... :oops: Thank you!!
 
I'm sorry but I've never tried to compile 860C-850C in a Windows environment.

Oh, ok. Do you compile the 850c code in pure Linux (Ubuntu?) or WSL2 for Windows (Ubuntu?) Linux

Looks like I'll have to set up a toolchain to see what is going on. The Makefile looks very odd, but then again I don't usually have much to do with them, just hope they work and make tweaks!
 
So I setup the toolchain in Ubuntu (barebones) Linux (bare metal installation, not virtual) and ran the ./release-850C_bootloader.sh
script which asked me for the version number - I just used 0.0.1 for now.

I get lots of compiles and I think there is some linking going on but then it errors with
Code:
in/ld: _build/ugui_driver/ugui_display_850c.o: in function `getLcdDevcode':
/home/gordon/860C-850C-Display/Color_LCD_860C-master/firmware/860C_850C/src/ugui_driver/ugui_display_850c.c:600: multiple definition of `getLcdDevcode'; _build/ugui_driver/ugui_display_8x0c.o:/home/gordon/860C-850C-Display/Color_LCD_860C-master/firmware/860C_850C/src/ugui_driver/ugui_display_8x0c.c:779: first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:152: main.elf] Error 1
cp: cannot stat 'main.bin': No such file or directory

Done! If the build went correctly, find the files on: /home/gordon/860C-850C-Display/Color_LCD_860C-master/firmware/releases/0.0.1

There's nothing in the release folder. I can't find main.bin. If someone could confirm where this is/should be please.

Oh hold on, the cp is in the script, not the makefile. So the error is in the line before

There are plenty of warnings, but I know what those are about and I know how to fix them. I think :)

If I look at (around) line 152 on the Makefile I get
Code:
main.elf: $(OBJECTS) startup_stm32f10x_md.o
	@echo "..linking"
	$(LD)  $^ $(LFLAGS) -o $@          <---line 152

startup_stm32f10x_md.o:
	$(AS) $(ASFLAGS) startup_stm32f10x_md.s -o startup_stm32f10x_md.o

I think this is just the linking command being run on each item in OBJECTS, but I'm not sure.

Is that "multiple definition" anything to worry about?

BTW what is difference between release-850C and release-850C_bootloader?

If it could be confirmed that the repository is up to date and that the buildworks on someone's machine from the repository then I could look at my setup and see what I've done wrong.

Well, it keeps me out of trouble while I look for work... :)

Gordon
 
gfmoore said:
I get lots of compiles and I think there is some linking going on but then it errors with
Code:
in/ld: _build/ugui_driver/ugui_display_850c.o: in function `getLcdDevcode':
/home/gordon/860C-850C-Display/Color_LCD_860C-master/firmware/860C_850C/src/ugui_driver/ugui_display_850c.c:600: multiple definition of `getLcdDevcode'; _build/ugui_driver/ugui_display_8x0c.o:/home/gordon/860C-850C-Display/Color_LCD_860C-master/firmware/860C_850C/src/ugui_driver/ugui_display_8x0c.c:779: first defined here

I've built the 850C display code recently for a new 2021 850C display. Mbrusa kindly updated for this to work as the 2021 850C is different to the older model. Where the problem I think lies though is there are two display driver files, and the compiler is erroring out with multiple definitions for the same thing.

The files are in the directory
Color_LCD_860C/firmware/860C_850C/src/ugui_driver/

I believe ugui_display_850c.c is for the 2021 850C and still includes the 860C, while ugui_display_8x0c.c is for the old version of the 850C and 860C. I just deleted ugui_display_8x0c.c and it complies with no multiple definition conflicts.

The bootloader release is built to be uploaded to the display via the Apt display utility and a serial connection. The non-bootloader release has to be flashed using an ST-link programmer to an internal programming header inside the display. I don't know exactly what the code differences are in this case, but for other projects I've done normally when you link for a bootloader you leave gaps in the memory map so the bootloader on the microcontroller itself is not overwritten, and the first thing executed on startup is the bootloader code that then passes control to your code if it doesn't receive an upgrade command over the serial link.
https://github.com/OpenSourceEBike/TSDZ2_wiki/wiki/Flash-the-firmware-on-Bafang-850C-LCD
 
Blacklite said:
I believe ugui_display_850c.c is for the 2021 850C and still includes the 860C, while ugui_display_8x0c.c is for the old version of the 850C and 860C. I just deleted ugui_display_8x0c.c and it complies with no multiple definition conflicts.

The bootloader release is built to be uploaded to the display via the Apt display utility and a serial connection. The non-bootloader release has to be flashed using an ST-link programmer to an internal programming header inside the display.

@Blacklite thankyou very much. That worked perfectly and I can now build on Linux. How on earth did you figure that out? I was wondering about that multiple definitions and was just googling it when you answered. I suppose the benefit is that I have gained a deeper understanding of how make works as well :)

I am trying to compare the released version and the built/compiled version - they are different, but perhaps I haven't done the compare properly. I want to ensure that they are the same before I even being to think about flashing my built version.

I am going to now try and figure out why it won't build on windows as that doesn't make sense to me yet. ;)

Thanks again for your many helpful answers :()

Gordon
 
Blacklite said:
gfmoore said:
If the throttle is turning the motor on the stand at a good rate, what is happening on the road. It's as though the torque? has gone.
The only thing I can think that would make it underwhelming compared to what you had on stock firmware would be that the stock firmware had much higher current/power limits. Also worth checking you are not in street mode with a much lower power limit.

@Blacklite - you are officially my hero! :lol

I decided to totally disable street mode. Saw the orange colour on the assist header and bish bash bosh got loads and loads of power and my throttle is at peak performance.

So, somehow I wasn't able to switch from street mode to non street mode on my 850C. I'm probably doing something stupid, but now I can check the code and see where I've gone wrong. I guess I should have street mode working in case I hear sirens as the boyz try to catch up with me. ;)

I had the most brilliant ride yesterday. It was my longest ride since I got a bike in November and with a mate for the first time and with the assist I was able to keep up with him and get up any hill and got lots of exercise with no assist - I didn't even need the throttle as the torque assist (especially eMTB) is just so brilliant.

I am so happy, though completely shattered.

Thank you everyone. :)
 
gfmoore said:
So, somehow I wasn't able to switch from street mode to non street mode on my 850C. I'm probably doing something stupid, but now I can check the code and see where I've gone wrong. I guess I should have street mode working in case I hear sirens as the boyz try to catch up with me. ;)

Make sure you have the “Enable Hotkey” setting in the Street Mode config menu set to yes, otherwise you won’t be able to switch modes. When enabled the Hotkey is DOWN held together with POWER, until the assist colour changes.

I have my street mode set to 32km/h and 400W limits, which is low enough it doesn’t look like I’m overpowered. Hardly ever turn it off.

I find hybrid mode best for me. It effectively chooses the higher of the assistance calculated for both torque and power modes and uses that. Power tends to not have enough low cadence kick, and torque runs out of puff at the top end. So best of both worlds.
 
Blacklite said:
Make sure you have the “Enable Hotkey” setting in the Street Mode config menu set to yes, otherwise you won’t be able to switch modes. When enabled the Hotkey is DOWN held together with POWER, until the assist colour changes.

Ahh, I misunderstood. I thought the hotkey was the fourth key (M?) on the 860C!!! Thanks. :D

Trying to get make to work with windows is a weird thing. I'm trying to analyse the compile statement to see why it can't find the include files. (see some earlier post). I'll get there eventually...

Although to be honest I'd really like to not use the 850C and use instead my phone (android). I'm working through the original New "TSDZ2... thread (upto page 112 so far...) and I note that @feketehegyi analysed the signals coming out of the motor and displayed stuff on an android phone, but I can't find any details on how he did it. I know Casainho (and what amazing work he did when he came into that thread) has the bluetooth module and android app, but I just like to first get my head around the actual motor interface itself.

I was thinking myself of using NativeScript (I love JavaScript etc) for some app since it can be compiled to Android or iOS. (I hate Android/Kotlin so much work...) I've been playing around with Bluetooth (nRF) and hate that as well. Again what the boys did is remarkable. I just have woolly ideas floating in my head, but really I'd just like to have my phone as the only display and get rid of my Karoo headset and anything else. A main reason is that I'd then be able to actually see things on the display. Man where did my eyesight go, I used to be able to read resistor colour codes no problem when I was in my teens, now I can hardly even see a resistor!!!! :D 8)

Why has programming become so complex and so many things to get your head around. There should be one toolchain to rule them all. Now where's that copy of TurboPascal...

Sorry, just blathering... :wink:
 
Back
Top