• Hello ES! We could use some help to get us past the finish line on building the new knowledgebase for the forum.
    Can you donate? Please see our fundraising page. Thank you!

TSDZ8 OSF (open source firmware)

Hello, I would like to test this firmware: OSF_TSDZ8_860C_SPIDER_3_V00_02.04_other_compilation.hex.
I have always found the Katana variant to offer a better riding feel, and I need a version that features the "double assist" function for very steep climbs—similar to what I have on my current Katana version.
What are the advantages of the OSF_TSDZ8_860C_SPIDER_3_V00_02.04_other_compilation.hex version?
Best regards
 
Hello, is there any feedback yet regarding the performance and efficiency of the OSF_TSDZ8_860C_SPIDER_3_V00_02.04_other_compilation.hex?

Does the OSF_TSDZ8_860C_SPIDER_3_V00_02.04_other_compilation.hex offer any advantages over the OSF_TSDZ8_860C_KATANA_2_V00_01.35.hex?
 
... Does the OSF_TSDZ8_860C_SPIDER_3_V00_02.04_other_compilation.hex offer any advantages over the OSF_TSDZ8_860C_KATANA_2_V00_01.35.hex?
quoting from mstrens:
... Still In previous version, it was possible to specify the foc multiplier from the display reusing a field named coast brake threshold. This version does not use anymore the foc multiplier because the best lead angle should be calculated automatically. ...
 
I manually measured my torque sensor with weights while stationary to calculate the exact value for the Torque adc step parameter. Since I have data points for both 25 kg and 50 kg, I calculated both variants. During this process, I noticed that the exact placement of parentheses in the formula leads to massive differences depending on how it is entered into a standard calculator line.

Here are my calibration values measured from the bike:

  • ADC Offset / Base (ADC_min_360): 197
  • Max ADC Value at 80 kg (ADC_max_weight): 410
  • Max ADC Offset (ADC_max_360): 202
  • Safety Margin (Margin): 10
My specific weight measurement values:

  • 25 kg Base: ADC value at 25 kg = 272
  • 50 kg Base: ADC value at 50 kg = 392

The Mathematical Formula (expressed with double parentheses for single-line text input):​

Torque ADC step = (Weight * 167) / (((ADC_test - ADC_min_360 - Margin) * 160) / (ADC_max_weight - ADC_max_360 - Margin))

Calculation 1: Based on 25 kg​

  • Numerator: 25 * 167 = 4175
  • Left Parenthesis (ADC delta): 272 - 197 - 10 = 65
  • Right Parenthesis (Max Range): 410 - 202 - 10 = 198
Using the correct double-parentheses logic to keep the entire block in the denominator:4175 / ((65 * 160) / 198) = 79.48

Result for 25 kg: approx. 79 (or rounded 80).

Calculation 2: Based on 50 kg​

  • Numerator: 50 * 167 = 8350
  • Left Parenthesis (ADC delta): 392 - 197 - 10 = 185
  • Right Parenthesis (Max Range): 410 - 202 - 10 = 198
Using the exact same logic:8350 / ((185 * 160) / 198) = 55.85

Result for 50 kg: approx. 55 (or rounded 56).

(Note: If one mistakenly types the formula strictly from left to right without enclosing the entire denominator block in double parentheses—i.e., 8350 / 185 * 160 / 198—the calculator outputs 36.46, which seems to be a common parenthesis pitfall).

My questions and suggestions for the forum:​

1. Formula VerificationAre my two calculations (79/80 for the 25 kg base and 55/56 for the 50 kg base) mathematically correct and properly aligned with how the firmware source code handles the formula internally?

2. Torque Sensor Saturation Comparison (TSDZ2 vs. TSDZ8)I want to clarify a critical hardware difference regarding sensor saturation. On the older TSDZ2, the torque sensor was much softer and typically reached complete saturation at around 25 kg to 30 kg, flattening out heavily after that point. However, my measurements on the new TSDZ8 sensor show that it is mechanically much stiffer and remains highly responsive up to 50 kg (jumping from ADC 272 at 25 kg all the way up to ADC 392 at 50 kg).

Because the TSDZ8 sensor stays linear for so much longer, configuring the Torque ADC step using the 50 kg calibration data (value 55) should technically cover the entire main riding range much more accurately than scaling from a 25 kg data point. What is your view on this regarding the TSDZ8 hardware?

3. Feature Suggestion: Implementing a Knee-Point / Piecewise Linear InterpolationSince the firmware code currently calculates the human power using a single linear multiplier, we always have to compromise—either calibrating for perfect accuracy at the low end or at the high end.

Would it be possible to modify the OSF code to allow entering a specific "knee-point" or knee-weight where saturation begins (e.g., setting an offset, a 50 kg linear target, and an 80 kg saturation endpoint)?

Alternatively, could we implement a basic piecewise linear interpolation (a small lookup table with 3 or 4 calibration points)? This would allow the microcontroller to calculate the power using smaller, dedicated linear segments. It would make the human power (watt) display and the motor assistance 100% accurate across the entire weight range without requiring heavy floating-point mathematics that overload the processor. How difficult would it be to implement this in a future update?

Thank you very much for your help and insights!
 
Last edited:
Hi everyone,

While calibrating my TSDZ8 torque sensor, I noticed a significant physical limit (sensor saturation) at higher loads:

  • 0 to 50 kg: Very linear behavior, moving 183 ADC steps (from ADC 209 up to 392).
  • 50 to 80 kg: The sensor flattens out completely, moving only 24 ADC steps (from ADC 392 to 416).
If we calibrate the motor strictly linearly based on the 50 kg point, the firmware drastically underestimates human power during hard sprints. On the other hand, if we calibrate linearly up to 80 kg, the everyday resolution under 50 kg is completely ruined.

Important Note:​

Just a quick heads-up: I am not a programmer myself and have absolutely no coding experience. However, I wanted to find a solution for this issue, so I worked this out with the help of an AI assistant to translate my sensor curves into code. There might be syntax errors or logical bugs in it, so please treat this as a concept proposal from a passionate rider/tester rather than ready-to-merge code!

The Solution: A Dynamic Piecewise Linear Interpolation​

Instead of changing the display code or adding new communication protocols, we can implement a dual-slope logic purely inside the motor controller using the variables already sent by the display.

By utilizing ui16_adc_pedal_torque_offset_set (which holds the calibrated weight ADC, e.g., 392) and ui16_adc_pedal_torque_range, the motor can dynamically map the curve into two distinct sectors:

  1. Sector 1 (Under 50 kg): Uses the normal, honest linear slope (mapping 0–50 kg to 0–100 steps in the internal 160-step software window).
  2. Sector 2 (Over 50 kg): Automatically increases the slope (in my case, by 4.57x) for the remaining steps to perfectly compensate for the sensor saturation up to 80 kg.

Proposed Code Change for ebike_app.c​

Inside get_pedal_torque(void), we can replace the original linear mapping block with this fully dynamic fallback-safe version:

C

// ===================================================================================
// START: FULLY DYNAMIC & VARIABLE PIECEWISE LINEAR TORQUE CALIBRATION (KNEE-POINT)
// ===================================================================================
if (ui16_adc_pedal_torque > ui16_adc_pedal_torque_offset) {
uint16_t raw_delta = ui16_adc_pedal_torque - ui16_adc_pedal_torque_offset;

// Dynamically fetch the knee-point from the display calibration settings.
// ui16_adc_pedal_torque_offset_set holds the calibrated intermediary ADC value (e.g. 392)
uint16_t adc_knee_delta = 0;
if (ui16_adc_pedal_torque_offset_set > ui16_adc_pedal_torque_offset) {
adc_knee_delta = ui16_adc_pedal_torque_offset_set - ui16_adc_pedal_torque_offset;
}

// Safety Fallback: If no valid weight ADC is set, revert to original linear mapping
if (adc_knee_delta == 0 || adc_knee_delta >= ui16_adc_pedal_torque_range) {
ui16_adc_pedal_torque_delta_160 = ((uint32_t)raw_delta * ADC_TORQUE_SENSOR_RANGE_TARGET) / ui16_adc_pedal_torque_range;
}
else {
// SECTOR 1: Linear main range (From offset up to calibrated weight, e.g. 50 kg)
if (raw_delta <= adc_knee_delta) {
// Map the clean linear range to exactly 100 steps out of the 160 target window
ui16_adc_pedal_torque_delta_160 = (uint32_t)(raw_delta * 100) / adc_knee_delta;
}
// SECTOR 2: Saturation range (From calibrated weight up to max weight)
else {
uint16_t extra_delta = raw_delta - adc_knee_delta;
uint16_t total_range_delta = ui16_adc_pedal_torque_range;
uint16_t remaining_adc_range = total_range_delta - adc_knee_delta;

if (remaining_adc_range > 0) {
// Scale the flat saturation curve with a steeper slope dynamically
// to capture the remaining 60 steps up to the 160 target limit.
uint16_t extra_remapped = (uint32_t)(extra_delta * 60) / remaining_adc_range;
ui16_adc_pedal_torque_delta_160 = 100 + extra_remapped;
} else {
ui16_adc_pedal_torque_delta_160 = ADC_TORQUE_SENSOR_RANGE_TARGET;
}
}
}

// Hard ceiling safety check
if (ui16_adc_pedal_torque_delta_160 > ADC_TORQUE_SENSOR_RANGE_TARGET) {
ui16_adc_pedal_torque_delta_160 = ADC_TORQUE_SENSOR_RANGE_TARGET;
}
}
// ===================================================================================
// END: FULLY DYNAMIC & VARIABLE PIECEWISE LINEAR TORQUE CALIBRATION
// ===================================================================================

Why this benefits the community:​

  • Zero Display Code Changes: No need to update the 860C UI or the serial communication array.
  • 100% User-Adjustable: Other riders can use a different knee-point (e.g., 30 kg) simply by entering their specific data into the existing display calibration fields.
  • Backwards Compatible: If someone prefers a simple linear setup or skips the advanced calibration, the logic automatically defaults to the original linear formula.
What do you guys think about adding this to the official OSF branch? Would love to hear your thoughts and feedback!
 
Korrekte Anzeige von Human Power

Hallo zusammen,



ich habe mich intensiv mit dem Drehmomentsensor meines TSDZ8 beschäftigt. Viele kennen das Problem: Im Wiegetritt bringt man ordentlich Kraft auf das Pedal, aber der Sensor läuft in eine physikalische Sättigung. Die Firmware regelt dann ab, obwohl man eigentlich noch mehr Kraft einbringt.



Das Problem: Der ADC-Wert des Sensors flacht oberhalb eines Knickpunkts (bei mir ca. 397 ADC) stark ab. Der Motor "denkt" dann, man würde nicht fester treten.



Vorher: Im Wiegetritt stagnierte die vom Display angezeigte Eigenleistung ("Human Power") bei ca. 350–400 Watt, da der Sensor physikalisch an seine Grenze kam.

Nachher: Durch die Korrektur zeigt mir das Display nun eine tatsächliche Eigenleistung von bis zu ca. 640 Watt an, was meine physische Belastung im Wiegetritt bei 69 kg Körpergewicht endlich korrekt widerspiegelt. Die Frage ist: Erscheinen euch diese 640 Watt Human Power bei meinem Körpergewicht als plausibel, oder ist das für einen Hobbyfahrer schon das physikalische Limit?

Die Lösung: Ich habe den Test zweig von mstrens OSF_860C-test6_with_pll verwendet und mit Unterstützung durch die KI (Gemini) eine stückweise lineare Sättigungskorrektur in die ebike_app.c eingebaut. Der Algorithmus erkennt den Bereich, in dem der Sensor "taub" wird, und rechnet den Leistungsabfall dynamisch hoch.

Aktuell ist mein Knickpunkt 397 und der Faktor 2 noch fest im code verankert, ich würde gerne das der code die Werte aus dem Display übernimmt habe kenne aber die commands nicht.

torque adc on weight 397 (Knickpunkt)

torque adc step adv 2 (Faktor 2)



Hier der Code

// --- START: SÄTTIGUNGSKORREKTUR ali code ---

// Der Knickpunkt des Sensors liegt bei exakt 397 ADC.

// Die Korrektur greift nur oberhalb dieses Wertes.



#define ABSOLUTER_KNICKPUNKT 397



if (ui16_adc_pedal_torque > ABSOLUTER_KNICKPUNKT) {

// Boost-Logik: Faktor 2 für den Zuwachs über 397

uint32_t delta_zuwachs = (uint32_t)(ui16_adc_pedal_torque - ABSOLUTER_KNICKPUNKT) * 2000 / 1000;



ui16_adc_pedal_torque_delta += (uint16_t)delta_zuwachs;



// Sicherheitscap: Begrenzung auf das physikalische Sensor-Limit

if (ui16_adc_pedal_torque_delta > ADC_TORQUE_SENSOR_RANGE_TARGET) {

ui16_adc_pedal_torque_delta = ADC_TORQUE_SENSOR_RANGE_TARGET;

}

}

// --- ENDE: SÄTTIGUNGSKORREKTUR ---







Hier habe ich den code eingefügt

#else // (USE_SPIDER_LOGIC_FOR_TORQUE == (2))

// when ui8_TSamplesNum == 20, we can compare with previous sample and we use Texpected that has been calculated

// else, we use current value (remapped to 160) and filtered

if (ui8_TSamplesNum == 20){

ui16_adc_pedal_torque_filtered_noExpo = filter( ui16_TExpectedNew, ui16_adc_pedal_torque_filtered_noExpo, 4);

} else { // TSampleNum =0/19;

ui16_adc_pedal_torque_filtered_noExpo = filter( ui16_TorqueDeltaADC_norm , ui16_adc_pedal_torque_filtered_noExpo , 5);

}

#endif

ui16_adc_pedal_torque_delta = expo(

(int) ui16_adc_pedal_torque_filtered_noExpo ,

((int) ui8_adc_pedal_torque_range_adj - 20) * 12 ); // apply expo ; *12 because expo expect a value in range -256/+256



// here ui16_adc_pedal_torque_delta is known

ui16_adc_pedal_torque_delta_temp = ui16_adc_pedal_torque_delta;



// --- START: SÄTTIGUNGSKORREKTUR ali code ---

// Der Knickpunkt des Sensors liegt bei exakt 397 ADC.

// Die Korrektur greift nur oberhalb dieses Wertes.



#define ABSOLUTER_KNICKPUNKT 397



if (ui16_adc_pedal_torque > ABSOLUTER_KNICKPUNKT) {

// Boost-Logik: Faktor 2 für den Zuwachs über 397

uint32_t delta_zuwachs = (uint32_t)(ui16_adc_pedal_torque - ABSOLUTER_KNICKPUNKT) * 2000 / 1000;



ui16_adc_pedal_torque_delta += (uint16_t)delta_zuwachs;



// Sicherheitscap: Begrenzung auf das physikalische Sensor-Limit

if (ui16_adc_pedal_torque_delta > ADC_TORQUE_SENSOR_RANGE_TARGET) {

ui16_adc_pedal_torque_delta = ADC_TORQUE_SENSOR_RANGE_TARGET;

}

}

// --- ENDE: SÄTTIGUNGSKORREKTUR ---



// for cadence sensor check

ui16_adc_pedal_torque_delta_no_boost = ui16_adc_pedal_torque_delta;



// calculate torque on pedals

ui16_pedal_torque_x100 = ui16_adc_pedal_torque_delta * ui8_pedal_torque_per_10_bit_ADC_step_x100;



Hier habe ich den code eingefügt

if (ui16_adc_pedal_torque_delta_160 > ui16_adc_pedal_torque_noExpo) katana_dif = ui16_adc_pedal_torque_delta_160 - ui16_adc_pedal_torque_noExpo;

else katana_dif = ui16_adc_pedal_torque_noExpo - ui16_adc_pedal_torque_delta_160;

if (katana_dif < 60) katana_factor = 1;

else if (katana_dif < 80) katana_factor = 2;

else if (katana_dif < 100) katana_factor = 4;

else if (katana_dif < 130) katana_factor = 8;

while ( katana_factor){ // fill buffer one or several times

if ( katana_count == katana_buffer_len){ // when buffer is totally used, first remove oldiest value (but do not increase count)

katana_sum -= katana_buffer[katana_next_read];

katana_next_read++;

katana_next_read &= KATANA_MODULO;

} else { // when there is place in the buffer, increase count

katana_count++;

}

// add new value to sum and in the buffer

katana_sum += ui16_adc_pedal_torque_delta_160;

katana_buffer[katana_next_write] = ui16_adc_pedal_torque_delta_160 ;

katana_next_write++;

katana_next_write &= KATANA_MODULO;

katana_factor--;

}

if (katana_count > 0) {

ui16_adc_pedal_torque_delta_160 = katana_sum / katana_count ; // calculate average as final result

}

// check maximum : should not happen but added for safety.

if (ui16_adc_pedal_torque_delta_160 > ADC_TORQUE_SENSOR_RANGE_TARGET) ui16_adc_pedal_torque_delta_160 = ADC_TORQUE_SENSOR_RANGE_TARGET;

#endif

// save the value before applying expo in order to calculate variation in katana1234 logic on next loop (here above)

ui16_adc_pedal_torque_noExpo = ui16_adc_pedal_torque_delta_160 ;



// apply expo : value is in range 0/256 and so does not need to be remaped

// coeff expect a value in range-256/256 while range_adj is in range 0/40

// so we have to substract 20 and multiply by 12.

ui16_adc_pedal_torque_delta = expo(

(int) ui16_adc_pedal_torque_noExpo ,

((int) ui8_adc_pedal_torque_range_adj - 20) * 12 ); // apply expo ; *12 because expo expect a value in range -256/+256



// here ui16_adc_pedal_torque_delta is known

ui16_adc_pedal_torque_delta_temp = ui16_adc_pedal_torque_delta;



// --- START: SÄTTIGUNGSKORREKTUR ali code ---

// Der Knickpunkt des Sensors liegt bei exakt 397 ADC.

// Die Korrektur greift nur oberhalb dieses Wertes.



#define ABSOLUTER_KNICKPUNKT 397



if (ui16_adc_pedal_torque > ABSOLUTER_KNICKPUNKT) {

// Boost-Logik: Faktor 2 für den Zuwachs über 397

uint32_t delta_zuwachs = (uint32_t)(ui16_adc_pedal_torque - ABSOLUTER_KNICKPUNKT) * 2000 / 1000;



ui16_adc_pedal_torque_delta += (uint16_t)delta_zuwachs;



// Sicherheitscap: Begrenzung auf das physikalische Sensor-Limit

if (ui16_adc_pedal_torque_delta > ADC_TORQUE_SENSOR_RANGE_TARGET) {

ui16_adc_pedal_torque_delta = ADC_TORQUE_SENSOR_RANGE_TARGET;

}

}

// --- ENDE: SÄTTIGUNGSKORREKTUR ---



// for cadence sensor check

ui16_adc_pedal_torque_delta_no_boost = ui16_adc_pedal_torque_delta;



// calculate torque on pedals

ui16_pedal_torque_x100 = ui16_adc_pedal_torque_delta * ui8_pedal_torque_per_10_bit_ADC_step_x100;









Warum der Faktor 2?

Der Faktor 2 (bzw. 2000) ist kein Zufallswert. Ich habe diesen Koeffizienten gemeinsam mit Gemini direkt aus meiner erstellten Messtabelle ermittelt. Er gleicht den physikalischen Empfindlichkeitsverlust meines Sensors oberhalb des Knickpunkts aus. Die Formel berechnet, wie weit man im Sättigungsbereich ist, und verstärkt das Signal genau so stark, dass die Kennlinie wieder eine lineare Steigung aufweist.



Mein Setup (TSDZ8)

Torque ADC Offset: 209

Torque ADC Max: 450

Torque ADC on Weight (Knickpunkt): 397

Torque ADC Step: 71

Weight on pedal 53

Die Berechnung für meinen Step-Wert basiert auf dieser Formel:

ADC Step = (Weight on pedal * 167) / ((Knickpunkt - Offset) * 160 / (Max_ADC - Offset))

Eingesetzt: (53 * 167) / ((397 - 209) * 160 / (450 - 209)) ≈ 71



Fazit

Das Fahrgefühl ist nun deutlich direkter und das System liefert eine präzise Messung der Human Power über den gesamten Leistungsbereich.
 

Attachments

  • TSDZ8 Torquesensor-Kg neu (1).png
    TSDZ8 Torquesensor-Kg neu (1).png
    97.6 KB · Views: 6
Last edited:
The riding feel is now much more direct, and the system provides a precise measurement of "Human Power" across the entire power range.
That's nice! I assume this is what you have tested personally? Do you might have your code/updates published to any git repository with public access?
 
That's nice! I assume this is what you have tested personally? Do you might have your code/updates published to any git repository with public access?
hallo Ich habe kein eigenes Repository veröffentlicht. ich habe das projekt von mstrens verwendet und nur 2 code blöcke hinzugefügt/ geändert.
GitHub - mstrens/OSF_860C at test6_with_pll


OSF_TSDZ8_860C_SPIDER_3_V00_02.04_other_compilation.hex

ich werde noch weitere test mit einem besseren faktor machen und meinen post aktualisieren.
der aktuelle faktor ist rechnerisch noch zu klein aber trotzdem hat es schon eine Verbesserung gebracht.
wenn jemand Verbesserungs Vorschläge hat gerne her damit.
ich bin kein Programmierer habe das mit hilfe ki gemacht.


Hi, I haven't published a repository of my own. I used mstrens' project and only added or modified two code blocks.
GitHub - mstrens/OSF_860C at test6_with_pll


OSF_TSDZ8_860C_SPIDER_3_V00_02.04_other_compilation.hex

I’m going to run further tests using a better factor and update my post.
The current factor is still mathematically too low, but it has already resulted in an improvement.
If anyone has suggestions for improvement, please feel free to share them.
I’m not a programmer; I did this with the help of AI.
 
Debes ir al menú y luego a "moto" => cambiar la contraseña a "no". Esta es la razón por la que no podíamos cambiar los valores. El acelerador debe cambiarse a incondicional en el menú de la moto y en Temperatura del motor => Característica => Acelerador. Si no cambia la contraseña a "no", después de modificar los parámetros, estos se restablecerán a los valores predeterminados y los cambios no se guardarán.
Hola, he intentado seguir estas instrucciones pero la seguridad para cambiar los valores no se desbloquea.
 
I’m not a programmer; I did this with the help of AI.
If so, are you sure the AI builds the right hex file for you, including the updates you mentioned? Sorry if it feels like I'm underestimating your and the AI's skills, I just wanted to double-check. Anyway, thanks for tweaking this, let's hope we can get something useful for everyone. One day I thought it would be cool to show pedaling power and motor power as some kind of graphical gauge on the display. It would probably help to see how pedaling power/torque compares to the actual pedaling force, and whether at some point it feels like it doesn't rise anymore. One more thing that comes to mind when reading your posts is that the torque sensor most likely behaves a bit differently in different motors. That's probably why we don't have settings that work for everyone, and instead there are a few torque sensor configuration options you can change on the display. I hope you've checked all of them before working on this. Given that, it should be built in a flexible way so it has a chance to work well for all motors and rider weights. I haven't looked into this matter, but who knows, maybe my thoughts can help here, since we don't have any better feedback from other forum members so far anyway :)
 
If so, are you sure the AI builds the right hex file for you, including the updates you mentioned? Sorry if it feels like I'm underestimating your and the AI's skills, I just wanted to double-check. Anyway, thanks for tweaking this, let's hope we can get something useful for everyone. One day I thought it would be cool to show pedaling power and motor power as some kind of graphical gauge on the display. It would probably help to see how pedaling power/torque compares to the actual pedaling force, and whether at some point it feels like it doesn't rise anymore. One more thing that comes to mind when reading your posts is that the torque sensor most likely behaves a bit differently in different motors. That's probably why we don't have settings that work for everyone, and instead there are a few torque sensor configuration options you can change on the display. I hope you've checked all of them before working on this. Given that, it should be built in a flexible way so it has a chance to work well for all motors and rider weights. I haven't looked into this matter, but who knows, maybe my thoughts can help here, since we don't have any better feedback from other forum members so far anyway :)
hallo ich habe gestern festgestellt das der von mir veröffentlichte code leide nicht erst nach meinem knick bei 397 angewendet wurde, daher ist der code falsch.
ich habe scho einen neuen code den ich die Tage ausprobieren werde.
ich denke auch das der faktor 2 über meinem knickpunkt 397 besser passt.
die codes lasse ich von ki schreiben muss aber immer gut durch kucken was die ki mir da zusammen schreibt oft sind fehler enthalten die ich schon ohne programmier kenntnisse erkenne.
die hex compiliere ich selber das habe mittlerweile gelernt.
der gedanke das alle Parameter vom display einstellbar sind ist mir auch wichtig.
aktuell habe ich noch nicht herausgefunden was ich in den code schreiben muss das der knickpunkt von dem display wert *torque on weight* gelesen wird.
gut wäre noch wen der faktor 2 vom dem display wert torque adc step adv gelesen wird.



ich weis nicht ob alle tsdz8 motoren den knickpunk an der gleichen stelle habe.
es wäre hilfreich wenn noch mehr benutze eine test reihe erstellen die kg/adc werte zeigen.






EDIT:

Habe den neuen code getestet und er schein zu funktionieren und habe meinen post weiter oben angepasst.
 
Last edited:
Thank you all for your contributions to this OSF.

I have a Varstrom TSDZ8 with EKD01 display. I have just installed OSF_TSDZ8_VLCD_SPIDER_3_V00_02.04.hex.

I would like to configure street mode so that the speed is limited to 25km/h, power limited to 500W and throttle limited to 6km/h for our local laws. This looks fairly easy to achieve with the java configurator however I have noticed some issues. I would like to achieve maximum power in off-road mode as we have a track with a very steep hill next to our house.

1. The throttle does not obey any speed limits. Either when setting "Throttle Mode" to 6km/h or "Throttle on street mode" to 6km/h. It doesn't even obey the Max Speed Offroad Mode (km/h) speed limit or the display set speed limit. Is there a setting I have missed? Is this a known bug?

2. The EKD01 has a speed limit that can be varied by pressing power & plus and a speed that is preset in the information screen after entering a pass-code. These seem to be the only speeds that matter when pedaling even when "Set max speed from display" is off or on. Does this still activate offroad mode and street mode?

3. When I set Motor Power Max to 500W and pedal up our steep hill, the power shown on the display is a constant 460W and doesn't seem to go higher, with or without throttle. Is there a reason it doesn't get to 500? I have a 48V battery and Battery Current Max is set to 16A.

Any help would be appreciated.
 
Thank you all for your contributions to this OSF.

I have a Varstrom TSDZ8 with EKD01 display. I have just installed OSF_TSDZ8_VLCD_SPIDER_3_V00_02.04.hex.

I would like to configure street mode so that the speed is limited to 25km/h, power limited to 500W and throttle limited to 6km/h for our local laws. This looks fairly easy to achieve with the java configurator however I have noticed some issues. I would like to achieve maximum power in off-road mode as we have a track with a very steep hill next to our house.

1. The throttle does not obey any speed limits. Either when setting "Throttle Mode" to 6km/h or "Throttle on street mode" to 6km/h. It doesn't even obey the Max Speed Offroad Mode (km/h) speed limit or the display set speed limit. Is there a setting I have missed? Is this a known bug?

2. The EKD01 has a speed limit that can be varied by pressing power & plus and a speed that is preset in the information screen after entering a pass-code. These seem to be the only speeds that matter when pedaling even when "Set max speed from display" is off or on. Does this still activate offroad mode and street mode?

3. When I set Motor Power Max to 500W and pedal up our steep hill, the power shown on the display is a constant 460W and doesn't seem to go higher, with or without throttle. Is there a reason it doesn't get to 500? I have a 48V battery and Battery Current Max is set to 16A.

Any help would be appreciated.
About point 1, I checked the code. It seems that setting Throttle mode on 6km/h stops the assistance when speed exceed 6km/h but only when you are not pedaling. So if cadence is > 0, the assistance calculated based on throttle apply even when speed is more than 6km/h.
 
About point 1, I checked the code. It seems that setting Throttle mode on 6km/h stops the assistance when speed exceed 6km/h but only when you are not pedaling. So if cadence is > 0, the assistance calculated based on throttle apply even when speed is more than 6km/h.
Okay thanks.

I am testing this by just lifting the rear wheel up and activating the throttle. I noticed the pedals were turning slightly. I held the pedals from moving and repeated the test and the speed still went to maximum speed. I am using hybrid mode and the throttle also only works in pas 2 and above.
 
Okay thanks.

I am testing this by just lifting the rear wheel up and activating the throttle. I noticed the pedals were turning slightly. I held the pedals from moving and repeated the test and the speed still went to maximum speed. I am using hybrid mode and the throttle also only works in pas 2 and above.
You are right. I just noticed that Java configurator has 2 different options for speed limit with thottle. One is without pedaling and the other does not take care of the cadence. I expect you are using the second one that is not managed in the same way. In the basic settings of java configurator, there is an option "Set max speed from display". What is your choise for this box? It could be that when you enabled it, then the limit of 6 km/h with throttle is discarded. Could you check once when Set max speed from display is disabled
 
You are right. I just noticed that Java configurator has 2 different options for speed limit with thottle. One is without pedaling and the other does not take care of the cadence. I expect you are using the second one that is not managed in the same way. In the basic settings of java configurator, there is an option "Set max speed from display". What is your choise for this box? It could be that when you enabled it, then the limit of 6 km/h with throttle is discarded. Could you check once when Set max speed from display is disabled
I have throttle set to just "6km/h" not "6km/h and pedalling". Set max speed from display is unticked. I tried with it ticked and it didn't seem to make a difference. Either way the max speed limit while pedalling is set from the display and no speed limit is set for the throttle whether pedalling or not.
 
Back
Top