New "TSDZ2 Torque Sensor Central Motor"
- Thread starter larsottar
- Start date
BeachRider2016 said:
(Other) bafang motors use a microcontroller for which there is no cheap programmer and development tools available - that's why there is so little customization / firmware / mods for them. I'd imagine the ultra is similar (?) - IIRC it's mostly based on the BBSHD with just a different housing.
one of the reasons the TSDZ2 has so good custom firmware because the microcontroller in it is an STM32 - which is well supported by low-cost hobbyist dev tools.
It's the same reason why the stock LCD that comes with the tsdz2 isn't really used together with the custom firmware, since that too is based on a non-programmable (for us) microcontroller. (the bafang LCD's use STM32 or nrf52, which is why they were used for tsdz2 custom firmware)
I've got a strange problem I can't figure out. My 850C display went out on me and so I updated to an 860C. At the same time, I went from 1.00 to 1.10 on the opensource software. I have a 29 bike with larger tires and setting the circumference to 2410 had me sync'd with my GPS perfectly with the 850C. I put that same number in under the 860C / 1.10 setup and I'm constantly showing about 85% of actual distance no matter what I put in for wheel circumference. I moved it to 2800 since that was what it calculated out to, but was still off by the exact same percentage as when I had it at 2410. I looked in the source and saw 2100 is the default which calcs out to about what I'm seeing (2100/2410 = .87). It looks like it is not using the number in the UI and always using the default. Also dug through the source for both 1.00 and 1.10 and saw nothing that would appear to cause that. The trip stuff is in 1.10, but it doesn't look like it handles retrieval of the settings from the eeprom or the moving of the wheel_perimeter value any differently than 1.00. If no one has any suggestions, I'm going to revert to 1.00 and see if that resolves it (in case I missed something). Going to blame the 860C if that doesn't change anything. FYI: I've been running on various renditions for the last 8,000 km and it just works - good stuff.
Hi there,
today i got "error 3 torque"....
i can imagine it has to do with bad weather yesterday...maybe some humidity got somewhere and damaged something...who knows...
display/engine start normal but as soon as pressure on the pedal increases a bit, support stops and i get this error code.
is there a way of checking this without changing the torque sensor right away....
:? what would you suggest to do before starting to disassemble everything.... 
I want to add two observations: when i press the walk assist button, i will get this error 3 torque fault message also. so i do not even need to ride the bike to get it. it also "works" when standing.
and: when i go in menu "technical" i do get changing values of the torque when i step on the pedal...so something seems to still be working there...no idea....
so my assumption is: engine failure? meaning: it cannot create the necessary torque and thus the error message..
what do you think?
today i got "error 3 torque"....
i can imagine it has to do with bad weather yesterday...maybe some humidity got somewhere and damaged something...who knows...
display/engine start normal but as soon as pressure on the pedal increases a bit, support stops and i get this error code.
is there a way of checking this without changing the torque sensor right away....
:? what would you suggest to do before starting to disassemble everything.... I want to add two observations: when i press the walk assist button, i will get this error 3 torque fault message also. so i do not even need to ride the bike to get it. it also "works" when standing.
and: when i go in menu "technical" i do get changing values of the torque when i step on the pedal...so something seems to still be working there...no idea....
so my assumption is: engine failure? meaning: it cannot create the necessary torque and thus the error message..
what do you think?
I apologize for the following question:..
The actual motor has 3 thick wires blue, green and yellow.
Can the battery be connected to (which) 2 of these in order to see if the motor works or if it is broken? My intention would be to simply.make the motor run.b applying voltage directly to it to see if it is still.working at all.
Or is there another way of checking this out without proper installation?
Many thanks in advance
The actual motor has 3 thick wires blue, green and yellow.
Can the battery be connected to (which) 2 of these in order to see if the motor works or if it is broken? My intention would be to simply.make the motor run.b applying voltage directly to it to see if it is still.working at all.
Or is there another way of checking this out without proper installation?
Many thanks in advance
casainho said:
Did that, but it's been raining too much to check it out. Thought about just trying the 'Reset to Defaults' to and reconfiguring to see if that shook it loose. Going to try the version compiled with the new perimeter default first though.
LeftCoastNurd
100 W
- Joined
- Oct 22, 2019
- Messages
- 127
andyme said:
no, its a 3 phase servo motor, you need to apply 3 phases of AC to it to get it to spin. higher the frequency the faster it turns, the phases should be synchronized with the encoder outputs for it to spin smoothly.
andyme said:
I've understood that there's a mixup in the error codes and error 3 actually refers to hall signal error, which could be a fault in the sensors, their wiring or the controller. I assume you are using OSF, but which version?
In the Technical section in the menu you can see the hall signal. You can rotate very slow the bicycle wheel back backwards to see this value changing and it must always follow the next same sequence and values must be only the next ones: 4, 6, 2, 3, 1, 5.
The hall sensors are located on top of the motor, next to the three phase wires. Hall signal wires are the ones going to the 5-pin connector, here you can also check with a multimeter if you get consistent voltage readings between red/black wire and other colors, and these change according to the angle of the motor rotor.
Anyway, also double check all the wires going to the controller. If these are all good I'd think it's more probably a fault in the controller than in the motor, but you might have to get a spare one to be sure.
andyme said:
IIRC, when you spin the motor shaft by hand with all the wires disconnected as well as disconnected from each other, it should feel like it is "sitting" / or "plopping" into place in multiple points as you rotate it (the magnets attraction on the rotor is noticeable). If you then short the wires together, the motion as you turn it should feel completely smooth, i.e there is no more "magnetic" feeling as you turn it, and I think it feels stiffer to turn too. If you short just two wires together its something in between.
You can also test with a multimeter, to see if the readings between phases seem sensible, I believe all combinations of wires should show a similar resistance.
Don't apply DC, that may cause the magic smoke to escape and fry the motor. It's a brushless (not-really)-DC motor, which requires a controller to turn DC into synchronized three phases to make it turn.
mdumdei said:
I did some more looking into the code and saw the odometer calc was done like it was in 1.0.0 so checked the distance on the odometer vs. the trip meter. I found the odometer gave a correct value but the trip meter was short. I'm still working out the logic of the trip code, but I'm wondering if it isn't cutting off precision at these lines in "state.c" around line 517:
// update all trip distance variables
rt_vars.ui32_trip_a_distance_x1000 += (ui32_temp / 1000);
rt_vars.ui32_trip_b_distance_x1000 += (ui32_temp / 1000);
ui32_temp is wheel_ticks * perimeter. For a wheel that is close to a multiple of 1000 mm, the error wouldn't be much. For a wheel about out in the middle like mine at 2410, the error would be larger and more noticeable. 'wheel_ticks' in the new code is right above that and is:
// calculate how many revolutions since last reset ...
uint32_t wheel_ticks = rt_vars.ui32_wheel_speed_sensor_tick_counter
- ui32_wheel_speed_sensor_tick_counter_offset;
// ... and convert to distance traveled
uint32_t ui32_temp = wheel_ticks * ((uint32_t) rt_vars.ui16_wheel_perimeter);
Looks unscaled to me at first glance and running integer math on it is going to drop trailing digits. The flaw in that logic is I see the var is named 'x1000' which would indicate it is scaled. Posting this in case someone has some insight and could save me some time. I'm going to attempt to resolve it myself, but not being familiar with the code, it may take a while. I "think" something is wrong though since on my bike the trip meter runs about 85% of the distance shown on the odometer. Anyone else seeing a discrepancy between the trip meters and the change in odometer value?
I think that was it. I fixed it with 3 lines of code. The beginning of state.c now looks like this in my rev (changes are bold faced). My odometer and trip now both match after applying the updated code:
static void rt_calc_trips(void) {
static uint8_t ui8_1s_timer_counter = 0;
static uint8_t ui8_3s_timer_counter = 0;
static uint32_t ui32_wheel_speed_sensor_tick_counter_offset = 0;
static uint32_t ui32_remainder = 0;
// used to determine if trip avg speed values have to be calculated :
// - on first time this function is called ; so set by dfault to 1
// - then every 1 meter traveled
static uint8_t ui8_calc_avg_speed_flag = 1;
// calculate how many revolutions since last reset ...
uint32_t wheel_ticks = rt_vars.ui32_wheel_speed_sensor_tick_counter
- ui32_wheel_speed_sensor_tick_counter_offset;
// ... and convert to distance traveled
uint32_t ui32_temp = wheel_ticks * ((uint32_t) rt_vars.ui16_wheel_perimeter) + ui32_remainder;
// if traveled distance is more than 1 wheel turn update trip variables and reset
if (wheel_ticks >= 1) {
ui8_calc_avg_speed_flag = 1;
// update all trip distance variables
rt_vars.ui32_trip_a_distance_x1000 += (ui32_temp / 1000);
rt_vars.ui32_trip_b_distance_x1000 += (ui32_temp / 1000);
ui32_remainder = ui32_temp % 1000;
static void rt_calc_trips(void) {
static uint8_t ui8_1s_timer_counter = 0;
static uint8_t ui8_3s_timer_counter = 0;
static uint32_t ui32_wheel_speed_sensor_tick_counter_offset = 0;
static uint32_t ui32_remainder = 0;
// used to determine if trip avg speed values have to be calculated :
// - on first time this function is called ; so set by dfault to 1
// - then every 1 meter traveled
static uint8_t ui8_calc_avg_speed_flag = 1;
// calculate how many revolutions since last reset ...
uint32_t wheel_ticks = rt_vars.ui32_wheel_speed_sensor_tick_counter
- ui32_wheel_speed_sensor_tick_counter_offset;
// ... and convert to distance traveled
uint32_t ui32_temp = wheel_ticks * ((uint32_t) rt_vars.ui16_wheel_perimeter) + ui32_remainder;
// if traveled distance is more than 1 wheel turn update trip variables and reset
if (wheel_ticks >= 1) {
ui8_calc_avg_speed_flag = 1;
// update all trip distance variables
rt_vars.ui32_trip_a_distance_x1000 += (ui32_temp / 1000);
rt_vars.ui32_trip_b_distance_x1000 += (ui32_temp / 1000);
ui32_remainder = ui32_temp % 1000;
One last comment and I will stop cluttering the channel. I saw calc_odometer was discarding some turns of the wheel too and made a change to hang on to those also:
static void rt_calc_odometer(void) {
static uint8_t ui8_1s_timer_counter;
static uint32_t ui32_remainder = 0;
uint8_t ui8_01km_flag = 0;
// calc at 1s rate
if (++ui8_1s_timer_counter >= 10) {
ui8_1s_timer_counter = 0;
// calculate how many revolutions since last reset and convert to distance traveled
uint32_t ui32_temp = (rt_vars.ui32_wheel_speed_sensor_tick_counter
- rt_vars.ui32_wheel_speed_sensor_tick_counter_offset)
* ((uint32_t) rt_vars.ui16_wheel_perimeter) + ui32_remainder;
// if traveled distance is more than 100 meters update all distance variables and reset
if (ui32_temp >= 100000) { // 100000 -> 100000 mm -> 0.1 km
// update all distance variables
// ui_vars.ui16_distance_since_power_on_x10 += 1;
rt_vars.ui32_odometer_x10 += 1;
ui8_01km_flag = 1;
ui32_remainder = ui32_temp - 100000;
// reset the always incrementing value (up to motor controller power reset) by setting the offset to current value
rt_vars.ui32_wheel_speed_sensor_tick_counter_offset =
rt_vars.ui32_wheel_speed_sensor_tick_counter;
}
}
static void rt_calc_odometer(void) {
static uint8_t ui8_1s_timer_counter;
static uint32_t ui32_remainder = 0;
uint8_t ui8_01km_flag = 0;
// calc at 1s rate
if (++ui8_1s_timer_counter >= 10) {
ui8_1s_timer_counter = 0;
// calculate how many revolutions since last reset and convert to distance traveled
uint32_t ui32_temp = (rt_vars.ui32_wheel_speed_sensor_tick_counter
- rt_vars.ui32_wheel_speed_sensor_tick_counter_offset)
* ((uint32_t) rt_vars.ui16_wheel_perimeter) + ui32_remainder;
// if traveled distance is more than 100 meters update all distance variables and reset
if (ui32_temp >= 100000) { // 100000 -> 100000 mm -> 0.1 km
// update all distance variables
// ui_vars.ui16_distance_since_power_on_x10 += 1;
rt_vars.ui32_odometer_x10 += 1;
ui8_01km_flag = 1;
ui32_remainder = ui32_temp - 100000;
// reset the always incrementing value (up to motor controller power reset) by setting the offset to current value
rt_vars.ui32_wheel_speed_sensor_tick_counter_offset =
rt_vars.ui32_wheel_speed_sensor_tick_counter;
}
}
feketehegyi
100 W
- Joined
- Jul 11, 2018
- Messages
- 117
From my side I can tell you that I really enjoyed your posts. Thank you!mdumdei said:
I forked the main branch, did the edits to state.c and a pull request. Pretty naive on github protocols so let me know if it didn't come through as expected. I may have done a pull against my own fork and it not be something that shows up where you can see it. I need to get up to speed on all that. I did a good test today and after getting my wheel perimeter set right, it was dead-on for both the trip meter and the odometer. I had to reduce my previous wheel circumference by 80 mm to get it matched up to my GPS which makes sense since it is no longer discarding any traveled mm. The new value is in line with the actual measured circumference of the wheel.casainho said:
LeftCoastNurd
100 W
- Joined
- Oct 22, 2019
- Messages
- 127
FijiBrad said:
I'm in the USA (California) and got mine from eco-ebikes.com, and am very happy with the setup and support. they are on the other coast, but stuff gets here usually in a few days, which is fine by me
if tong sheng has their own aliexpress store, I'd consider getting it there, but I have no experience with the vendors on there, its kind of a crapshoot. I'd be very leary of neverheardofem battery packs. I got a 'shark' pack with 14S4P samsung 35E cells from eco-ebikes. I probably should have found a 14S3P or even 14S2P as I doubt I'll ever run this pack out, its hours of fun with the TSDZ2, and my conversion is a 700c bike built to be reasonably light and fast.
imho, the tsdz2 *needs* the temp sensor if you're going to run any sort of power above minimal, especially if you want to spin up hills, and you need to watch it. I'm running the 1.1.0 firmware, on the 860C display and the tsdz2.
