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

[HughF]

These are the settings I use. It is working better than the default settings.

Thanks for this My boost settings are the same as the regular assist settings so perhaps that is the problem! I'll up them and see if it makes a difference. I have configured the torque settings but can't say it made any difference. The only other thing I can think of is turning the field weakening off to see if that makes a difference.

Lowering all the ADC settings, helped improve the low-end power.

Thanks for that, I'm suffering from this on steep climbs too
Because the motor adds % power compared to torque x cadence, as cadence slows on the climb I lose power, so my cadence slows, so I lose power, so my cadence slow, then I can't climb any more.

I have been slowly raising the ADCs, to try and get rid of the ghost peddling, over run and random cut outs on rough terrain.

The mud "disabled" my speed sensor, but the motor behaved as normal. this wouldn't have been the case with the original firmware as it uses speed in it calculations. Is this part of the problem?

Switch to torque mode, that will remove the cadence value from the motor current calculation.

Although torque mode has been the default since 1.0.0

[mctubster]

Switch to torque mode, that will remove the cadence value from the motor current calculation.

Although torque mode has been the default since 1.0.0

Doesn't for me at least on v1.1 ... I have noted when climbing a very steep hill on a 90kg loaded cargo bike at say 60 dropping to 40 rpm the motor says it is supplying a high current, but my seperate current meter shows the actual current from the battery is much lower. There is definitely some kind of feature here. Maybe I have a setting somewhere that causes this.

Anyways there is finally a release of the .20 codebase with support for 860c which sounds like .20 motor control + foc + further optimisations, so will install tonight and take some of my ballast (6yo, 3yo) for a test of the bike up "the hill" https://goo.gl/maps/XawpySWDXRDYJZMZ8

Now that I have another cargo bike with Bosch gen 4 cargo line, I have something to compare to too.

[Surdeahora]

"Anyways there is finally a release of the .20 codebase with support for 860c which sounds like .20 motor control + foc + further optimisations, so will install tonight"

Hi is there a link for the code for .20 that supports 860c?

I'd love to try it out.

Does anyone know, are there plans to address the low end torque / hill starts on 1.1?

Just wandering if I should stick it out with this version or if I need to keep searching for alternatives.
Thanks

[HughF]

"Anyways there is finally a release of the .20 codebase with support for 860c which sounds like .20 motor control + foc + further optimisations, so will install tonight"

Hi is there a link for the code for .20 that supports 860c?

I'd love to try it out.

Does anyone know, are there plans to address the low end torque / hill starts on 1.1?

Just wandering if I should stick it out with this version or if I need to keep searching for alternatives.
Thanks

The torque mode fork by user r0mko (Search on here for a thread I started about it) has very good low-end performance with a current ramp that is 3x the value shown on the display.

[HughF]

Switch to torque mode, that will remove the cadence value from the motor current calculation.

Although torque mode has been the default since 1.0.0

Doesn't for me at least on v1.1 ... I have noted when climbing a very steep hill on a 90kg loaded cargo bike at say 60 dropping to 40 rpm the motor says it is supplying a high current, but my seperate current meter shows the actual current from the battery is much lower. There is definitely some kind of feature here. Maybe I have a setting somewhere that causes this.

Anyways there is finally a release of the .20 codebase with support for 860c which sounds like .20 motor control + foc + further optimisations, so will install tonight and take some of my ballast (6yo, 3yo) for a test of the bike up "the hill" https://goo.gl/maps/XawpySWDXRDYJZMZ8

Now that I have another cargo bike with Bosch gen 4 cargo line, I have something to compare to too.

I'd be very interested to hear how the TSDZ2 compares to a commercial offering as I'm looking for something more 'integrated' now...

[dameri]

"Anyways there is finally a release of the .20 codebase with support for 860c which sounds like .20 motor control + foc + further optimisations, so will install tonight"

Hi is there a link for the code for .20 that supports 860c?

I'd love to try it out.

Does anyone know, are there plans to address the low end torque / hill starts on 1.1?

Just wandering if I should stick it out with this version or if I need to keep searching for alternatives.
Thanks

It is v20.1 but here is the link: https://www.endless-sphere.com/forums/v ... 2#p1621822

[bikelpl]

I have tested powering up with just 36V on the screen and also plugged into my TSDZ2 successfully running v1.1 (with my 860c). No change in behaviour. Blank screen with 850c firmware. Display works with 860c firmware as long as I hold down the power button

Probably and old and incorrect hardware version of 850C. The best bet is to use the 860C display as there are no reports of such issues with it.

Thanks for the reply casainho. I did wonder that and checked the back of the screen. Looks like manufacture 2021! don’t disagree re the 860c screen.B6A8EB97-7D29-4B0B-AB93-32E5D4C4E8F9.jpeg

Maybe I should change the wiki instructions and remove the 850C, as even if some old and this recent version does not work, so no point to recomend it.

I also have the newest 850C display. I managed to run it with OSF.

Below init code works with newest 850C display marked as "TFTGD3V2.3LF60"
It is mix of 860C init.
I don't know how to add this to github and how to make this code to be automatically chosen between different versions of displays so i paste it here. Maybe someone else possibly could add it to github repository.

Code: Select all

void display_8x0C_lcd_init() {
    // next step is needed to have PB3 and PB4 working as GPIO
    /* Disable the Serial Wire Jtag Debug Port SWJ-DP */
    GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);
    
    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_InitStructure.GPIO_Pin = LCD_READ__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_READ__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = LCD_RESET__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_RESET__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = LCD_COMMAND_DATA__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_COMMAND_DATA__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = LCD_CHIP_SELECT__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_CHIP_SELECT__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = LCD_WRITE__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_WRITE__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = 0xffff;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_BUS__PORT, &GPIO_InitStructure);
    
    // disable reset
    GPIO_SetBits(LCD_RESET__PORT, LCD_RESET__PIN);
    
    // default to write mode
    GPIO_SetBits(LCD_READ__PORT, LCD_READ__PIN);
    
    // keep chip select active
    GPIO_ResetBits(LCD_CHIP_SELECT__PORT, LCD_CHIP_SELECT__PIN);
    
   
    lcd_IC_t type = LCD_ST7796;

        delay_ms(120);
        lcd_write_command(0x11);
        delay_ms(120);

        lcd_write_command(0x36);
        lcd_write_data_8bits(0x48);

        lcd_write_command(0x3A);
        lcd_write_data_8bits(0x55);

        lcd_write_command(0xF0);
        lcd_write_data_8bits(0xC3);

        lcd_write_command(0xF0);
        lcd_write_data_8bits(0x96);

        lcd_write_command(0xB4);
        lcd_write_data_8bits(0x01);

        lcd_write_command(0xB7);
        lcd_write_data_8bits(0xC6);

        lcd_write_command(0xC0);
        lcd_write_data_8bits(0xF0);
        lcd_write_data_8bits(0x35);

        lcd_write_command(0xC1);
        lcd_write_data_8bits(0x15);

        lcd_write_command(0xC2);
        lcd_write_data_8bits(0xAF);

        lcd_write_command(0xC3);
        lcd_write_data_8bits(0x09);

        lcd_write_command(0xC5);     //VCOM
        lcd_write_data_8bits(0x06);

        lcd_write_command(0xC6);
        lcd_write_data_8bits(0x00);

        lcd_write_command(0xE8);
        lcd_write_data_8bits(0x40);
        lcd_write_data_8bits(0x8A);
        lcd_write_data_8bits(0x00);
        lcd_write_data_8bits(0x00);
        lcd_write_data_8bits(0x29);
        lcd_write_data_8bits(0x19);
        lcd_write_data_8bits(0xA5);
        lcd_write_data_8bits(0x33);

        lcd_write_command(0xE0);
        lcd_write_data_8bits(0x70);
        lcd_write_data_8bits(0x00);
        lcd_write_data_8bits(0x05);
        lcd_write_data_8bits(0x03);
        lcd_write_data_8bits(0x02);
        lcd_write_data_8bits(0x20);
        lcd_write_data_8bits(0x29);
        lcd_write_data_8bits(0x01);
        lcd_write_data_8bits(0x45);
        lcd_write_data_8bits(0x30);
        lcd_write_data_8bits(0x09);
        lcd_write_data_8bits(0x07);
        lcd_write_data_8bits(0x22);
        lcd_write_data_8bits(0x29);

        lcd_write_command(0xE1);
        lcd_write_data_8bits(0x70);
        lcd_write_data_8bits(0x0C);
        lcd_write_data_8bits(0x10);
        lcd_write_data_8bits(0x0F);
        lcd_write_data_8bits(0x0E);
        lcd_write_data_8bits(0x09);
        lcd_write_data_8bits(0x35);
        lcd_write_data_8bits(0x64);
        lcd_write_data_8bits(0x48);
        lcd_write_data_8bits(0x3A);
        lcd_write_data_8bits(0x14);
        lcd_write_data_8bits(0x13);
        lcd_write_data_8bits(0x2E);
        lcd_write_data_8bits(0x30);

       // lcd_write_command(0x21);

        lcd_write_command(0xF0);
        lcd_write_data_8bits(0xC3);

        lcd_write_command(0xF0);
        lcd_write_data_8bits(0x96);

        delay_ms(120);

        lcd_write_command(0x29);
    
    delay_ms(25);
    // End of display configuration
    // @geeksville board reads back as 0x2, 0x4, 0x94, 0x81, 0xff - a legit ili9481
    write_pulse_duration = 0; // enable fast writes
    
    // Note: if we have some devices still not working, we might need to add a READ command to 0xbf (8.2.39) to read
    // the chip id of the failing units - this would allow us to see the vendor code of whoever made the display and
    // confirm it is a 9481 (or if different - what it is)
    
    // It is worth noting that the display controller has a small amount of non volatile memory.  I bet the mfg of the
    // 850C is checking that code in their firmware, and based on that value chosing to flip the display horizontally
    // if needed (via command 0x36)
    
    // Initialize global structure and set PSET to this.PSET.
    UG_Init(&gui, lcd_pixel_set, DISPLAY_WIDTH, DISPLAY_HEIGHT);
    // Register acceleratos.
    UG_DriverRegister(DRIVER_FILL_FRAME, (void*) HW_FillFrame);
    UG_DriverRegister(DRIVER_DRAW_LINE, (void*) HW_DrawLine);
    UG_DriverRegister(DRIVER_FILL_AREA, (void*) HW_FillArea);   

    //UG_DriverEnable ( DRIVER_FILL_FRAME ) ;
   // UG_DriverEnable ( DRIVER_DRAW_LINE ) ;
   // UG_DriverEnable ( DRIVER_FILL_AREA ) ;
}

[Mr.Flibble]

Thanks for this My boost settings are the same as the regular assist settings so perhaps that is the problem! I'll up them and see if it makes a difference. I have configured the torque settings but can't say it made any difference. The only other thing I can think of is turning the field weakening off to see if that makes a difference.

Lowering all the ADC settings, helped improve the low-end power.

Thanks for that, I'm suffering from this on steep climbs too
Because the motor adds % power compared to torque x cadence, as cadence slows on the climb I lose power, so my cadence slows, so I lose power, so my cadence slow, then I can't climb any more.

I have been slowly raising the ADCs, to try and get rid of the ghost peddling, over run and random cut outs on rough terrain.

The mud "disabled" my speed sensor, but the motor behaved as normal. this wouldn't have been the case with the original firmware as it uses speed in it calculations. Is this part of the problem?

Switch to torque mode, that will remove the cadence value from the motor current calculation.

Although torque mode has been the default since 1.0.0

Makes very little difference, in fact power mode is slightly better at hill climbing.
Torque mode somehow provides more power at higher cadences with less pressure on the peddles .....................

Think I may try the other fork tomorrow.

[mctubster]

Now that I have another cargo bike with Bosch gen 4 cargo line, I have something to compare to too.

I'd be very interested to hear how the TSDZ2 compares to a commercial offering as I'm looking for something more 'integrated' now...

I think of the Bosch gen 4 as a Mercedes ... it is well built, simple to operate, reliable. On the downside it is expensive, and not like owning an Alfa

It certainly feels like it has a torque or boost mode when starting off, and then switches to a power mode at higher RPMS. It has a huge amount of torque, certainly more than the TSDZ2 - I would almost say the top assist level is dangerous if you are not expecting it at low speeds.

The pedal responsiveness is amazing, extremely fast to respond to changes in pedal pressure. Means you can take off some power for .5s while changing gears

I ride on economy or tour. Unfortunately there is a big step up in power in tour, I sometimes find myself wanting something in the middle. For my wife (who this bike is for) it is perfect. She rides to school with our eldest on the back. She uses tour and switches to sport when climbing steep hills.

The biggest issue is the 25km/h speed limit here in AU ... I certainly am getting a lot of exercise when I wind this very heavy bike up to 30km/h + since I am doing all of the work, maybe not a bad thing.

Lots of other little refinements too, always on brake light, very accurate range estimation. Just be aware that the batteries are at a 30-50% premium over decent generics.

[mctubster]

I also have the newest 850C display. I managed to run it with OSF.

Below init code works with newest 850C display marked as "TFTGD3V2.3LF60"
It is mix of 860C init.
I don't know how to add this to github and how to make this code to be automatically chosen between different versions of displays so i paste it here. Maybe someone else possibly could add it to github repository.

Code: Select all

void display_8x0C_lcd_init() {
    // next step is needed to have PB3 and PB4 working as GPIO
    /* Disable the Serial Wire Jtag Debug Port SWJ-DP */
    GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);
    
    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_InitStructure.GPIO_Pin = LCD_READ__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_READ__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = LCD_RESET__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_RESET__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = LCD_COMMAND_DATA__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_COMMAND_DATA__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = LCD_CHIP_SELECT__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_CHIP_SELECT__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = LCD_WRITE__PIN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_WRITE__PORT, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = 0xffff;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(LCD_BUS__PORT, &GPIO_InitStructure);
    
    // disable reset
    GPIO_SetBits(LCD_RESET__PORT, LCD_RESET__PIN);
    
    // default to write mode
    GPIO_SetBits(LCD_READ__PORT, LCD_READ__PIN);
    
    // keep chip select active
    GPIO_ResetBits(LCD_CHIP_SELECT__PORT, LCD_CHIP_SELECT__PIN);
    
   
    lcd_IC_t type = LCD_ST7796;

        delay_ms(120);
        lcd_write_command(0x11);
        delay_ms(120);

        lcd_write_command(0x36);
        lcd_write_data_8bits(0x48);

        lcd_write_command(0x3A);
        lcd_write_data_8bits(0x55);

        lcd_write_command(0xF0);
        lcd_write_data_8bits(0xC3);

        lcd_write_command(0xF0);
        lcd_write_data_8bits(0x96);

        lcd_write_command(0xB4);
        lcd_write_data_8bits(0x01);

        lcd_write_command(0xB7);
        lcd_write_data_8bits(0xC6);

        lcd_write_command(0xC0);
        lcd_write_data_8bits(0xF0);
        lcd_write_data_8bits(0x35);

        lcd_write_command(0xC1);
        lcd_write_data_8bits(0x15);

        lcd_write_command(0xC2);
        lcd_write_data_8bits(0xAF);

        lcd_write_command(0xC3);
        lcd_write_data_8bits(0x09);

        lcd_write_command(0xC5);     //VCOM
        lcd_write_data_8bits(0x06);

        lcd_write_command(0xC6);
        lcd_write_data_8bits(0x00);

        lcd_write_command(0xE8);
        lcd_write_data_8bits(0x40);
        lcd_write_data_8bits(0x8A);
        lcd_write_data_8bits(0x00);
        lcd_write_data_8bits(0x00);
        lcd_write_data_8bits(0x29);
        lcd_write_data_8bits(0x19);
        lcd_write_data_8bits(0xA5);
        lcd_write_data_8bits(0x33);

        lcd_write_command(0xE0);
        lcd_write_data_8bits(0x70);
        lcd_write_data_8bits(0x00);
        lcd_write_data_8bits(0x05);
        lcd_write_data_8bits(0x03);
        lcd_write_data_8bits(0x02);
        lcd_write_data_8bits(0x20);
        lcd_write_data_8bits(0x29);
        lcd_write_data_8bits(0x01);
        lcd_write_data_8bits(0x45);
        lcd_write_data_8bits(0x30);
        lcd_write_data_8bits(0x09);
        lcd_write_data_8bits(0x07);
        lcd_write_data_8bits(0x22);
        lcd_write_data_8bits(0x29);

        lcd_write_command(0xE1);
        lcd_write_data_8bits(0x70);
        lcd_write_data_8bits(0x0C);
        lcd_write_data_8bits(0x10);
        lcd_write_data_8bits(0x0F);
        lcd_write_data_8bits(0x0E);
        lcd_write_data_8bits(0x09);
        lcd_write_data_8bits(0x35);
        lcd_write_data_8bits(0x64);
        lcd_write_data_8bits(0x48);
        lcd_write_data_8bits(0x3A);
        lcd_write_data_8bits(0x14);
        lcd_write_data_8bits(0x13);
        lcd_write_data_8bits(0x2E);
        lcd_write_data_8bits(0x30);

       // lcd_write_command(0x21);

        lcd_write_command(0xF0);
        lcd_write_data_8bits(0xC3);

        lcd_write_command(0xF0);
        lcd_write_data_8bits(0x96);

        delay_ms(120);

        lcd_write_command(0x29);
    
    delay_ms(25);
    // End of display configuration
    // @geeksville board reads back as 0x2, 0x4, 0x94, 0x81, 0xff - a legit ili9481
    write_pulse_duration = 0; // enable fast writes
    
    // Note: if we have some devices still not working, we might need to add a READ command to 0xbf (8.2.39) to read
    // the chip id of the failing units - this would allow us to see the vendor code of whoever made the display and
    // confirm it is a 9481 (or if different - what it is)
    
    // It is worth noting that the display controller has a small amount of non volatile memory.  I bet the mfg of the
    // 850C is checking that code in their firmware, and based on that value chosing to flip the display horizontally
    // if needed (via command 0x36)
    
    // Initialize global structure and set PSET to this.PSET.
    UG_Init(&gui, lcd_pixel_set, DISPLAY_WIDTH, DISPLAY_HEIGHT);
    // Register acceleratos.
    UG_DriverRegister(DRIVER_FILL_FRAME, (void*) HW_FillFrame);
    UG_DriverRegister(DRIVER_DRAW_LINE, (void*) HW_DrawLine);
    UG_DriverRegister(DRIVER_FILL_AREA, (void*) HW_FillArea);   

    //UG_DriverEnable ( DRIVER_FILL_FRAME ) ;
   // UG_DriverEnable ( DRIVER_DRAW_LINE ) ;
   // UG_DriverEnable ( DRIVER_FILL_AREA ) ;
}

Thank you for that. I don't have a build env here, and also not sure how to add detection to the code. Are you considering moving to v20.1c? Would love a patched 850c binary for that if you do

Cheers

[Rydon]

Are you considering moving to v20.1c? Would love a patched 850c binary for that if you do

Cheers

mbrusa already did an 850C version for v20.1C. I have tested it. It works great!

[mctubster]

Are you considering moving to v20.1c? Would love a patched 850c binary for that if you do

Cheers

mbrusa already did an 850C version for v20.1C. I have tested it. It works great!

There is a new version of the 850c that needs a patch to work with any of the current released code bases

[HughF]

Makes very little difference, in fact power mode is slightly better at hill climbing.
Torque mode somehow provides more power at higher cadences with less pressure on the peddles .....................

Think I may try the other fork tomorrow.

I'm going to try the new version by mbrusa later today too - everyone seems to say it is the best one yet.

[casainho]

Makes very little difference, in fact power mode is slightly better at hill climbing.
Torque mode somehow provides more power at higher cadences with less pressure on the peddles .....................

Think I may try the other fork tomorrow.

I'm going to try the new version by mbrusa later today too - everyone seems to say it is the best one yet.

I wish to know more about it as later I would like to update my version and take advantage of the development of the other developers - this is the beauty of OpenSource, many developers improving and testing different paths in parallel

This project did grow a lot, is not only the TSDZ2 motor firmware, now it is:
- TSDZ2 motor firmware
- 860C/SW102 displays firmware
- TSDZ2 wireless hardware + firmware
- TSDZ2 fully wireless remote (with brake sensor connection) hardware + firmware
- Android app
- Cycling GPS wireless displays like Garmin Edge

The fully wireless remote, with brake sensor connection, were finished last week:




And although the Garmin Edge already show EBike speed, battery state, assist level, it does not yet show specific TSDZ2 data like motor current, battery voltage or motor temperature. I am now start developing it and I have initial communications already working by Bluetooth:

[nbdriver]

Hello everyone, i just received my new motor after i broke the shaft on my old one from 2016. But when i try to read the firmware with ST Virtual Programmer to make a backup before flashing, i always have an error "Cannot communicate with the device".

When i try the USB cable on my two other motors it works every time. Is something changed on the new motors ?

My motor has a yellow ring at the speed sensor connector if it helps.

When i turn it on with the VLCD5 it turns on and seem to work (not mounted on the bike).

[casainho]

Hello everyone, i just received my new motor after i broke the shaft on my old one from 2016. But when i try to read the firmware with ST Virtual Programmer to make a backup before flashing, i always have an error "Cannot communicate with the device".

When i try the USB cable on my two other motors it works every time. Is something changed on the new motors ?

My motor has a yellow ring at the speed sensor connector if it helps.

When i turn it on with the VLCD5 it turns on and seem to work (not mounted on the bike).

Maybe the wires on the connector for flash programming changed??

[nbdriver]

Hello everyone, i just received my new motor after i broke the shaft on my old one from 2016. But when i try to read the firmware with ST Virtual Programmer to make a backup before flashing, i always have an error "Cannot communicate with the device".

When i try the USB cable on my two other motors it works every time. Is something changed on the new motors ?

My motor has a yellow ring at the speed sensor connector if it helps.

When i turn it on with the VLCD5 it turns on and seem to work (not mounted on the bike).

Maybe the wires on the connector for flash programming changed??

Thank you casainho as always
That's what i'm wondering... How could i test this without risking the controller ?
Maybe trying to invert Ground ans Swim ?

[casainho]

Thank you casainho as always
That's what i'm wondering... How could i test this without risking the controller ?
Maybe trying to invert Ground ans Swim ?

I don´t know. I would open the motor, take out the motor controller and see...
Or maybe you have the different motor controller version that has a totally different microcontroller??

[nbdriver]

I think after a little bit of reading that i understand what my problem is.... I have the new infineon controller...
i didn't knew there was a new controller available, so now i'm screwed, as i don't want to ride with stock firmware with no voltage indicator, no custom assist levels,....



Maybe we should warn users of this new controller on the Wiki page, because it is going to be more common in the future.

[Chri_Tof]

Hello everyone, i just received my new motor after i broke the shaft on my old one from 2016. But when i try to read the firmware with ST Virtual Programmer to make a backup before flashing, i always have an error "Cannot communicate with the device".

When i try the USB cable on my two other motors it works every time. Is something changed on the new motors ?

My motor has a yellow ring at the speed sensor connector if it helps.

When i turn it on with the VLCD5 it turns on and seem to work (not mounted on the bike).

Maybe its the Motor with the new Controller. You can find out by measuring the voltage between GND and Swim. 5V --> old Controller, 0V --> new Controller. As far as I know, there is actually no way to flash the new Controller.

[Chri_Tof]

I think after a little bit of reading that i understand what my problem is.... I have the new infineon controller...
i didn't knew there was a new controller available, so now i'm screwed, as i don't want to ride with stock firmware with no voltage indicator, no custom assist levels,....

Maybe we should warn users of this new controller on the Wiki page, because it is going to be more common in the future.

Where did you buy the Motor? And which version (6 or 8 pin)? On the german forum we realised that PSW is sending in some cases the old one and in other cases the new one.

https://www.pedelecforum.de/forum/index ... st-1630507

[nbdriver]

I think after a little bit of reading that i understand what my problem is.... I have the new infineon controller...
i didn't knew there was a new controller available, so now i'm screwed, as i don't want to ride with stock firmware with no voltage indicator, no custom assist levels,....

Maybe we should warn users of this new controller on the Wiki page, because it is going to be more common in the future.

Where did you buy the Motor? And which version (6 or 8 pin)? On the german forum we realised that PSW is sending in some cases the old one and in other cases the new one.

https://www.pedelecforum.de/forum/index ... st-1630507

Thank you, i went thru all the posts on the german forum, and yes i have the new controller (6 pin bought at enerprof.de). I also contacted PSWPOWER, and they said the motors that they ship now are 2020 Motors, so i think with the new controller.

So as for today it seems very difficult to order a motor compatible with the OSF, it is a shame... and not good for the people who want to enter in this wonderful project today...

[Chri_Tof]

I think after a little bit of reading that i understand what my problem is.... I have the new infineon controller...
i didn't knew there was a new controller available, so now i'm screwed, as i don't want to ride with stock firmware with no voltage indicator, no custom assist levels,....

Maybe we should warn users of this new controller on the Wiki page, because it is going to be more common in the future.

Where did you buy the Motor? And which version (6 or 8 pin)? On the german forum we realised that PSW is sending in some cases the old one and in other cases the new one.

https://www.pedelecforum.de/forum/index ... st-1630507

Thank you, i went thru all the posts on the german forum, and yes i have the new controller (6 pin bought at enerprof.de). I also contacted PSWPOWER, and they said the motors that they ship now are 2020 Motors, so i think with the new controller.

So as for today it seems very difficult to order a motor compatible with the OSF, it is a shame... and not good for the people who want to enter in this wonderful project today...

I bought a 6 Pin Motor mid February at PSW and I became the old one. Someone at the german forum has bought nearly the same time at PSW a 8 Pin Motor and he became the new one. So maybe there are just selling the last old-6-Pin-Motors. They always say its the new version. I dont think they know about the differences. Enerprof only sell the new ones.

[casainho]

So as for today it seems very difficult to order a motor compatible with the OSF, it is a shame... and not good for the people who want to enter in this wonderful project today...

Buy the old motor controller for 35€ - done!

And please add this information to the wiki!!

[HughF]

I just bought a replacement 6 pin controller from PSWPower on AliExpress, I received an old style one, so they are available.