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

I totally concur on Hybrid mode, especially for fast road riding. It makes power delivery pretty much seamless as you shift and change cadence. Just for giggles I experimented a little with pure cadence mode on a few rides this week. It works fine, but man, I don't see how anyone rides PAS only bikes. No comparison to what the OSF guys have wrought... or really even the TSDZ2 OEM torque drive which is still far superior to PAS... at least if you are used to riding real bikes fast.

Blacklite said:
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.
 
gfmoore said:
...

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. ....
@feketehegyi did the most simple interfacing between controller and bluetooth by soldering just a simple HC05 module inside the controller (or outside with a 5V supply). But he has removed all his first videos about this (voamca) and did not made a complete "how to" description on Github. You must grab the bits together.
I have made a short summary of it here
For OSF stock display you can replace (or change code of) one file to communicate (ebike_app.c), but for other display version you must add some code to a file (ebike_app.c too ?) before compiling.
I don't know if the app works as expected, because I know nothing about configuration differences between OSF for stock and other display's. feketehegyi made and demonstrate it for stock display OSF.

________________________________________________________________________________________________
EDIT: jul 27 2021
Everything for OSF is removed, so most of the links don't work anymore.

________________________________________________________________________________________________

mspider65 did made wireless for stock display too and casainho made it for 860C.
They did both a great job, but both HW interfacing is a bit more complex.
Advantage is the documentation, which is a lot better and all open source.
 
gfmoore said:
Although to be honest I'd really like to not use the 850C and use instead my phone (android).

I haven’t used it but look at mspider65’s Android implementation. The motor firmware for the Mbrusa build you are using is forked from his project, and his improvements in motor code, including hall calibration, are pretty amazing. Casainho based his android app off mspider’s I believe.
https://github.com/TSDZ2-ESP32/TSDZ2-ESP32-Wiki/wiki
https://endless-sphere.com/forums/viewtopic.php?f=30&t=103318
A great read on how he improved the motor performance.
https://endless-sphere.com/forums/viewtopic.php?f=30&t=110121
 
@Elinx and @Blacklite

Thanks for the info and links.

I actually have mspider65's board, but I baulked (so far) at opening up the motor and splicing connections to the controller. I also have the nrf52840 bluetooth dongles (and even the dk development board) that Casainho's bluetooth system uses. I could see that he could set up parameters for the OSF from an app, but not yet understood if/how he was reading data from the motor. He used ANT+ to communicate with his Garmin, but I don't use Garmin.

I'm someone who usually likes to try and break down code so I can get a handle on how it works. I tried learning how to use the BT dongles and made progress, but I found that it was really hard to figure out how BT really worked and how to use it in code. For instance as I was trying to figure out how to get the OTA DFU (Over the air device firmware update) to work Nordic told me it was impossible to get the dongle to do over the air updates without flashing it from a DK board or Segger, even though I know Casainho et al did it! I got so frustrated with Nordic that I've left working with it for now. I will probably go back to it.

I was just thinking (as did @feketehegyi) of just reading what was going on between the motor and the display and getting some kind of feel for what I'd need to read/send. I'd probably need to get my head round the motor and display code and Casainho's bluetooth code to do this.

I have written some node.js code in the past for reading the output from my solar power/mains display gadget and displaying it on a web page, but doing that on a bike is not the same. I was thinking of looking at a nodemcu board since that works with wi-fi which (in my head) is much easier to use than Bluetooth or ANT+ (I mean have you ever looked at the specs for those!), but then I'm not sure that is the best way forward as you'd not want to have to connect your phone to the interface with wi-fi? But it's what I am able to do at the moment. I hate steep learning curves, just like I hate steep gradients! Then there's creating Fit files and connecting to Strava - they aren't straightforward either from scartch, though I have located a good library that can read them, never tried to write one. Funnily enough doing maps is relatively easy!

I also would like to create a nicer interface - much like the analogue car speedo style of the original 850c display. This is relatively straightforward using Javascript libraries for me.

I think I need to just hi-jack the motor to display harness and grab the gnd tx, rx lines and read through a ttl-usb dongle (as used for flashing?) I mean it's basically serial/uart (just like in the old days when we used rs-232-c, I guess!) Maybe even just keep it wired through usb on the phone (though do later phones/iphones still use usb - will they in the future?)

As I write this I'm thinking that using Casainho's bluetooth dongle and hacking that is probably going to be the best way forward.

I know I'm going around in circles, but each iteration is slowly building up my mental model of what is going on. I am constantly amazed at what these wonderful people have accomplished and the generosity of spirt that gives us so much.


I wish there were tutorials on how all these things work. For instance a specification for the motor interface? What does it send, what does it read. Is the config information stored in the motor controller memory, or is it stored in the display/bluetooth dongle and re-sent at switch on. Some pseudo code or a flowchart would be real nice. I know I can get this eventually from reading the code, but it isn't a simple job for someone new to it.

I'm blathering again... Perhaps I should just enjoy what I have and go for a ride!!! :lol
 
gfmoore said:
....


I wish there were tutorials on how all these things work.....
I'm blathering again... Perhaps I should just enjoy what I have and go for a ride!!! :lol
Imho the problem is you indeed are going in circles between casainho, mspider65, mbrusa and now feketehegyi too. You didn't made a real choice based on what you had, have and want to do.

They all use he same sources, but change these for their own needs, so the result is, as you have seen, different (with different code too).

The best tutorial and how to you find in the tsdz2 wiki.
mbrusa has his own (small) wiki

Before the wiki all Tsdz2 information is collected inside bitbucket
 
Elinx said:
Imho the problem is you indeed are going in circles between casainho, mspider65, mbrusa and now feketehegyi too. You didn't made a real choice based on what you had, have and want to do.

:lol: you are correct. But this is because there is nothing that I can find that does exactly what I want. i.e. use my phone, probably via bluetooth to connect to the motor that allows me to set the motor and display information from the motor and allows me to customise the mobile phone display.

Each developer has their own view of what they want to do, but nothing quite meets what I want. It's taken me a while to try and figure out what this motor does and what others have done with it. In going through the posts and threads I'm thinking, ahh yes that might do it and then I find I can't either get a toolchain that compiles e.g. Casainhos or I have to do some surgery that I am not yet prepared to do, mspider65 or feketehegyi in the original New TSDZ2 thread at around page 110+ which I'm reading comes on the scene and I think, yes that's what I want, but he provides no information and then blanks his videos. (A point you asked him about, but got a quite evasive answer!)

This thread of mbrusa's is brilliant and has gotten me into the OSF (because I had to do something or my motor was just metal waste), but now I'm thinking how can I take it forward and achieve my ultimate aim.

As I badly explained, I like to re-invent the wheel so I understand what I am doing. I don't really just like to pick up code and guess at what I'm doing, but my brain at my age is now struggling to get to grips with all the technologies that you need to do all this embedded stuff. I get there in the end, but I'm not quick enough. But please, just so you realise that I'm not a complete idiot have look at some recent programming I did on https://www.esci.thenewstatistics.com/ Of course it's got nothing to do with embedded systems, but it wasn't trivial!)

Give me a job that needs HTML, CSS, Javascript, Node and I'm away, but getting these toolchains to work and understanding what the heck is going on with the hardware, bluetooth, ANT+, bldc motors and the like is a whole new world. Man even riding a bike is an experience I haven't had for 35 years!

I'm just grateful that you folks have been so patient with me.

And in being patient, after writing my last drivel I decided I needed to do more than talk I needed to do something. So I thought, right get a 8 pin extension cable, cut off the end and plug it into a breadboard and get my scope out and re-invent feketehegyi's wheel (edit: wheel? :) perhaps I meant application :lol:) . Guess what, I can't find one, which is weird, considering there must be thousands of 8pin controllers in use.

There's this https://www.ebay.co.uk/itm/143490350349?var=442451910144&hash=item2168b0fd0d:g:6DwAAOSwe2JeDxMs but it's rather expensive!!!

Anyone got a link to a supplier (I've looked all over aliexpress!) Seems 9 pin is all that's available.
 
Elinx said:
The best tutorial and how to you find in the tsdz2 wiki.
mbrusa has his own (small) wiki

Before the wiki all Tsdz2 information is collected inside bitbucket

Yes, but as far as I can tell none of these actually explain the interface and specifications. For example:
What bytes are being sent from the motor that provides the information on say the current currently being drawn.
What bytes need to be sent to the controller to set the lower voltage limit, or whatever.

I know it's in the code, but I just haven't figured out where yet.

Edit: perhaps the motor is sending/receiving a packet of information and I'd like to know the structure of it? Is it written down somewhere?

:)
 
gfmoore said:
I know it's in the code, but I just haven't figured out where yet.

In the motor firmware look at the communications_controller and communications_process_package functions in ebike_app.c
You will also need to check the state machine in the UART RX interrupt routine, also in ebike_app.c
 
Hello,

I've been running TSDZ2 osf 20.1C.3 with 860C display without problem.

Now I've switched to a SW102 display. I have problems with display hanging repeatedly on configuration panel. For example when I go to "display" menu, everytime I want to scroll down below "reset ble connections", display hangs and I have to remove battery to revive it.

Same with "torque sensor calibration" : when i try to scroll below the "torque adc with weight" line, display hangs.

Problem is that I can not access some options... the next option which is "config shortcut key" :-(

The display is in 20.1C.2, which seems to be the last one. Is it the reason why it does not work with 20.1C.3 ? Should I downgrade the TSDZ2 to 20.1C.2 ?

Ben
 
ben5763 said:
Hello,

I've been running TSDZ2 osf 20.1C.3 with 860C display without problem.

Now I've switched to a SW102 display. I have problems with display hanging repeatedly on configuration panel. For example when I go to "display" menu, everytime I want to scroll down below "reset ble connections", display hangs and I have to remove battery to revive it.

Same with "torque sensor calibration" : when i try to scroll below the "torque adc with weight" line, display hangs.

Problem is that I can not access some options... the next option which is "config shortcut key" :-(

The display is in 20.1C.2, which seems to be the last one. Is it the reason why it does not work with 20.1C.3 ? Should I downgrade the TSDZ2 to 20.1C.2 ?

Ben

Well... did some testing today. Downgrade to 20.1C.1 with no change. Than I found a way : when an option is freezing, modify another option above the one which causes the freeze, save exit, and next time it works. At least it worked on the display menu.

Then i noticed that ther is no "config shortcut key" in the menu of the sw102. Does it mean that some features of the 860c 20.1C.3 are not implemented for the SW102 ? I'm a bit lost :wink:

On the other side, everything works OK. I use the tsdz2 on a full suspended mtb, and the eMTB mode is really a must !! Thanks for all the work :thumb:

It's just that I loved this shortkey feature to enter the configuration menu 8)
 
Blacklite said:
In the motor firmware look at the communications_controller and communications_process_package functions in ebike_app.c
You will also need to check the state machine in the UART RX interrupt routine, also in ebike_app.c

Thank you so much, that is very helpful. :D

Today, however, I have been battling with the makefile for 850C and windows. There be dragons there.

However, I think I've slain it, though it might get up and roast me yet.

I didn't know much about make (and I still don't) but this is a particularly convoluted example that I still don't understand. I think it's probably because it is trying to build different things and trying to make use of common source files and where necessary not have to rebuild things. (Well, I suppose that is what make is all about), anyway I digress

The main issues with converting it to work with Windows is that operating system commands like rm = rmdir and mkdir are not the same in Linux and Windows. Also the commands in windows don't like trailing slashes for directory/folder names. Commands in windows easily fail. Sometimes the / is ok, sometimes not and a \ must be used (as in a batch file)

Make is a very strange weapon, where logical inference must go out the window (er!) because what works in one context won't in another. Within a "rule" variables only exist within a line and there are strange variable names such $@ $< and so on. It's done my head in. It isn't easy to debug - old school with lots of $(info ...) statements (where it's possible)!

EDIT: You will see from later posts that this does not work with pure windows command. I hadn't made the connection, but I was using a windows command shell called CMDER (which is easy to install) and that allows some Linux (or UNIX) like commands such as ls and allows forward slashes for subfolder separators. Pure windows command only likes \, doesn't have ls only dir whereas Makefile needs \\ and I couldn't get it to work. Close, but no cigar.

However here is the Windows Makefile I created that seems to work: (in ... Color_LCD_860C-master\firmware\860C_850C\src)
Code:
#  Copyright (C) 2015 Joerg Hoener
#
#    This program 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.
#
#    This program 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/>.

#GM add this for windows
SHELL=cmd

# we expect DISPLAY_VERSION to be passed as argument to Make, like: make DISPLAY_VERSION="860C_BOOTLOADER"
# check to see if version is defined, if not, assume default
ifndef DISPLAY_VERSION
  CFLAGS += -DDISPLAY_850C
  DISPLAY_VERSION_DEFINED = yes
  $(info WARNING | using default display version: DISPLAY_850C, no bootloader)
endif

ifeq ($(DISPLAY_VERSION), 850C_BOOTLOADER)
  CFLAGS += -DDISPLAY_850C
  BOOTLOADER = yes
  DISPLAY_VERSION_DEFINED = yes
endif

ifeq ($(DISPLAY_VERSION), 860C_BOOTLOADER)
  CFLAGS += -DDISPLAY_860C
  BOOTLOADER = yes
  DISPLAY_VERSION_DEFINED = yes
endif

ifneq ($(DISPLAY_VERSION_DEFINED), yes)
  $(error wrong DISPLAY_VERSION or not set)
else
  ifeq ($(DISPLAY_VERSION), 850C_BOOTLOADER)
  $(info WARNING | using display version: 850C_BOOTLOADER)
  endif
  ifeq ($(DISPLAY_VERSION), 860C_BOOTLOADER)
  $(info WARNING | using display version: 860C_BOOTLOADER)
  endif
endif

ifdef BOOTLOADER
CFLAGS += -DUSE_WITH_BOOTLOADER
LFLAGS = -Xlinker --defsym=USE_WITH_BOOTLOADER=1
endif

TCPREFIX  = arm-none-eabi-
CC      = $(TCPREFIX)gcc
AS      = $(TCPREFIX)as 
LD      = $(TCPREFIX)gcc -v # use GCC and not LD so the math functions work like atan2()
CP      = $(TCPREFIX)objcopy
OD      = $(TCPREFIX)objdump
GDB     = $(TCPREFIX)gdb
SIZE     = $(TCPREFIX)size



# Optimization level, can be [0, 1, 2, 3, s]. 
# 0 = Turn off optimization. Reduce compilation time and make debugging
#     produce the expected results.
# 1 = The compiler tries to reduce code size and execution time, without
#     performing any optimizations that take a great deal of compilation time.
# 2 = GCC performs nearly all supported optimizations that do not involve a 
#     space-speed tradeoff. As compared to -O1, this option increases
#     both compilation time and the performance of the generated code.
# 3 = Optimize yet more. Turns on -finline-functions and more.
# s = -Os enables all -O2 optimizations that do not typically increase code
#     size.
# (See gcc manual for further information)
OPT = 0

# -mfix-cortex-m3-ldrd should be enabled by default for Cortex M3.
# CFLAGS -H show header files

AFLAGS  = -I./GD32F10x_standard_peripheral/Include -I -Ispl/CMSIS -Ispl/inc -c -g -mcpu=cortex-m3 -mthumb -l libgcc

#CFLAGS  += -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 -O$(OPT) -g -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections -l libgcc 

#Windows doesn't like -I./ it wants -I.  ignore the forward slash
CFLAGS  += -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 -O$(OPT) -g -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections -l libgcc 

# Need following option for LTO as LTO will treat retarget functions as
# unused without following option
CFLAGS += -fno-builtin
CFLAGS += -std=c99 --specs=nano.specs --specs=nosys.specs -Wall  -I../../common/include

LFLAGS  += -Tstm32_flash.ld -L/usr/lib/gcc/arm-none-eabi/4.9.3/armv7-m -lgcc -lm -nostartfiles -lnosys -mcpu=cortex-m3 -mthumb -Wl,--gc-sections

LFLAGS += --specs=nano.specs --specs=nosys.specs # to use newlib nano
LFLAGS += -Xlinker -Map=main.map
#LFLAGS += -u _printf_float # newlib nano printf use floats
#LFLAGS += -u _scanf_float # newlib nano scanf use floats
CPFLAGS = -Obinary 
ODFLAGS = -S


#Get all the source files
include ../../common/Makefile.common

COMMONDIR = ../../common/src

OBJDIR = _build

#added here by GM from the dep magic code at bottom
DEPDIR := _deps

#CUSTOM_SOURCES=$(shell find spl ugui_driver *.c -type f -iname '*.c') 
#Linux find command doesn't work as provided - gives error 
CUSTOM_SOURCES = $(shell ls spl/CMSIS/*.c spl/src/*.c ugui_driver/*.c *.c) 

COMMON_SOURCES = fault.c buttons.c utils.c ugui.c fonts.c state.c screen.c mainscreen.c configscreen.c eeprom.c

SOURCES = $(CUSTOM_SOURCES) $(foreach x, $(COMMON_SOURCES), $(COMMONDIR)/$(x))

OBJECTS = $(foreach x, $(basename $(SOURCES)), $(OBJDIR)/$(x).o)

#$(info gm ----------------> $(SOURCES) )
#$(info gm ----------------> $(OBJECTS) )


# dev platform specific.
# OPENOCD_PATH := E:/nrf5/Toolchain/OpenOCD/0.10.0-12-20190422-2015/bin
# OPENOCD_BIN := openocd.exe
# NRFUTIL := $(SDK_ROOT)/external_tools/Windows/nrfutil.exe

OPENOCD_PATH := /usr/local/share/openocd/bin
OPENOCD_BIN := openocd
NRFUTIL := nrfutil

OPENOCD := '$(OPENOCD_PATH)/$(OPENOCD_BIN)' -f $(OPENOCD_PATH)/../scripts/interface/stlink.cfg -f $(OPENOCD_PATH)/../scripts/target/stm32f1x.cfg

all: main.bin size

# Ignore - useful for debugging makefiles
test:
	echo objs $(OBJECTS)

clean: 
	@echo "...cleaning"
#	rm -f main.lst main.elf main.bin
#	rm -rf $(OBJDIR) .deps
	del main.lst
	del main.elf
	del main.bin
	rmdir /S /Q $(OBJDIR)
	rmdir /S /Q $(DEPDIR) 

#flash_serial: main.bin 
#	$(STM32FLASH) main.bin

# before using this unlock cpu with
# > stm32f1x unlock 0
# stm32f1x unlocked.
# INFO: a reset or power cycle is required for the new settings to take effect.
#flash_jtag: main.bin
#	$(OPENOCD) -c "init; reset halt; sleep 500; stm32f1x mass_erase 0; flash write_bank 0 main.bin 0; shutdown"

#run_jtag: flash_jtag
#	$(OPENOCD) -c "init; reset halt; reset run; shutdown"

# Just start an openocd session
#openocd:
#	$(OPENOCD) 

size:
	@echo "Size:"
	$(SIZE) main.elf

main.bin: main.elf
#	@echo "...copying"
	$(CP) $(CPFLAGS) main.elf main.bin
	$(OD) $(ODFLAGS) main.elf > main.lst

main.elf: $(OBJECTS) startup_stm32f10x_md.o
	@echo "..linking"
	$(LD)  $^ $(LFLAGS) -o $@

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

#
# The following makefile magic generates proper dependencies for headerfiles, so that if you change a headerfile
# the correct C files that use it will be recompiled 
#Changed .deps to _deps in windows (In linux .deps is a hidden file. Also moved higher up this makefile
#DEPDIR := _deps
DEPFLAGS = -MT $@ -MD -MP -MF $(DEPDIR)/$*.d

COMPILE.c = $(CC) $(DEPFLAGS) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c


$(OBJDIR)/%.o : %.c $(DEPDIR)/%.d | $(DEPDIR)
#	@mkdir -p $(dir $@) $(DEPDIR)/$(dir $<)

#	GM Fix - Couldn't fix it within Makefile
#	Windows doesn't have -p --parents -which is a flag  no error if existing, make parent directories as needed
#	$(dir names…) Extracts the directory-part of each file name in names.
#	mkdir $(dir $@) $(DEPDIR)/$(dir $<) --didn't work because of trailing /   :~0,-1% removes it
#      Windows hard code the creation of these two folders
#	Can't figure how to drop the trailing / which crashed mkdir in windows so pass to a batch file makedir.bat	

	makedir $(dir $@)
	makedir $(DEPDIR)/$(dir $<)
	
	
	$(COMPILE.c) $(OUTPUT_OPTION) $< 
	
#$(DEPDIR): ; @mkdir -p $@
$(DEPDIR): ; makedir $@

DEPFILES := $(SOURCES:%.c=$(DEPDIR)/%.d)
$(DEPFILES):

include $(wildcard $(DEPFILES))

I'd like to highlight where I changed things, though I have written comments.

However, the big thing is that you will also need a small batch file that I use to create folders:
This replaces the nice simple one liner near the bottom:
$(OBJDIR)/%.o : %.c $(DEPDIR)/%.d | $(DEPDIR)
# @mkdir -p $(dir $@) $(DEPDIR)/$(dir $<)

I still haven't figured out how this works because it was written by an alien with a gigantic brain. It creates different folders depending on ???? but basically the _build and _dep folders.

By the way I changed the .dep to _dep because really a . file is hidden (at least in linux) and I also didn't like it as a name for a windows file - but change it back if you want.

So you need to create a batch file called makefile.bat

Code:
@echo off
REM This batch file is used with the Makefile as @mkdir -p $(dir $@) $(DEPDIR)/$(dir $<) won't work under windows
REM Gordon Moore 24 July 2021
set dn=%1

set dnl=%dn:~-1%
set dnx=%dn:~0,-1%

::remove any trailing /
if %dnl% == / set dn=%dnx%

::replace / with \ for subfolder creation in windows
set dn=%dn:/=\%
::@echo %dn%

if not exist %dn% mkdir %dn%

If you now do

make clean
make

within the same folder, it should (hopefully) build.

(Oh I commented out some flashing stuff in the Makefile, I suppose these should be re-instated for those who need debugging (openocd) etc rather than just flashing)

I have noted though that there is a very slight difference in the output from SIZE
Windows:
"Size:"
arm-none-eabi-size main.elf
text data bss dec hex filename
271248 5496 57916 334660 51b44 main.elf

Linux
Size:
arm-none-eabi-size main.elf
text data bss dec hex filename
271248 5492 57916 334656 51b40 main.elf

I don't know what the implications of this are.

I also need to compare the output of the bin files against the "master" file from mbrusa. When I attempted this the last time I got some differences which I haven't investigated.

In other words DO NOT FLASH this output until we are confident that all is well.

Now to try the actual shell scripts for the 850C with bootloader and convert them to windows batch files.

I wish I could make the output less verbose!!! Edit: Before anyone says it, I bet that's what some think about me :wink:

:D

Gordon
 
ben5763 said:
...
Then i noticed that ther is no "config shortcut key" in the menu of the sw102. Does it mean that some features of the 860c 20.1C.3 are not implemented for the SW102 ? I'm a bit lost :wink:

On the other side, everything works OK. I use the tsdz2 on a full suspended mtb, and the eMTB mode is really a must !! Thanks for all the work :thumb:

It's just that I loved this shortkey feature to enter the configuration menu 8)
Yes, not all features are present in SW102.
Unfortunately, every item added to the configuration menu increases the chances of blocking.
In the next version I will try to add the "Configuration short cut key".
I don't have a SW102 to try, so I keep my fingers crossed.
 
mbrusa said:
ben5763 said:
...
Then i noticed that ther is no "config shortcut key" in the menu of the sw102. Does it mean that some features of the 860c 20.1C.3 are not implemented for the SW102 ? I'm a bit lost :wink:

On the other side, everything works OK. I use the tsdz2 on a full suspended mtb, and the eMTB mode is really a must !! Thanks for all the work :thumb:

It's just that I loved this shortkey feature to enter the configuration menu 8)
Yes, not all features are present in SW102.
Unfortunately, every item added to the configuration menu increases the chances of blocking.
In the next version I will try to add the "Configuration short cut key".
I don't have a SW102 to try, so I keep my fingers crossed.

Thanks Mbrusa, but don't spend time on this if chances to block are higher.

What I see is that for real MTB, only a small factor display works (I broke my 860C screen so quickly, I even don't know how, maybe only hitting a tree branch, or vibrations during downhill...).

VLCD6 and XC18H are ok, but soo difficult to handle osf configuration :-(

SW102 is than the last option.

I dream of a "SW102 light" version which would not freeze, but without all what we don't use for mountain biking (lights, break sensor, temp sensor, coast break, street mode... and maybe others)

Maybe will try to have a look also on my side, but I'm not used to this type of programing. What is the best development tool to use whith your sources on Windows system ?
 
I've got great news for all the guys who noticed more heating in every version after 0.8.0 (inlcuding 1.1.0 ; 20.1c2 etc)
I've got new firmware from mbrusa - 20.1c3-NEW

I am so happy! you guys did it! :))
I repeated the heating test on same route same day in same conditions, my 4km test uphill ride. Both rides started with ambient temperature at the bottom.
I compared 0.20beta1 with lcd3 (which performed best up to this day) with 20.1c3-NEW 860c lcd.

0.20beta1 - temperature on the top - 62c
mbrusa new firmware - 55c
(old firmwares f.e. 1.1.0 ; 20.1c2 - 75c) : so 20 degrees C difference.

Ride was much smoother, and I felt even better assist. it is very good firmware!
info about my ride: cadence 75-80, battery 55v , pwm 90-100, power assist set on maximum level - limit 525w.
Thank you once again :) great work! Now I can finally ride with 860c.
For all you guys riding tsdz2 MTB in the mountains I recommend it.
Thank you for awesome work!
 
blazo said:
I've got great news ..... mbrusa - 20.1c3-NEW
..
I repeated the heating test on same route same day in same conditions, ....
I compared 0.20beta1 with lcd3 (which performed best up to this day) with 20.1c3-NEW 860c lcd.

0.20beta1 - temperature on the top - 62c
mbrusa new firmware - 55c
(old firmwares f.e. 1.1.0 ; 20.1c2 - 75c)...
.....
Nice to hear :thumb:
Some questions:
Tested with the same motor, but different display's?
Field Weakening enabled/disabled in configurations?
 
Elinx said:
Some questions:
Tested with the same motor, but different display's?
Field Weakening enabled/disabled in configurations?

yes, same bike(enduro), same motor(48v), I have same connector for both lcd's so I switch them fast, upload firmware for motor and repeat test ride ( of course after the motor cools down to ambient temperature)
I always keep the same conditions, and same route - steady uphill tarmac ride.
Field weakening was disabled to keep the same conditions on both firmwares. But now I will ride new firmware more so I will test FW too. :)
 
blazo said:
....same bike(enduro), same motor(48v), I have same connector for both lcd's so I switch them fast,.....
Field weakening was disabled ...
Thanks for the comparision.
I'm curious of the differences with temperature with and without FW and of course the effectiveness of it on the power at higher cadence.
 
Elinx said:
I'm curious of the differences with temperature with and without FW and of course the effectiveness of it on the power at higher cadence.
I just did test for you. Result with Field Weakening enabled is : 54c degrees on the top of the hill. almost the same when disabled(55). Also I haven't felt any noticeable difference in assist. Same cadence 75-80. Pwm 95-100.
 
blazo said:
I've got great news for all the guys who noticed more heating in every version after 0.8.0 (inlcuding 1.1.0 ; 20.1c2 etc)
I've got new firmware from mbrusa - 20.1c3-NEW

I am so happy! you guys did it! :))
I repeated the heating test on same route same day in same conditions, my 4km test uphill ride. Both rides started with ambient temperature at the bottom.
I compared 0.20beta1 with lcd3 (which performed best up to this day) with 20.1c3-NEW 860c lcd.

0.20beta1 - temperature on the top - 62c
mbrusa new firmware - 55c
(old firmwares f.e. 1.1.0 ; 20.1c2 - 75c) : so 20 degrees C difference.

Ride was much smoother, and I felt even better assist. it is very good firmware!

info about my ride: cadence 75-80, battery 55v , pwm 90-100, power assist set on maximum level - limit 525w.
Thank you once again :) great work! Now I can finally ride with 860c.
For all you guys riding tsdz2 MTB in the mountains I recommend it.
Thank you for awesome work!

Thanks for testing and posting your results!
I agree with your results and just haven't had time to post my opinion about the latest version, it is great!
The 860C is by far the best display, it is so easy to see in all lighting conditions and much easier to set up and change the settings. And I am grateful for everyone's efforts from starting this effort to the latest efforts from mbrusa!
 
blazo said:
.....Result with Field Weakening enabled is : 54c degrees on the top of the hill. almost the same when disabled(55). .....Same cadence...
That is great, meaning FW doesn't have impact on the temperature with lower cadences.
How effective FW is, imho you only can feel with really high cadences,
 
Hello, I purchased an SW102 from Electrify Bike that is said to work with TSDZ2. My understanding is that other people have gotten this firmware to work with it out of the box.

My question is, which fork should I use for this, the VLCD5, VLCD6, XH18 version? Or the 850C, 860C, SW102 version?

If the former, which display do I select in the Java Configurator? My attempts so far have all resulted in error 30 on the display after ~30 seconds.

Wondering if it is also possible that this display is not set up with the TSDZ2 specific communication protocol, or if it could just be busted / DOA. I know on other displays, error 30 is sometimes a permanent communication error. I am considering purchasing a SW102 from Eco Cycles that also claims to use TSDZ2 specific protocol

If anyone has any insight they could share on this, I would appreciate the help.
 
blazo said:
...
0.20beta1 - temperature on the top - 62c
mbrusa new firmware - 55c
(old firmwares f.e. 1.1.0 ; 20.1c2 - 75c) : so 20 degrees C difference.
...
Well blazo, we needed a confirmation, thanks.
In my test laps between v20.1C and v20.1C.3 I had found a temperature difference of about 7/10 ° C, but with PWM 80% and I rarely reach high power.
I remember that FW does not activate at a predefined cadence, but when the PWM is at 100%.
 
ben5763 said:
Thanks Mbrusa, but don't spend time on this if chances to block are higher.

What I see is that for real MTB, only a small factor display works (I broke my 860C screen so quickly, I even don't know how, maybe only hitting a tree branch, or vibrations during downhill...).

VLCD6 and XC18H are ok, but soo difficult to handle osf configuration :-(

SW102 is than the last option.

I dream of a "SW102 light" version which would not freeze, but without all what we don't use for mountain biking (lights, break sensor, temp sensor, coast break, street mode... and maybe others)

Maybe will try to have a look also on my side, but I'm not used to this type of programing. What is the best development tool to use whith your sources on Windows system ?
The idea of a light version for SW102 is interesting
Many features could be enabled by default without the possibility of disabling them (example "config shortcut key").
It is thus possible to eliminate some items of the configuration menu without sacrificing features.
The configuration menu structure is in the configscreen.c file and the default settings in the eeprom.h file, an advanced text editor such as Notepad ++ is enough for a change of this type.
However, you need a virtual machine with ubuntu installed and the necessary software to compile.
 
mbrusa said:
However, you need a virtual machine with ubuntu installed and the necessary software to compile.

I am using pure windows 10 and I can compile ok now - at least for motor and 850C, see post above for changes to Makefile? Not that I've tested it yet on my motor or display.

Or am I missing something :)
 
Back
Top