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

ok!
I want to install an emergency cut off switch and temp into the brake harness. This allows me to keep my throttle.

How does the OSF use the 3 pin brake sensor?

Is this closing the circuit sending 5V through to the other side?

I was thinking to make a comparator circuit that doesn't release again till it turns 80c.


View attachment 368910

There is a simpler way that I've looked into, tested but have not installed yet.

In post #2,594 TSDZ2 OSF for all displays, VLCD5-VLCD6-XH18, LCD3, 860C-850C-SW102. I have a video showing pulling on the right side brake lever cuts out the motor (note brake cutout symbol appears in top/ middle of display), then a temperature switch temporarily wired to the other brake cutout input, when the wires are shorted on the temperature switch, also made the brake cutout symbol appear.
 
Great, less to go wrong. as these brake inputs are set as normally open (NO) otherwise you would always need brake sensors fitted, so any sensor wired in parallel across the input will activate the stop signal. If the input was set as normally closed (NC) the sensors would be wired in series.
 
here is a patch to modify max rampe RPM in cadence mode.
This is a powershell patch.
You choose up to 120 RPM for max (70 RPM fixed on mbrusa version)
need to put patch in src folder and execute it.



# Demande la nouvelle limite haute en RPM de pédalage (entre 45 et 120)
# Ask for the new high RPM limit (between 45 and 120)
$RPM_LIMIT = [int](Read-Host "Entrez la nouvelle limite haute de RPM de pédalage (entre 45 et 120) / Enter the new high RPM limit (between 45 and 120)")

# Vérifie que la valeur est dans la plage désirée
# Check that the value is within the required range
if ($RPM_LIMIT -lt 45 -or $RPM_LIMIT -gt 120) {
Write-Host "Erreur : La valeur doit être comprise entre 45 et 120 RPM. / Error: The value must be between 45 and 120 RPM."
exit
}

# Nom du fichier source à modifier
# Name of the source file to modify
$SOURCE_FILE = "ebike_app.c"

# Vérifie que le fichier existe
# Check that the file exists
if (!(Test-Path $SOURCE_FILE)) {
Write-Host "Erreur : Le fichier $SOURCE_FILE n'existe pas ! / Error: The file $SOURCE_FILE does not exist!"
exit
}

# Lecture du fichier sous forme d'un tableau de lignes
# Read the file as an array of lines
$lines = Get-Content $SOURCE_FILE

# Parcours de toutes les lignes du fichier
# Loop through all lines of the file
for ($i = 0; $i -lt $lines.Length; $i++) {

# Lorsque nous trouvons un appel à map_ui8 avec ui8_pedal_cadence_RPM,
# on part du principe que le bloc ressemble à :
# ui8_tmp = map_ui8(ui8_pedal_cadence_RPM,
# (uint8_t)20, // 20 rpm
# (uint8_t)80, // 70 rpm
# ... );
#
# When we find a call to map_ui8 with ui8_pedal_cadence_RPM,
# assume the block looks like:
# ui8_tmp = map_ui8(ui8_pedal_cadence_RPM,
# (uint8_t)20, // 20 rpm
# (uint8_t)80, // 70 rpm
# ... );
if ($lines[$i] -match "map_ui8\s*\(\s*ui8_pedal_cadence_RPM") {

$paramCount = 0

# Parcours des lignes suivantes de ce bloc
# Loop through the following lines of this block
for ($j = $i+1; $j -lt $lines.Length; $j++) {

# Détecte les lignes contenant une valeur sous la forme : (uint8_t)<nombre>, // <nombre> rpm
# Detect lines containing a value in the form: (uint8_t)<number>, // <number> rpm
if ($lines[$j] -match "^\s*\(uint8_t\)") {
$paramCount++

# Lorsque c'est la deuxième occurrence (la limite haute), on la remplace
# When it's the second occurrence (the high limit), replace it
if ($paramCount -eq 2) {

# Remplace la valeur numérique qui suit "(uint8_t)" par $RPM_LIMIT
# Replace the numeric value following "(uint8_t)" with $RPM_LIMIT
$lines[$j] = $lines[$j] -replace "\(uint8_t\)\s*\d+", "(uint8_t)$RPM_LIMIT"

# Remplace le commentaire indiquant l'ancienne valeur par le nouveau commentaire
# Replace the comment indicating the old value with the new comment
$lines[$j] = $lines[$j] -replace "//\s*\d+\s*rpm", "// $RPM_LIMIT rpm"

# Sortie du bloc après cette modification
# Exit the inner loop after updating this parameter
break
}
}

# Si on atteint la fin du bloc (exemple : une ligne se terminant par ");"),
# on sort également de la boucle
# If we reach the end of the block (e.g., a line ending with ");"), exit the loop as well
if ($lines[$j] -match "\);\s*$") {
break
}
}
}
}

# Réécriture du fichier avec les modifications
# Write the modified lines back to the source file
$lines | Set-Content $SOURCE_FILE

Write-Host "Patch appliqué ! La nouvelle limite haute de RPM est maintenant $RPM_LIMIT. / Patch applied! The new high RPM limit is now $RPM_LIMIT."
Pause
 

Attachments

  • patch Cadence mode RPM max.7z
    1.6 KB · Views: 3
Last edited:
  • Like
Reactions: dgc
zanatole, I have a headache looking at the patch, but very interested.
it modify this:

ui8_tmp = map_ui8(ui8_pedal_cadence_RPM,
(uint8_t)20, // 20 rpm <------------------------- end of boost begin of ramp, javaconfigurator can modify this
(uint8_t)80, // 70 rpm <--------------------- HERE is MAX RPM

2 occurence in code (increasing RPM and decreasing)

patch has to be in src folder

1) you shall change RPM before flashing
javaconfigurator dont change RPM max
so you can patch before using javaconfigurator (or use it, click compile&flash, abort flashing, patch and manually click compile&flash)


2) use javaconfigurator to set your parameters
then click compile &flash if you patched code before
 
Last edited:
Hey you Screwers :cool:
I have noticed sth. interersting in the TSDZ8 Thread in this forum: There is a guy who ported the mbrusa firmware for the TSDZ8. And, as I understand, says that the newer controllers for the TSDZ2 have the same chip as the TSDZ8. So the firmware should be flashable on the new controllers?! The hardware of the new controllers should have the faster chips as I have heard?
 
here is a patch to modify max rampe RPM in cadence mode.
This is a powershell patch.
You choose up to 120 RPM for max (70 RPM fixed on mbrusa version)
need to put patch in src folder and execute it.
...
But did you understand what the lines you changed are for?
I don't think so.
 
But did you understand what the lines you changed are for?
I don't think so.
I think it modify ramp for motor: low rpm more assistance high rpm less assistance. Software suppose if you are on high cadence you need less assistance. This way Electric consumption decrease.

I assume ramp isn't linear but the points are calculated from a beginning to an end.
I increase rpm of the end.

I suppose that increasing end rpm mean having less assistance on low cadence.
I presume ramp, far from linear has a maximum between min and max not far from max.

Those lines are more important on cadence mode because Software calculate assistance only on cadence. In fact all mode are influented but less than cadence.

In fact 80-90 rpm In cadence mode is better because motor efficiency is far better compared to 50 60 !

If high limit is 70 rpm motor deliver less power after 70. But motor is designed to run at 100 rpm (more efficient!)

Maintaining assistance to 90 rpm increase consumption on a way but decrease consumption too by working more efficiently.

My natural rpm is 70 -100... even when going to work....

Edit: ramp is linear ... not gaussian...

For information I'm ingenier formed in electromechanical...
 
Last edited:
Hi @mbrusa ;
finally I was able to test your new firmware-version (Firmware open source v20.1C.6-VLCD5-VLCD6-XH18)
It runs great, thanks again.

But I might have stumbled over a potential bug:
I use 'Auto Display Data with Lights on' and use 3 items to be shown when lights are switched on:
battery current (5 secs), motor temperature (2,5 secs) and consumed Wh (2,5 secs)
But sometimes (pretty often), the battery voltage is shown briefly instead the current, or sometimes it is shown additionally very briefly (less than a second) before the current.
Also, the consumed Wh shown were initially often '0', before they finally showed a number.

If you want to replicate this to trouble shoot, see my attached ini file (i am using xh-18 display).
All the best and thank you again for your work here!

P.S. This potential bug is not necessarily new, as I just with your new firmware added the 'consumed Wh', so I can not compare apples to apples with the prior firmware
 

Attachments

  • HOnewSensor_woCal_consWh_current.ini
    807 bytes · Views: 3
Hi @mbrusa ;
finally I was able to test your new firmware-version (Firmware open source v20.1C.6-VLCD5-VLCD6-XH18)
It runs great, thanks again.

But I might have stumbled over a potential bug:
I use 'Auto Display Data with Lights on' and use 3 items to be shown when lights are switched on:
battery current (5 secs), motor temperature (2,5 secs) and consumed Wh (2,5 secs)
But sometimes (pretty often), the battery voltage is shown briefly instead the current, or sometimes it is shown additionally very briefly (less than a second) before the current.
Also, the consumed Wh shown were initially often '0', before they finally showed a number.

If you want to replicate this to trouble shoot, see my attached ini file (i am using xh-18 display).
All the best and thank you again for your work here!

P.S. This potential bug is not necessarily new, as I just with your new firmware added the 'consumed Wh', so I can not compare apples to apples with the prior firmware
I tried the ini file, there is indeed a problem.
I think the cause is the same as a bug already reported, during the configuration of the parameters it enters an infinite loop.
It happens when "Time to menu items" is greater than "Time to displayed data", try to set all times to 50.
It will be fixed in the next version that I will release soon.
 
I think it modify ramp for motor: low rpm more assistance high rpm less assistance. Software suppose if you are on high cadence you need less assistance. This way Electric consumption decrease.

I assume ramp isn't linear but the points are calculated from a beginning to an end.
I increase rpm of the end.

I suppose that increasing end rpm mean having less assistance on low cadence.
I presume ramp, far from linear has a maximum between min and max not far from max.

Those lines are more important on cadence mode because Software calculate assistance only on cadence. In fact all mode are influented but less than cadence.

In fact 80-90 rpm In cadence mode is better because motor efficiency is far better compared to 50 60 !

If high limit is 70 rpm motor deliver less power after 70. But motor is designed to run at 100 rpm (more efficient!)

Maintaining assistance to 90 rpm increase consumption on a way but decrease consumption too by working more efficiently.

My natural rpm is 70 -100... even when going to work....

For information I'm ingenier formed in electromechanical...
You seem really convinced.
 
I tried the ini file, there is indeed a problem.
I think the cause is the same as a bug already reported, during the configuration of the parameters it enters an infinite loop.
It happens when "Time to menu items" is greater than "Time to displayed data", try to set all times to 50.
It will be fixed in the next version that I will release soon.
Thanks, @mbrusa!
I just flashed it (with everything set to 3 secs) and the data looks consistent now.
One thing I noticed during the power up sequence:
When I power on the display, I would expect - based on my ini file - to only see the Battery-voltage (Volts) during this system power up.
However, I get:
1) Volts
2) '0'
3) % SOC
during system power up.

And 1 unrelated question to your firmware:
I do not understand how to move between the lights mode:
I would like to be able to
- switch lights on and off
- switch to assist with sensor error mode, when needed
I looked at your manual, but still can not figure out how to switch 'assist with sensor error' on and off . (I have no break sensors)
 
You seem really convinced.
i presume yes i didnt read the line for ramp response to cadence... the fact is it's working so the problem i got is solved.

Do we have any idea of real efficiency of tsdz2b?

I search for test (TSDZ2b response characteristic in voltage, current, effort) but found nothing except 73% wo precision.

Legal street mode limit is 250W nominal a wheel ....
here the limit is 250 W nominal electric (wichmake sence since electric power >mechanic power)

It make big difference:
If we are close of 250W nominal at exit of motor we should be more close of 250W nominal at wheel ...
 
Last edited:
Here is a script to patch ebike_app.c in order to modify when assistance begin to decrease with speed:
WARNING: if you set 20% of speed max assistance decrease at 25*0.8=20 and end at 25*1.2=30km/h tho its illegal regard to european law on street (even in street mode)

if you dont want it dont write "+ margin" in script bellow!
ie
uint16_t speed_limit_high = target_speed + margin;
uint16_t speed_limit_high = target_speed

my problem was assistance in cadence mode decreasing near 23 24 i wanted to retard the decrease.

mbrusa code
defines a transition window around the configured maximum speed. For example, if the maximum is set to 25 km/h, the code calculates:

  • speed_limit_low = (25 – 2) × 10 = 230 (which corresponds to 23.0 km/h)
  • speed_limit_high = (25 + 2) × 10 = 270 (which corresponds to 27.0 km/h)
Here's what the code does in that range:

  1. Below 23 km/h: Full assistance is provided.
  2. Between 23 km/h and 27 km/h: The code uses a mapping function to progressively reduce the target battery current (and therefore the motor assistance) as the speed increases. This means that assistance ramps down gradually within this window.
  3. Above 27 km/h: The assistance is completely cut off.
This design creates a soft transition—ensuring that the motor assistance decreases smoothly rather than being abruptly cut at exactly 25 km/h to help accommodate transient speed variations and sensor noise.

In contrast, strict legal regulations for electric bicycles (often for comfort and safety reasons) may require assistance to stop exactly at 25 km/h. However, the original implementation intentionally uses a ±2 km/h margin, cutting off assistance completely only when the measured speed exceeds 27 km/h (for a configured 25 km/h maximum).

So, to answer your question: according to this code, the motor assistance does not cut off abruptly at 25 km/h—it instead begins to fade between 23 and 27 km/h in street mode.


What i do: i choose a % of max speed and assistance begin to fade at max speed-% to end at max speed+%


I choosed 2%: for me in legal mode assistance begin to fade at 24.5km/h and stop at 25.5 km/h.
legaly there's a small marge, not specified in norme but 2% should be ok.



here is patch code (powershell): apply&compile&flash




# Ask for the desired margin percentage (between 0 and 20)
$MARGIN_PERCENT = [int](Read-Host "Enter the desired margin percentage (between 0 and 20)")
if ($MARGIN_PERCENT -lt 0 -or $MARGIN_PERCENT -gt 20) {
Write-Host "Error: The margin must be between 0% and 20%."
exit
}

# Name of the source file to modify
$SOURCE_FILE = "ebike_app.c"

# Verify that the source file exists
if (!(Test-Path $SOURCE_FILE)) {
Write-Host "Error: The file $SOURCE_FILE does not exist!"
exit
}

# Read the source file as an array of lines
$lines = Get-Content $SOURCE_FILE

# Search for all lines containing speed limit related variables (original or already patched)
# We look for any lines with "speed_limit_low", "speed_limit_high", "target_speed", or "margin"
$indices = @()
for ($i = 0; $i -lt $lines.Length; $i++) {
if ($lines[$i] -match "uint16_t\s+(speed_limit_low|speed_limit_high|target_speed|margin)\s*=") {
$indices += $i
}
}

if ($indices.Count -eq 0) {
Write-Host "No occurrence of 'speed_limit_low', 'speed_limit_high', 'target_speed', or 'margin' was found in the file."
exit
}

# Assume that the block containing these definitions is grouped together.
# If the block spans more than 10 lines, abort modification to avoid misidentification.
$blockStart = ($indices | Measure-Object -Minimum).Minimum
$blockEnd = ($indices | Measure-Object -Maximum).Maximum
if (($blockEnd - $blockStart) -gt 10) {
Write-Host "The detected block seems too large ($($blockEnd - $blockStart + 1) lines). The script cannot reliably identify it."
exit
}

# Construct the new code block using the proportional margin approach.
# Here, the target speed (in deci-km/h) is computed and then the margin is given as:
# margin = target_speed * (MARGIN_PERCENT / 100)
# Finally, speed_limit_low and speed_limit_high are calculated accordingly.
$replacementBlock = @"
uint16_t target_speed = m_configuration_variables.ui8_wheel_speed_max * 10;
uint16_t margin = (uint16_t)(target_speed * $($MARGIN_PERCENT) / 100.0); // margin of $MARGIN_PERCENT%
uint16_t speed_limit_low = target_speed - margin;
uint16_t speed_limit_high = target_speed + margin;
// write this for strict high marge:
//uint16_t speed_limit_high = target_speed
"@

# Split the replacement block into lines
$newBlockLines = $replacementBlock.Trim().Split("`n")

# Replace the detected block (from blockStart to blockEnd) with the new block
if ($blockStart -gt 0) {
$before = $lines[0..($blockStart - 1)]
} else {
$before = @()
}

if ($blockEnd -lt ($lines.Length - 1)) {
$after = $lines[($blockEnd + 1)..($lines.Length - 1)]
} else {
$after = @()
}

$lines = $before + $newBlockLines + $after

# Write the modified content back to the source file
$lines | Set-Content $SOURCE_FILE

# Display success message
Write-Host "Patch applied successfully! The new speed margin of $MARGIN_PERCENT% has been set in $SOURCE_FILE."
Pause
 

Attachments

  • patch marge vitesse.7z
    1.4 KB · Views: 0
Last edited:
In theory, all displays with Tongsheng protocol should work with OSF, but not all displays respect the protocol 100%, some adaptation may be necessary.
To confirm that everything works correctly with SW-M58, someone has to try it.
mbrusa:

I finally got to try out display SW-M58 with a TSDZ2B motor and the v20.1C.6 firmware. I think I can safely say that the SW-M58 display functions correctly. I also have a EKD01 display and that works as well.

However, there are strange motor performance issues using either display suggesting there is something wrong in the firmware. The problem is that while riding the bike the perceived motor boost does not track the assist setting. For example:

Assist #1 and assist #5 both produce high boost with assist #5 slightly higher
Assist #2 and assist #3 both produce low boost but not zero.
Assist #4 produces moderate boost.

The progression of power seems to go 2,3,4,1,5 instead of the expected 1,2,3,4, 5. The ride experience is unpleasant, so I have since restored the firmware back to the factory files. Any comments?
 

Attachments

  • Screenshot 2025-04-27 175612.png
    Screenshot 2025-04-27 175612.png
    120.2 KB · Views: 8
  • Screenshot 2025-04-27 180433.png
    Screenshot 2025-04-27 180433.png
    97 KB · Views: 8
New Hybrid mode

Mbrusa coded an hybrid mode: best of torque and power is used to calculate assistance.

I found Emtb for mountain bike is the best mode.
Problem: i want torque based on low RPM and power based on high RPM

Replace hybrid mode of mbrusa with hybrid emtb torque / emtb power

Edit 4/05/25. Previous version buggy. Fixed it.

Code of ebike_app.c:

static void apply_hybrid_emtb_assist(void)
{
#define eMTB_ASSIST_DENOMINATOR_MIN 10 // Minimum denominator for eMTB assistance calculation

uint16_t ui16_adc_battery_current_target_emtb_torque)=0; // Calculated based on eMTB torque
uint16_t ui16_adc_battery_current_target_emtb_power=0; // Calculated based on eMTB power
uint16_t ui16_adc_battery_current_target=0; // Final target battery current

// Check for assistance without pedal rotation
if (m_configuration_variables.ui8_assist_without_pedal_rotation_enabled) {
if ((ui8_pedal_cadence_RPM == 0U) &&
(ui16_adc_pedal_torque_delta > (120 - ui8_assist_without_pedal_rotation_threshold))) {
ui8_pedal_cadence_RPM = 1; // Simulate cadence if required conditions are met
}
}

// Force assistance in case of errors
if (m_configuration_variables.ui8_assist_with_error_enabled) {
ui8_pedal_cadence_RPM = 1;
}

// Check if torque is applied OR if startup assistance is active
if (((ui16_adc_pedal_torque_delta) && (ui8_pedal_cadence_RPM > 0U))
|| (ui8_startup_assist_adc_battery_current_target)) {

// eMTB torque assistance calculation
uint16_t ui16_emtb_assist_denominator = (508 - (ui8_riding_mode_parameter << 1)) + eMTB_ASSIST_DENOMINATOR_MIN;

// Progressive calculation of pedal torque delta
uint16_t ui16_emtb_adc_pedal_torque_delta = (uint16_t)(
((uint32_t)(ui16_adc_pedal_torque_delta * ui16_adc_pedal_torque_delta) + ui16_emtb_assist_denominator)
/ ui16_emtb_assist_denominator
);

// Save eMTB torque calculation
ui16_adc_battery_current_target_emtb_torque = ui16_emtb_adc_pedal_torque_delta;

// eMTB power assistance calculation
uint16_t ui16_eMTB_assist_denominator = (508 - (ui8_riding_mode_parameter << 1)) + eMTB_ASSIST_DENOMINATOR_MIN;

// Adjust denominator based on cadence
if (ui16_eMTB_assist_denominator >= ui8_pedal_cadence_RPM) {
ui16_eMTB_assist_denominator -= ui8_pedal_cadence_RPM;
} else {
ui16_eMTB_assist_denominator = 0;
}

ui16_eMTB_assist_denominator += eMTB_ASSIST_DENOMINATOR_MIN;

// Progressive calculation for eMTB power assistance
uint16_t ui16_eMTB_adc_pedal_torque_delta = (uint16_t)(
((uint32_t)(ui16_adc_pedal_torque_delta * ui16_adc_pedal_torque_delta) + ui16_eMTB_assist_denominator)
/ ui16_eMTB_assist_denominator
);

// Save eMTB power calculation
ui16_adc_battery_current_target_emtb_power = ui16_eMTB_adc_pedal_torque_delta;

// Determine final assistance level (max of torque or power calculations)
ui16_adc_battery_current_target = (ui16_adc_battery_current_target_emtb_power > ui16_adc_battery_current_target_emtb_torque) ?
ui16_adc_battery_current_target_emtb_power : ui16_adc_battery_current_target_emtb_torque;

// Apply motor acceleration and deceleration control
set_motor_ramp();

// Set final battery current target within maximum limits
if (ui16_adc_battery_current_target > ui8_adc_battery_current_max) {
ui8_adc_battery_current_target = ui8_adc_battery_current_max;
} else {
ui8_adc_battery_current_target = (uint8_t)ui16_adc_battery_current_target;
}

#if STARTUP_ASSIST_ENABLED
// Manage startup assistance logic
if (ui8_startup_assist_flag) {
if (ui8_adc_battery_current_target > ui8_startup_assist_adc_battery_current_target) {
ui8_startup_assist_adc_battery_current_target = ui8_adc_battery_current_target;
}
ui8_adc_battery_current_target = ui8_startup_assist_adc_battery_current_target;
} else {
ui8_startup_assist_adc_battery_current_target = 0;
}
#endif

// Adjust duty cycle target based on battery current
ui8_duty_cycle_target = (ui8_adc_battery_current_target) ? PWM_DUTY_CYCLE_MAX : 0;
}
}

call it from hybrid

so to use emtb hybrid you have to run hybrid mode


If you want to patch ebike_app.c wo doing it yourself:
put patch in src folder and patch then compil&flash
you will drive hybrid eMTB torque/eMTB power!
 

Attachments

  • patch marge vitesse.7z
    1.4 KB · Views: 0
  • ebike_app.c
    128.4 KB · Views: 0
Last edited:
worse of bosch ...
Yes, but you should also take into account the price of the Bosch motor itself, its maintenance, and the price and availability of parts. If it is 3 times more expensive, is it 3 times better? No. It is 1.5-2 times better at most.
Another question - which Bosch mid-drive models can be easily installed on any bike without almost any problems?
 
Last edited:
Thanks, @mbrusa!
I just flashed it (with everything set to 3 secs) and the data looks consistent now.
One thing I noticed during the power up sequence:
When I power on the display, I would expect - based on my ini file - to only see the Battery-voltage (Volts) during this system power up.
However, I get:
1) Volts
2) '0'
3) % SOC
during system power up.

And 1 unrelated question to your firmware:
I do not understand how to move between the lights mode:
I would like to be able to
- switch lights on and off
- switch to assist with sensor error mode, when needed
I looked at your manual, but still can not figure out how to switch 'assist with sensor error' on and off . (I have no break sensors)
Hi @endlessolli.
When the display is turned on, the chosen data is displayed, in your case Volts, but if "Soc % calculation" is set to Auto and the actual Soc deviates more than +/- 15% from the stored ones, an automatic reset occurs and the new Soc value is also displayed.
Keep in mind that with flashing the Soc is set by default to 99.9, it is normal for there to be a reset at the first power-up.
At the next power-up, only Volts will be displayed.

In the event of a sensor failure, to force assistance, it is necessary to enable "Assist with error". To do this, "Set parameter" must be enabled (by default it is disabled).
To enable it, turn on the display and select level 0-OFF, turn the lights on and off, until E02 flashes.
Then, to enable "Assist with error", select level 4-TURBO, turn the lights on and off 3 times, until E04 flashes.
You will need to choose a assist mode that does not use the faulty sensor.
 
mbrusa:

I finally got to try out display SW-M58 with a TSDZ2B motor and the v20.1C.6 firmware. I think I can safely say that the SW-M58 display functions correctly. I also have a EKD01 display and that works as well.

However, there are strange motor performance issues using either display suggesting there is something wrong in the firmware. The problem is that while riding the bike the perceived motor boost does not track the assist setting. For example:

Assist #1 and assist #5 both produce high boost with assist #5 slightly higher
Assist #2 and assist #3 both produce low boost but not zero.
Assist #4 produces moderate boost.

The progression of power seems to go 2,3,4,1,5 instead of the expected 1,2,3,4, 5. The ride experience is unpleasant, so I have since restored the firmware back to the factory files. Any comments?
The first operation to do to obtain a well-distributed assistance on the various levels, is the calibration of the torque sensor.
Insert the values of “Pedal torque ADC offset” and “Pedal torque ADC max” in the configurator.
Enable "Calibrated", "Estimated" and "Torque sensor adv".

Regarding the order of the levels, probably SW-M58 and EKD01 are different.
The fifth level in the EKD01 display should be the last, so "Assist level 5 (%) should be set to "AFTER TURBO" and the % greater than 100 (default 130).
While the fifth level in the SW-M58 display could be the first, so "Assist level 5 (%) should be set to "BEFORE ECO" and the % less than 100 (default 60).
If you can try and give me confirmation, it would be of great help. Thanks.
 
Back
Top