TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

Zelenaar said:
casainho said:
Zelenaar said:
How can I test if there is communication between display and motor ?
The LCD works stand alone from the motor. If the data variables for configuration does not arrive to the motor, it may not work. Like, if it consider 0 assist level after power on and LCD do not send assist higher than 0, then motor will not assist.

But if you had communication, the battery voltage would be correct to what you expect. I don't know what that LCD shows when it does not receive any battery voltage after power on.
What if you had incorrect configuration on battery cells number??

Or most important, are you sure motor is turned on?? Because LCD does but motor may not be turned on and so no data on LCD!!

Hi Casainho
I disassembled the motor/controller and did some testings and measurements

Battery (unplugged, switched on) : 41.7v

20190413_142346s.jpg
Controller (battery on, display on)
Controller 5wire white connector :
  • Black-red : 4.2v (0v when display off)
  • Black-green : 4.8v (0v when display off)
  • All other combinations : 0v

Controller 2 wire white connector :
  • Black-red 0v

Motor :
  • All combinations between blue-green-yellow 0v

Motor to display connector (6p female):
(Unplugged from display, battery on)
  • Black-green : 41.3v
  • Black-all others : 0v

Motor to speedsensor/program connector (6p male)
(Unplugged from speedsensor, battery on, display on)
  • Orange-black : 4.6v
  • Orange-brown : 4.9v
  • Orange-purple : 2.1v

Display :
Disassembled and checked connections
After powerup (using (|) button) : Battery indicator always on 1bar, level up/down working but no reaction of motor, walk assist not working.
Odo correct on 144km
20190411_114724s.jpg

--------------------------------------------------------------------
What to conclude ??
  • Wiring issue ? : I don't think so
    triple checked as much as possible the wiring/connectors.
    was working before, nothing changed myself, no indications something was touched in the bikeshop during disc repair
  • Display issue ? : Maybe ?
    Is the display still sending correct signals to motor to ie power up ? (But I can see 4.2v & 4.8v on the 5pwhite connector in the controller when display is powered on)
    not sure how to test more
  • Controller issue ? : Maybe ?
    not sure how to test more
  • Firmware issue ? : Maybe ?
    Corrupted or wiped ? not sure as I can't test without ST-link programmer
Good tests!!
What about brake sensors?? See that firmware will not initialize (at least "my" firmware) if brake sensors are active. I mean, can be the brake signal itself for some reason and not the sensors themselfs.

If not, I can't see a reason other display not working or firmware not working. On firmware, can be something like corrupted EEPROM were configurations are saved??

About corruption of flash or EEPROM memory data, I could believe on that if firmware for some reason the motor coils are being incorrectly controlled and generating voltage peaks for regen, most likely when disable/enable PWM like I added recently to our firmware -- but I took great care to try avoid that possibility.
 
Just a short update from SW102 development:
IMG_20190413_223021_k.jpg

This looks broken but it's a proof of concept that we can initialize the LCD controller and show (some garbage) data.

Greetings
Nick
 
Nick said:
Just a short update from SW102 development:
IMG_20190413_223021_k.jpg

This looks broken but it's a proof of concept that we can initialize the LCD controller and show (some garbage) data.

Greetings
Nick
Really happy we got there!! Please push to github repo that I gave you write access as I would like to play a bit to figure out the pixels mapping to the bits we send.

I was stuck but didn't quit yet, having other developer as you is really great to move forward much faster!! So nice to see OpenSource working, mainly because ebike is growing and we can invest our time and take immediately value of it!!

Also please consider to use ugui library to rive the LCD as it is the one I am using for 850C and that way we could help each other: https://github.com/achimdoebler/UGUI
 
casainho said:
thineight said:
Hello casainho, any chance for you to release the next version with Buba fixes on LCD3 before the weekend?
It is a good window for us to test and report the feelings.
Buba fixes were only to distance so I think it is not enough for a new release, looking at the other issues reported.

I see beta 3 was released with some improvements on motor side, can you please release the beta4 with the LCD3 display (odometer bug) corrected, since the code is already fixed?
Thanks a lot.
 
thineight said:
casainho said:
thineight said:
Hello casainho, any chance for you to release the next version with Buba fixes on LCD3 before the weekend?
It is a good window for us to test and report the feelings.
Buba fixes were only to distance so I think it is not enough for a new release, looking at the other issues reported.

I see beta 3 was released with some improvements on motor side, can you please release the beta4 with the LCD3 display (odometer bug) corrected, since the code is already fixed?
Thanks a lot.
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0-beta4
 
casainho said:
Nick said:
Just a short update from

This looks broken but it's a proof of concept that we can initialize the LCD controller and show (some garbage) data.

Greetings
Nick
Really happy we got there!! Please push to github repo that I gave you write access as I would like to play a bit to figure out the pixels mapping to the bits we send.

I was stuck but didn't quit yet, having other developer as you is really great to move forward much faster!! So nice to see OpenSource working, mainly because ebike is growing and we can invest our time and take immediately value of it!!

Also please consider to use ugui library to rive the LCD as it is the one I am using for 850C and that way we could help each other: https://github.com/achimdoebler/UGUI

Nick, Casainho,

I assume this is the same display eggrider is using
https://bitbucket.org/eggpower/eggriderv2/wiki/Home
They are using the bluetooth to upload new firmware.
Are there plans/ideas to develop an android app ?
- easy setup/change of the firmware settings ?
- visualusation/download of the stats.

I ordered one with pswpower on aliexpress. Hopefully i can start playing with it in a few weeks.
 
Zelenaar said:
Nick, Casainho,

I assume this is the same display eggrider is using
https://bitbucket.org/eggpower/eggriderv2/wiki/Home
They are using the bluetooth to upload new firmware.
Are there plans/ideas to develop an android app ?
- easy setup/change of the firmware settings ?
- visualusation/download of the stats.

I ordered one with pswpower on aliexpress. Hopefully i can start playing with it in a few weeks.
How can you help to get there? Are you available to develop?

Yes, I think it is similar and maybe we should put a note on the wiki.
 
casainho said:
Zelenaar said:
Nick, Casainho,

I assume this is the same display eggrider is using
https://bitbucket.org/eggpower/eggriderv2/wiki/Home
They are using the bluetooth to upload new firmware.
Are there plans/ideas to develop an android app ?
- easy setup/change of the firmware settings ?
- visualusation/download of the stats.

I ordered one with pswpower on aliexpress. Hopefully i can start playing with it in a few weeks.
How can you help to get there? Are you available to develop?

Yes, I think it is similar and maybe we should put a note on the wiki.

Hi Casianho
I have a technical (and programming) background.
Programming skills maybe a little rusty but I did Arduino, C, C++, little Java, ... development in the pasts.
I also have graphical skills => maybe I can assist in the gui part
And the last year my son did some Bluetooth and android app developments for his bachelor projects, I could try to activate him to assist me in starting an Android App
 
casainho said:
Rydon said:
I tested v19 beta 3 on a coaster brake motor. There is no backward resistance but I also have no power. I did a reset and triple checked all the settings. There are good torque and PAS/cadence readings but always 0 watts. Any ideas?

The motor worked fine with v18.2 but had extreme backward resistance that made it unusable for coaster brake.
This code changed bit since beta 2, now ui8_pas_cadence_rpm will be 0 if we are not pedaling forward:

Can you please verify that you have cadence value only when pedaling forward??

This is the new piece of code to turn on/off the motor PWM. See that if there is not ui8_m_adc_battery_target_current because there is no cadence or torque.

Try also to enable BOOST.

Sorry, I missed this when you posted it. I have tested again and cadence is 0 when pedaling backward. There is no power when pedaling forward at any assist level. Watts is always 0. Cadence reads as expected when pedaling forward. Turning on boost has no effect. Can I try something else?
 
Rydon said:
casainho said:
Rydon said:
I tested v19 beta 3 on a coaster brake motor. There is no backward resistance but I also have no power. I did a reset and triple checked all the settings. There are good torque and PAS/cadence readings but always 0 watts. Any ideas?

The motor worked fine with v18.2 but had extreme backward resistance that made it unusable for coaster brake.
This code changed bit since beta 2, now ui8_pas_cadence_rpm will be 0 if we are not pedaling forward:

Can you please verify that you have cadence value only when pedaling forward??

This is the new piece of code to turn on/off the motor PWM. See that if there is not ui8_m_adc_battery_target_current because there is no cadence or torque.

Try also to enable BOOST.

Sorry, I missed this when you posted it. I have tested again and cadence is 0 when pedaling backward. There is no power when pedaling forward at any assist level. Watts is always 0. Cadence reads as expected when pedaling forward. Turning on boost has no effect. Can I try something else?
So, there is cadence and torque sensor signal. Please try startup start without pedaling.

Please tell if PWM duty-cycle value do increases when you pedal with torque... It should increase!!

Are you sure brake signal is not active??
 
Zelenaar said:
casainho said:
Zelenaar said:
Nick, Casainho,

I assume this is the same display eggrider is using
https://bitbucket.org/eggpower/eggriderv2/wiki/Home
They are using the bluetooth to upload new firmware.
Are there plans/ideas to develop an android app ?
- easy setup/change of the firmware settings ?
- visualusation/download of the stats.

I ordered one with pswpower on aliexpress. Hopefully i can start playing with it in a few weeks.
How can you help to get there? Are you available to develop?

Yes, I think it is similar and maybe we should put a note on the wiki.

Hi Casianho
I have a technical (and programming) background.
Programming skills maybe a little rusty but I did Arduino, C, C++, little Java, ... development in the pasts.
I also have graphical skills => maybe I can assist in the gui part
And the last year my son did some Bluetooth and android app developments for his bachelor projects, I could try to activate him to assist me in starting an Android App
I think no one is planning or doing the Android app and that will be a need. If you think you motivated to do it, please consider that and let's start first discussing what it should do.
 
Nick said:
SW102 basic µGUI integration:

IMG_20190415_194035_k.jpg
Great!!!

Now I advice you to follow the 850C firmware structure about receiving and sending data. At least on 850C, updating the display is so slow that I was missing communication packages. SW102 has DMA to transfer data to LCD but 850C can't use DMA so it makes the processor busy when driving the LCD. SW102 has advantage however, seems SW102 runs at 16MHz while 850C runs at 128MHz... so, if you separate the pieces of code running like keep in parallel and high priority the receiving of data from motor controller, you should not miss a package and also being able to calculate the things like battery SOC at always 100ms.

The data I am trying to save and show on LCD on 850C (save every 3.5 seconds, from last 60 minutes) I think you should save only on LCD memory and be ready to send to to mobile app when requested.

See that you will need to use the flash memory of NRF51 as EEPROM. On 850C, it has an external I2C EEPROM but I just forgot about it and I am using the STM32F103 flash as EEPROM.
 
casainho said:
So, there is cadence and torque sensor signal. Please try startup start without pedaling.

Please tell if PWM duty-cycle value do increases when you pedal with torque... It should increase!!

Are you sure brake signal is not active??

Ok, tested again after much rain. PWM is 0 pedaling with torque. There are no brake sensors installed.

I did notice that when you first power up the display it has a steady 0 and only a 0 in the odometer field and then changes after 5 seconds to a flashing 1. When pressing on/off to cycle through odometer fields the odometer field goes blank and so does the wheel speed. They never come back until power is cycled.
 
Rydon said:
casainho said:
So, there is cadence and torque sensor signal. Please try startup start without pedaling.

Please tell if PWM duty-cycle value do increases when you pedal with torque... It should increase!!

Are you sure brake signal is not active??

Ok, tested again after much rain. PWM is 0 pedaling with torque. There are no brake sensors installed.

I did notice that when you first power up the display it has a steady 0 and only a 0 in the odometer field and then changes after 5 seconds to a flashing 1. When pressing on/off to cycle through odometer fields the odometer field goes blank and so does the wheel speed. They never come back until power is cycled.
That one flashing is the error number 1 that means that torque sensor is being activated but wheel does not rotate after that 5 seconds. Why is that happening on that motor??

Can you post the values of torque sensor ADC and torque sensor at rest after startup and when you make force??

And make sure the wheel speed sensor is working.
 
Nick said:
SW102 basic µGUI integration:

IMG_20190415_194035_k.jpg

Hello SW102!!!

To me this is really the futur display for this firmware.
Minimalistic rich GUI on the bike (but still with enough details).
Details/logs/config on a android App using bluetooth,
And if uploading of firmware via bluetooth would work ... than no need for opening/wiring/soldering.

Nick, Casainho,
I will send you PM later today to see how (and when) I could participate in the android app
 
Nick said:
SW102 basic µGUI integration:

IMG_20190415_194035_k.jpg

Hello SW102!!!

To me this is really the futur display for this firmware.
Minimalistic rich GUI on the bike (but still with enough details).
Details/logs/config on a android App using bluetooth,
And if uploading of firmware via bluetooth would work ... than no need for opening/wiring/soldering.

Nick, Casainho,
I will send you PM later today to see how (and when) I could participate in the android app
 
Zelenaar said:
Nick said:
SW102 basic µGUI integration:

IMG_20190415_194035_k.jpg

Hello SW102!!!

To me this is really the futur display for this firmware.
Minimalistic rich GUI on the bike (but still with enough details).
Details/logs/config on a android App using bluetooth,
And if uploading of firmware via bluetooth would work ... than no need for opening/wiring/soldering.

Nick, Casainho,
I will send you PM later today to see how (and when) I could participate in the android app
Please do not send private as I prefer to talk public so others can follow/learn and join/help as they can.

Write your ideas like a quick proposal and then we can discuss.
 
casainho said:
Great!!!

Now I advice you to follow the 850C firmware structure about receiving and sending data. At least on 850C, updating the display is so slow that I was missing communication packages. SW102 has DMA to transfer data to LCD but 850C can't use DMA so it makes the processor busy when driving the LCD...

As far as I read the SDK docu, we can't use DMA for SPI master transfers. This needs a SPIM module, which only the nrf52 chips do have. Please correct me if I miss something, still new to this SDK and chip.
I read that only 2.4 GHz radio, encryption and SPI slave do have DMA support.

Right now CPU waits for SPI transaction to finish before next packets are send (blocking). My next step will be to implement SPI transfer non-blocking, this will reduce CPU load but needs more logic in the event handler.


Gretings
Nick

BTW,
discussing all technical ideas and details in this thread makes it very confusing. Should we move with those details to another solution? Github maybe?
 
Nick said:
As far as I read the SDK docu, we can't use DMA for SPI master transfers. This needs a SPIM module, which only the nrf52 chips do have. Please correct me if I miss something, still new to this SDK and chip.
I read that only 2.4 GHz radio, encryption and SPI slave do have DMA support.

Right now CPU waits for SPI transaction to finish before next packets are send (blocking). My next step will be to implement SPI transfer non-blocking, this will reduce CPU load.
I expected DMA. Well, just use NRF drivers because they should implement the best possible and see here SPI Manager example, that exactly drives a LCD: https://www.nordicsemi.com/DocLibRenamed/Content/SDK_Doc/nRF5_SDK/v15-3-0/nrf_spi_mngr_example
I used SPI Manager in the past.
 
Zelenaar said:
Nick said:
SW102 basic µGUI integration:

IMG_20190415_194035_k.jpg

Hello SW102!!!

To me this is really the futur display for this firmware.
Minimalistic rich GUI on the bike (but still with enough details).
Details/logs/config on a android App using bluetooth,
And if uploading of firmware via bluetooth would work ... than no need for opening/wiring/soldering.

Although doable, opening up the case is pretty ugly so Eyebyesickle and I have been exploring bluetooth uploading and firmware flashing with Topology Tech., the SW102 manufacturer. The problem we have is that they require an NDA to gain access to their boot loader and technical documents. As Casainho has pointed out an NDA is not possible with an open source project like this. Eyebyesickle is still trying to get them to reconsider this so that is still a possibility.

Topology Tech has said that with a volume commitment, they would be willing to preload firmware for us at the factory. We are willing to make that commitment. There are several possibilities with that approach.

The first might be to use a generic Bluetooth bootloader based on the Nordic NRF SDK that we could give to Topology to preload at the factory, after which we can use Bluetooth to update the firmware. Some have expressed that with a generic bootloader someone could maliciously reprogram your display remotely. I tend to think the possibility of this is remote and is a form of vandalism. A vandal could more easily take a hammer to your display if harm was their intent. Perhaps a password system could be implemented as a way to address this concern.

Another possibility would be to load a complete version of the firmware. The problem would be that it would be stuck on that version. Maybe that would not be bad if it was mature. My concern is if people start expanding it to cell phone app functionality they will inevitably want to make changes to the SW102 firmware. This has been the case with Eggrider for over a year. I would rather see a generic bootloader loaded at the factory or if Eyebyesickle prevails we can perhaps use theirs without an NDA.

I am sure we will figure something out. Let's keep this discussion going as development proceeds.
 
The first might be to use a generic Bluetooth bootloader based on the Nordic NRF SDK that we could give to Topology to preload at the factory, after which we can use Bluetooth to update the firmware.

If it s possible, i thinck moving to SW102 will make ppl enjoy
( i hope for, because i don t want to open SW102 as it s too meticulous for me ) .

As said before, it s not necessary to get acces full parameters with SW102 ...

What i would see on it :
time if avaiable
speed,
volt or a good baregraphe ( battery ), assist lvl, walk assist ( this 3 things absolutly necessary for me )

enjoy .

[youtube]kUSiMJRJqRI[/youtube]

OTB on second ( 9"50 ) and third video without big trouble for me ...
397 Wh used for 43 km and 1350 D+
12S battery on TSDZ v 0.16 open source firmware .
 
Nick said:
BTW,
discussing all technical ideas and details in this thread makes it very confusing. Should we move with those details to another solution? Github maybe?

Nick,
indeed maybe better to create a seperated post for it "TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor - SW102 developments"

Casainho,
Could you give me write access to the github section for SW102 (Also "Zelenaar") ? I would like to start adding a "spec wishlist" for the android app. and maybe some different gui designs for SW102 & Android app
Is there somewhere a list of info's that can be displayed ? (speed, odo, motor watts, human watts, .....) ?
stupid question without going thr your existing display codes ... Is the basic principle that the data is pushed to the display by the motor ? or is the display every x sec pulling the data from the motor ?

PS : I'm still waiting on my SW102 displays, hopefully in 1 to 2 weeks until then I need to limit myself to "paperware" :evil:
 
Zelenaar said:
Nick said:
BTW,
discussing all technical ideas and details in this thread makes it very confusing. Should we move with those details to another solution? Github maybe?

Nick,
indeed maybe better to create a seperated post for it "TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor - SW102 developments"

Casainho,
Could you give me write access to the github section for SW102 (Also "Zelenaar") ? I would like to start adding a "spec wishlist" for the android app. and maybe some different gui designs for SW102 & Android app
Is there somewhere a list of info's that can be displayed ? (speed, odo, motor watts, human watts, .....) ?
stupid question without going thr your existing display codes ... Is the basic principle that the data is pushed to the display by the motor ? or is the display every x sec pulling the data from the motor ?

PS : I'm still waiting on my SW102 displays, hopefully in 1 to 2 weeks until then I need to limit myself to "paperware" :evil:
I created this thread specifically for SW102: https://endless-sphere.com/forums/viewtopic.php?f=30&t=99698

I gave you write permissions to the wiki and repo for SW102 firmware. For mobile app, maybe we should use another repo specific to that.

Motor controller pushes data to the display and it is very basic to understand, please see here the full data that is sent:
uart_send_package()

https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/blob/master/src/controller/ebike_app.c

See that there are some features that are implemented by the LCD, like battery colomb counting for SOC.
 
Back
Top