TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)
- Thread starter casainho
- Start date
casainho said:
Hello,
Just uploaded the new version to the display. I used the one with the boot loader. After powering on the display, I see version 0.6.1 instead of the one mentioned in the post and in the name of the files. To be sure I uploaded the same file for a second time. Again version 0.6.1. With a motor disconnected after waiting a bit, I got an error related to the break instead of the expected ones for missing communication with the motor. I did not go further with updating the motor firmware and testing if it will work ...
Would you please kindly confirm if this is is just a wrong version number of the correct display firmware? Is it safe to use it or we should wait an update.
Thank you for your great development efforts and keeping us busy in this confinement times!
James Broadhurst
100 W
The version no is shown as 10 and there have been accidental mismatches in the past but I’m pretty certain this is the real deal.
casainho said:
Thank you very much for the fast response! I just wanted to be sure that this is the correct release. The motor firmware is upgraded already and I am ready for the test drive.
I discovered something else. When I prepared to enter the configuration data related to the wheel circumference, to my surprise it was already there. The same for the torque sensor configuration. Thank you very much for for the nice addition that saves time.
jeff.page.rides
100 W
- Joined
- Aug 13, 2019
- Messages
- 295
casainho & others,
I can't wait to put the 860C on my handcycle, I have an 860C and I am just waiting to see reports that it is safe and stable and doesn't have any overrun then I'll be installing it right away!
Thanks for supporting and using the 860C and for all your hard work!
I can't wait to put the 860C on my handcycle, I have an 860C and I am just waiting to see reports that it is safe and stable and doesn't have any overrun then I'll be installing it right away!
Thanks for supporting and using the 860C and for all your hard work!
jeff.page.rides said:
Well we have to wait a bit more for the overrun as Casainho told us that it is his second priority after releasing the stable version. More then that Mbrusa code is not directly portable to Casainho branch, motor.c implementations are quite different on those branches. But I'm sure it is easy for Casainho to implement similar thing in his own code.
I have ordered some spares to be able to play with the versions and the code without burning my battery and motor...
skestans
100 W
My display has a date stamp of 2019/09, it’s hard to imagine the internal battery running out so fast. My former cycling computer could last 3–4 years on a CR2032. The clock drift also seems to be a function of how long was the display powered on between uses: long usage and the clock doesn’t drift for longer. Simple power on and off, the clock can’t keep for more than a few hours. I have a hunch there is more to it than that, and I can’t open the display to check the battery because that would destroy it.casainho said:
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
I had a 850C on my bicycle always resetting the clock to 0h0 at startup. I measured the battery and was near 0 volts while on other unit was near 1.8 volts.skestans said:
If you bought the display and it has this issue, I would try to get a refund or warranty from the seller.
if it's a reset to 0:00 this is for sure the battery that is dead. If it's a drift it can be something else.skestans said:
It is possible that the RTC clock is done via internal oscillator the this microcontroller, and the temperature compensation does not work very well. however on the board there is an RTC quartz y2 that you can see on this image
https://postimg.cc/Kks77ty3
https://gd32mcu.21ic.com/data/documents/shujushouce/GD32F103xx_Datasheet_Rev2.6.pdf
@Casainho, do you use quartz for the RTC when the display is on standby? or is it the internal clock, I will look in the code myself but you might have the answer right away
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
Here the initialization code, note that it similar to the sample code for RTC, from this microcontroller manufacturer:vshitikov said:
https://github.com/OpenSource-EBike-firmware/Color_LCD/blob/master/firmware/860C_850C/src/rtc.c
Code:
void rtc_init()
{
NVIC_InitTypeDef NVIC_InitStructure;
uint16_t WaitForOscSource;
/*Enables the clock to Backup and power interface peripherals */
RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP | RCC_APB1Periph_PWR, ENABLE);
/* Configure one bit for preemption priority */
NVIC_InitStructure.NVIC_IRQChannel = RTC_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = RTC_INTERRUT_PRIORITY;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
/*Allow access to Backup Registers*/
PWR_BackupAccessCmd(ENABLE);
if(BKP_ReadBackupRegister(BKP_DR1) == CONFIGURATION_RESET)
{
/*Enables the clock to Backup and power interface peripherals */
RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP | RCC_APB1Periph_PWR,ENABLE);
/* Backup Domain Reset */
BKP_DeInit();
/*Enable 32.768 kHz external oscillator */
RCC_LSEConfig(RCC_LSE_ON);
for(WaitForOscSource = 0; WaitForOscSource < 5000; WaitForOscSource++) { }
RCC_RTCCLKConfig(RCC_RTCCLKSource_LSE);
/* RTC Enabled */
RCC_RTCCLKCmd(ENABLE);
RTC_WaitForLastTask();
/*Wait for RTC registers synchronisation */
RTC_WaitForSynchro();
RTC_WaitForLastTask();
/* Setting RTC Interrupts-Seconds interrupt enabled */
/* Enable the RTC Second */
RTC_ITConfig(RTC_IT_SEC , ENABLE);
/* Wait until last write operation on RTC registers has finished */
RTC_WaitForLastTask();
/* Set RTC prescaler: set RTC period to 1 sec */
RTC_SetPrescaler(32765); /* RTC period = RTCCLK/RTC_PR = (32.768 KHz)/(32767+1) */
/* Prescaler is set to 32766 instead of 32768 to compensate for
lower as well as higher frequencies*/
/* Wait until last write operation on RTC registers has finished */
RTC_WaitForLastTask();
// set default time to 0h0m0s
RTC_WaitForLastTask();
rtc_time_t rtc_time =
{
.ui8_hours = 0,
.ui8_minutes = 0
};
rtc_set_time(&rtc_time);
RTC_WaitForLastTask();
BKP_WriteBackupRegister(BKP_DR1, CONFIGURATION_DONE);
}
else
{
/* PWR and BKP clocks selection */
RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);
for(WaitForOscSource = 0; WaitForOscSource < 5000; WaitForOscSource++) { }
/* Wait until last write operation on RTC registers has finished */
RTC_WaitForLastTask();
/* Enable the RTC Second */
RTC_ITConfig(RTC_IT_SEC, ENABLE);
RTC_WaitForLastTask();
}
// reset counter if more than 1 day passed in power down/Low Power Mode
if((RTC_GetCounter() / SECONDS_IN_DAY) != 0)
{
RTC_WaitForLastTask();
RTC_SetCounter(RTC_GetCounter() % SECONDS_IN_DAY);
RTC_WaitForLastTask();
}
BKP_RTCOutputConfig(BKP_RTCOutputSource_None);
}casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
Jeff, you are in luck because other than the 860C, I am right now adding the code for detecting braking on the coast brake of TSDZ2. I did look at the code done by Buba and I am re using it.jeff.page.rides said:
Detect brake on coast brakes is easy, it is like a negative torque value on the torque sensor. Pedals torque sensor value is positive when when pedal forward and a negative value when we pedal backward. On TSDZ2 coast brake version is possible to detect this negative value but not on the regular version -- I am assuming this after looking at the code and comments Buba did, as also with all my current experience with the torque sensor, because I never tested a TSDZ2 coast brake version.
Here is the simple code to detect the braking on coast brakes:
Code:
#define COASTER_BRAKE_TORQUE_THRESHOLD 40
// check if coaster brake is engaged
if (UI16_ADC_10_BIT_TORQUE_SENSOR < (ui16_g_adc_torque_sensor_min_value - COASTER_BRAKE_TORQUE_THRESHOLD))
{
ui8_g_brakes_state = 1;
}jeff.page.rides
100 W
- Joined
- Aug 13, 2019
- Messages
- 295
casainho said:
WOW, Thanks!
When I was using version 19 it was scary to try to stop the motor. But when Buba made those changes to version 20 it wasn't perfect, but it definitely was an awesome improvement and wasn't scary anymore.
Please let me know when it's ready to go and we will give it a try. We also installed the overrun fix and it did seem to help make things just a little lighter to stop the motor to shift gears. I have a shift sensor that I'm going to install and that should make my shifting much easier I hope. To install a brake sensor on my bike would be a little more complicated.
Rydon and I have been putting version 20 with LCD3's on all the handcycles we do. When your firmware is ready and better then 20 we will start using 860C's on all the handcycles.
Thanks again,
Jeff
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
Here, the version 0.56.1 that works with current display firmware. This version has only the change to detect negative torque sensor value, on my bicycle I found no change at all.
Go to this link and click on save as, with mouse right click:
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/tree/coast_overrun/releases/0.56.1
For testing, I would activate the walk assist at level 1 and then pull the pedals backward...
Go to this link and click on save as, with mouse right click:
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/tree/coast_overrun/releases/0.56.1
For testing, I would activate the walk assist at level 1 and then pull the pedals backward...
bergerandfries
1 W
- Joined
- Mar 2, 2019
- Messages
- 60
Most excellent Tomcys! I want to add something that I haven't seen anywhere also to let folks know that they PROBABLY have swapped Tx/Rx in their bootloader build: The LEDs on the USB to UART board behavior:Tomcys said:ezrider1199 said:Hi,
I received a 850c from pswpower and am trying to flash it. I noticed it doesnt fit into my 4-1 cable because it came with a female end so i attempted to put on a new male connector (luckily had a spare). Cut it up and see that the colors are off and the pin positions dont match with what tsdz2 is expecting. So I tried to figure out and match up the pins according to this.
Here's where I am now
.
Currently I am able to plug an unflashed 850c to my controller and see it start up but I can't get it to flash... is there anything i can verify? I assume that because the 850c can startup that my wiring should be ok. The APT program doesn't show much in the way of errors. Thanks
Tsdz2 display --> 850c
Gnd, Black --> black
Batt V+, Red --> purple
Rx, Yellow --> white
Tx, Green --> green
5v, Blue --> orange
izeman said:
Hello everyone,
I too decided to embark on the trail of installing TSDZ2 on my bicycle as reading through the forum it felt like the right motor for my needs
Along the way I also decide to install open source firmware together with 850c display.
I'm currently in the process of trying to flash the firmware on 850C using bootloader and a DIY bootloader box as mentioned in TSDZ2_wiki. However i ran into some problems during the process and would like to ask for help
My situation:
I've connected the components for the DIY bootloader box using the guide provided in TSDZ2_wiki:
https://github.com/OpenSource-EBike-fir ... bootloader
After that, I've connected it to my PC and to my 850c display. All seems fine as before installing the firmware I've tried to power on the display it it starts up and shows all the data (current time, voltage (note: it displays 29.8V while being powered from my PC via bootloader box), km/h etc.).
So now I've identified my COM port (COM3), installed the required drivers, and opened the APT burn tools (v1.3) to start the flashing process.
Next up in the APT burn tools window I've selected my COM3 port, opened it, after that I've selected the firmware for 850c display and pushed he update firmware after which the program showed "waiting..." sign.
I've pushed my power button, but the display did not show anything, the flashing did not start and the message in the program kept repeating "waiting...". It seems I can not get the 850c display to flash.
What I've noticed in the program is that while it's waiting on the input from the display the numbers values near "Tx" (at the bottom of APT burn tools window) are constantly changing and increasing, while number near "Rx" stays at "0". Does this mean there is a problem with Rx connection?
I've followed the wire connection diagram in TSDZ2 wiki and the info on how to splice and connect the 5pin extension wire given by user ezrider1199 and later on user izeman in their posts. I've checked multiple times whether all the wires are connected correctly and it seems that everything is as show in the TZDZ2 wiki.
Does anyone else had the issue of display not flashing and has a solution to my situation?
P.S I've got my display from PSPOWER and it sayson the back of dispalay "850c tftgdv2.3clb60 xf2.0" and "V5.2 201909210119".
SOLUTION:
In my case i've tried switching Tx and Rx wires and flash again. To my surprise it worked! Yuppi!
This might no be the case to others, but I'll post my final wiring by colors that I have below:
My 5pin extension wires are connected as follows:
(I've identified wire labels according to this image:
http://i.imgur.com/3GaLDI1.jpg)
5pin extension cable white wire (I identified it as "RxD") -> USB to UART connection point "RxD"
black wire ("GND") -> DC booster connection point "OUT-" (GND)
green wire ("TxD") -> USB UART connection point "TxD"
red (i guess it's brown"ish") ("P+") -> DC booster connection point "OUT+" (P+)
orange wire -> left it unconnected (just dangling there on the side)
DC booster connection point "IN+" -> USB to UART connection point "5V"
DC booster connection point "IN-" -> USB to UART connection point "GND"
This solution might be specific to my situation therefore I would suggest to try it at own risk and only if all else fails (try rechecking if you identified the connection points correctly and if you connected everything correctly according to TSDZ2 wiki guide).
1) So the power LED should go on and stay on when you insert the USB stick
2) The "TXD" LED should light or pulse if there is voltage present or voltage pulses being sent from the USB to UART to the display. IF the TXD LED lights up when you power on the display, that's a key indicator your Tx/Rx are swapped! The RXD LED should be the one to light up when you power on the display while connected to the bootloader.
3) The "RXD" LED should only pulse once in a while during programming when the display is acknowledging back to the USB to UART. TXD LED will probably be solid lit for 1 to 1.5seconds and then a very short blip of RXD when programming is ongoing.
Any possibility to get Tomcys' info added to the home made bootloader Wiki? His info would have sped me on my way to discovering my swap of Tx/Rx
casainho said:
Thank you Casainho. I did some tests described below. In case you need more info or more testing please do not hesitate to come back to me. I hope that the results might be useful.
The three tests were performed both with versions 0.56 and 0.56.:
Test Case 1.
1. I select assist level one.
2. I press the minus button and keep it pressed to activate walk assist.
3. The motor starts in walk assist mode.
4. Trying to turn back the pedals is simply not possible. I try by hand only. The motor is much stronger than me.
5. I release the minus button. Here we have a fork:
6.1. Motors stops. This happens only 1 of 10 cases.
6.2. In 9 of 10 cases the motor continues running but in another mode. I assume it is the one of normal assist 1. I do not touch the pedals. They are rotating in the coaster brake motor version.
- v.056 - the motor stops after applying some back force on the pedals. After hat I can turn back and brake. Here I did only one test.
- v.056.1 - the motor stops after applying some back force on the pedals. May be the required force is a bit less than the one required for v.0.56 but more or less the same. The difference is also that the stopping is different. In this case it is not sudden but gradual and I can hear some grinding noises from the motor until it stops. May be for a second or two. Continuing with the back peddling to brake is almost impossible. I have to release the pedals from braking and only after second attempt I can brake normally.
Test Case 2:
1. I select assit mode 1.
2. I push the pedals front to engage the motor. The motor activates.
3. I stop pushing the pedals and take my hands off. The motor does not stop but continues running. The same way as after releasing the minus button to exit walk assist
4. On the display I see cadence 16 or 17, motor current 0.4 and human power 2.
5. When I back pedal the behaviour is the same as in point 6.2 of Test Case 1.
Test Case 3.
1. Motor running is either walk assist mode 1 or assist mode 1 ( the one described in Test Case 2, points 3. and 4.)
2. I apply force on the hand brake required only to activate the brake sensor.
2.1. Walk assist mode 1. Motor stops immediately.
2.2. Assit mode 1. Motor stops immediately.
3. After that I can directly back pedal to activate the coaster brake. It is possible from the first attempt.
In my opinion we are on the right track but some more fine tuning is necessary. The grinding noise and the blocking of the back pedalling (the required effort release and reapplying it for a second time in order to brake) is a bit of worry to me.
I don't know if not stopping of the motor after pushing the pedals forward in normal assist mode is a bug or a feature.
N.B. The testing was done in my living room only using my hands.
jeff.page.rides
100 W
- Joined
- Aug 13, 2019
- Messages
- 295
When using version 19 on my handcycle with the coaster brake I had to pull back twice to get the motor to stop and to be able to apply the brake. After switching to version 20 I only had to pull back once to get the motor to stop and apply the brake. So it sounds like adding the code isn't working correctly yet. I never have used or activated walk-assist maybe that's the problem.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
plpetrov, please test torque sensor ADC values, see how many negative units you get using or hands and your legs... Compare to the positive values.
After, do the same tests but with motor running.
Report when you have some data.
Do not enable torque sensor calibration, it does not expect negative values...
After, do the same tests but with motor running.
Report when you have some data.
Do not enable torque sensor calibration, it does not expect negative values...
casainho said:
Casainho,
Please find below the values you asked. However I did not get negative values. Now writing, I think may be I did not apply enough force. What I got is just decrease of the ACD Torque sensor value. The tests were done for the left and right side of the pedals:
Test case 1: Stationary, back tyre blocked by the coaster brake.
a. Left pedal side (for the calibration it is the right side, as I apply the braking weight on the opposite pedal):
ACD torque sensor value = 110 - 6 kg applied backwards
ACD torques value = 139 - 0 kg
ACD torque sensor value = 160 - 6 kg applied forward
b. Right pedal side (for the calibration it is the left side as I apply the braking weight on the opposite pedal):
ACD torque sensor value = 108 - 6 kg applied backwards
ACD torques value = 133 - 0 kg
ACD torque sensor value = 168 - 6 kg applied forward
Test case 2: Back tyre self rotating in assist level 1. I performed two or 3 measurements per side but had the feeling the the display values are a bit delayed. However at the moment of stoping the rotation we had the following values:
a. Left pedal side (for the calibration it is the right side as I apply the braking weight in the opposite pedal):
ACD torque sensor value = 123
b. Right pedal side (for the calibration it is the left side as I apply the braking weight in the opposite pedal):
ACD torque sensor value = 117
Test case 3: Back tyre self rotating in walk assist level 1. I can repeat it tomorrow morning. I could not stop the pedals by hand to get the ACD torque value at which the motor will stop.
Best wishes,
Plamen
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
Yes, negative torque sensor value is a value lower than the rest value. The values you reported are good to understand however, can you please try to block the wheel and brake as you expect and see the amount of ADC value goes lower / negative?plpetrov said:
Because on firmware is this:
#define COASTER_BRAKE_TORQUE_THRESHOLD 40
I think I know a way to almost immediately disable the motor as soon the negative threshold value is hit... Just tell me what is that value...
Similar threads
