TSDZ2 EBike wireless standard (like Specialized Turbo Levo) - OpenSource

[rananna]

Edit: Ok looks like if you select assist level 3 - that kills assist until you turn the motor on/off... i'll post a video

My installation does not exhibit this. Assist levels change smoothly without issue

 

[rananna]

Then I will build my remote and be ready to test!! And on next days I hope to have the full control on the wireless board also (power on/off, assist level and battery state).

@ranana, we really need to put all the files on the same repository, as I think the battery SOC will be the same on remote as on the wireless board, like at startup, the LEDs could blink from 1 to 10, long blink on last value, like if 50%, only blink 5 times and the color would be orange... would this work for a user to understand? -- after having this defined, we could trigger at anytime, maybe a button combination or only at startup.

This should be possible.
I need to think about led notifications to be sure they are clear and unobtrusive.
We have quite a few now!

 

[beemac]

Edit: Ok looks like if you select assist level 3 - that kills assist until you turn the motor on/off... i'll post a video

My installation does not exhibit this. Assist levels change smoothly without issue

Is your assist level 3 set to 0.28 in config? Could you try setting to that please?

 

[rananna]

Edit: Ok looks like if you select assist level 3 - that kills assist until you turn the motor on/off... i'll post a video

My installation does not exhibit this. Assist levels change smoothly without issue

Is your assist level 3 set to 0.28 in config? Could you try setting to that please?

No, this is set to 0.028 in config for me.
I set it to .28 and it still worked fine.

 

[beemac]

Then I will build my remote and be ready to test!! And on next days I hope to have the full control on the wireless board also (power on/off, assist level and battery state).

@ranana, we really need to put all the files on the same repository, as I think the battery SOC will be the same on remote as on the wireless board, like at startup, the LEDs could blink from 1 to 10, long blink on last value, like if 50%, only blink 5 times and the color would be orange... would this work for a user to understand? -- after having this defined, we could trigger at anytime, maybe a button combination or only at startup.

This should be possible.
I need to think about led notifications to be sure they are clear and unobtrusive.
We have quite a few now!

A led sequence for power level I like is; fixed off period e.g. 0.1s. Then on period proportional to SOC% (maybe 1s for 100% down to 0.1s for 0%). repeat.

So a full battery is 1s on, 0.1s off -repeat.
Empty battery is a 0.1s on, 0.1s off - repeat.

Looks urgent when it's running out to me!

 

[beemac]

Edit: Ok looks like if you select assist level 3 - that kills assist until you turn the motor on/off... i'll post a video

My installation does not exhibit this. Assist levels change smoothly without issue

Is your assist level 3 set to 0.28 in config? Could you try setting to that please?

No, this is set to 0.028 in config for me.
I set it to .28 and it still worked fine.

How odd... vid shows what's happening to me.. wonder what's different between us - something is!

 

[beemac]

My installation does not exhibit this. Assist levels change smoothly without issue

Is your assist level 3 set to 0.28 in config? Could you try setting to that please?

No, this is set to 0.028 in config for me.
I set it to .28 and it still worked fine.

How odd... vid shows what's happening to me.. wonder what's different between us - something is!

Sorry yes my mistake i meant 0.028

I went and tested again:

* Changing level 4 to 0.028 makes no difference: If 3 is 0.028 it kills assist - if it's not you can select all levels no issue.
* Changing level 2 to 0.028 makes no difference: If 3 is 0.028 it kills assist - if it's not you can select all levels no issue.
* Changing level 3 to 0.027 or 0.029 - you can change levels from 0-7 and back again no problems.
* Change level 3 to 0.028 - when selected it kills assist until motor on/off in all cases for me.

Also if you go into config whilst waiting for motor init - the yellow button never goes green.

 

[beemac]

* Changing level 4 to 0.028 makes no difference: If 3 is 0.028 it kills assist - if it's not you can select all levels no issue.
* Changing level 2 to 0.028 makes no difference: If 3 is 0.028 it kills assist - if it's not you can select all levels no issue.
* Changing level 3 to 0.027 or 0.029 - you can change levels from 0-7 and back again no problems.
* Change level 3 to 0.028 - when selected it kills assist until motor on/off in all cases for me.

I repeated the assist tests with 0.31 apk - and it's the same result.

speed (and i think human assist too, but hard to tell when hand cranking) look much better though - did that issue affect all display numbers?

 

[casainho]

* Changing level 4 to 0.028 makes no difference: If 3 is 0.028 it kills assist - if it's not you can select all levels no issue.
* Changing level 2 to 0.028 makes no difference: If 3 is 0.028 it kills assist - if it's not you can select all levels no issue.
* Changing level 3 to 0.027 or 0.029 - you can change levels from 0-7 and back again no problems.
* Change level 3 to 0.028 - when selected it kills assist until motor on/off in all cases for me.

I repeated the assist tests with 0.31 apk - and it's the same result.

speed (and i think human assist too, but hard to tell when hand cranking) look much better though - did that issue affect all display numbers?

I must say I also had the issue of motor stop assisting but I could never understand when it did happen, I am not having the chance to test on my EBike.

This issue is very strange!! If you can change the assist level on the mobile and see it changing, that means the assist level is really changing on the firmware.

I would say the assist level is 0 and so the motor does not assist.

But is strange that once the system fail, then it does not recovery anymore... The assist levels that were working do not work anymore...

Please try full erase wireless board firmware and flash again. Then, on mobile app, do never enter on the configurations and test all this again. I wonder if the configurations are making anything wrong...

 

[casainho]

@rananna, about the commands over ANT on the remote, why not use instead an no defined page on the standard instead of using incorrectly the standard?
Like use page xxx and that would mean no clash with a commercial button, since it will not anyway send that page.

And thinking on the commercial button, there will be no feedback to user about the motor power on/off, etc, so, I think we should replicate the same feedback on the wireless board, so user can turn on/ff the motor on the wireless board and will get the same feedback. For instance, if user turn motor power on and there is a specific blink, that same blink will happen on both our remote and the wireless board, when using a commercial remote, the blink will then happen only on the wireless board.

If we get the things more consistent, means less different things for the user to memorize and shorter documentation.

 

[rananna]

So everyone is on the same page, the previous comment relates to a Pull Request I gave @casainho yesterday as follows:
@ casainho,
In preparation for modifying the remote control code, I added the following changes to TSDZ2 wireless:

Fixed ANT assist level changing. You can now change the assist level from either a garmin device, the remote control or the android app, and everything updates as it should. I removed the open issue for this.
Added ANT state control communication to the code using the front and rear gearing (p_profile->common.gear_state) I don't think that this will ever be used by anyone, and the byte is a convenient way to communicate with the remote control using ANT page 16. the value of the gearing determines the state of the motor as follows:
front gear 0 - motor off MOTOR_INIT_OFF
front gear 1 - motor on MOTOR_INIT_READY
front gear 2 - motor initializing MOTOR_INIT_GET_MOTOR_ALIVE: & MOTOR_INIT_WAIT_MOTOR_ALIVE
front gear 3 - signal motor on/off
The rear gears are used to communicate error states:
rear gear 1 -MOTOR_INIT_ERROR_ALIVE
rear gear 2- MOTOR_INIT_ERROR_GET_FIRMWARE_VERSION
rear gear 3- MOTOR_INIT_ERROR_FIRMWARE_VERSION
rear gear 4- MOTOR_INIT_ERROR_SET_CONFIGURATIONS
With this communication working, I plan to implement in the remote control next

 

[rananna]

@rananna, about the commands over ANT on the remote, why not use instead an no defined page on the standard instead of using incorrectly the standard?
Like use page xxx and that would mean no clash with a commercial button, since it will not anyway send that page...

I understand your concern. It is often unwise to hack a standard. However, modifying the guts of the ANT LEV protocol to send another page periodically only to the remote is a very complicated undertaking. Adding the new page to the ANT LEV standard is effectively defining a new standard, and this additional page may mess up communication to ANT LEV devices that do not support the new page. I also do not know how to do it.
The far simpler solution for me was to coop the electronic shift control built into the standard to use as state control and error feedback to the remote.
The ant LEV standard was put in place to support all manner of light electric vehicles, not just ebikes. Of course, electronic shifting would be needed for a small ant LEV enabled eCAR, but I don't think it is coming any time soon to ebikes due to the complexity and cost.
For example, if you wanted to add electronic shifting to a standard bike today, adding a Shimano shifter and group set would set you back over $2000!
See https://www.atelierolympia.com/products/shimano-ultegra-r8050-di2-groupset?variant=31109433917504&currency=CAD&utm_medium=product_sync&utm_source=google&utm_content=sag_organic&utm_campaign=sag_organic&utm_campaign=gs-2020-03-23&utm_source=google&utm_medium=smart_campaign&gclid=CjwKCAiAgJWABhArEiwAmNVTB2CQB9EetE-ISF5zx-5FpFcR0Yo2LvQLhmYCY8BpoXMOe6InzCKJwxoCwAcQAvD_BwE
For a hobbiest to modify their TSDZ2 ebike to incorporate e shifting would be prohibitively expensive.
No commercial ebikes to my knowledge incorporate ANT LEV based e shifting, probably for the same reason.
Anyway, that was the reason I chose to use the gear state built into the ANT LEV standard to communicate and control the status of the motor state to the remote.
If anyone has a better solution, please let me know asap.

 

[rananna]

I looked into the $2000 Shimano Di2 shifter some more and see that it was implemented with a private ANT protocol, it does not use ANT LEV at all. So no conflict there.
In fact, I cannot find ANY e shifters currently on the market that support ANT LEV.
I think we are pretty safe in using the front and rear gear control built into the ANT LEV standard for TSDZ2 motor state control
If inexpensive commercially available ANT LEV eshifters become available sonetime in the future we could look into another communication option for the state control at that time.

 

[casainho]

@rananna, about the commands over ANT on the remote, why not use instead an no defined page on the standard instead of using incorrectly the standard?
Like use page xxx and that would mean no clash with a commercial button, since it will not anyway send that page...

I understand your concern. It is often unwise to hack a standard. However, modifying the guts of the ANT LEV protocol to send another page periodically only to the remote is a very complicated undertaking. Adding the new page to the ANT LEV standard is effectively defining a new standard, and this additional page may mess up communication to ANT LEV devices that do not support the new page. I also do not know how to do it.

So, anyway we will need to expand the standard / or not use it as it should, because we need.

I think that being able to add extra or extra pages will give us much more flexibility (you may need even more field in the future development) as also separate very well the standard pages / data and our specific pages / data.

After reading the ANT documentation, I think the devices will just ignore the pages that they do not expect to receive. But since our device is developed by us, we can make it interpret any extra page we send.

I can help you, it is very easy to understand how to add a n extra page:

1. start by copy the ant_lev_page_16.c / ant_lev_page_16.h and rename to your new page number, you will use this exiting files as a template for your new files
1.2 rename the structures and functions names

2. on ant_lev.c file, add you new page on the disp_message_decode()

static void disp_message_decode(ant_lev_profile_t * p_profile, uint8_t * p_message_payload)
{
    const ant_lev_message_layout_t * p_lev_message_payload =
        (ant_lev_message_layout_t *)p_message_payload;

    switch (p_lev_message_payload->page_number)
    {
        case ANT_LEV_PAGE_16:
            ant_lev_page_16_decode(p_lev_message_payload->page_payload,
                                  &(p_profile->page_16));
            break;

        case ANT_LEV_PAGE_XX:
            ant_lev_page_XX_decode(p_lev_message_payload->page_payload,
                                  &(p_profile->page_XX));
            break;

 

[rananna]

So, anyway we will need to expand the standard / or not use it as it should, because we need.

I think that being able to add extra or extra pages will give us much more flexibility (you may need even more field in the future development) as also separate very well the standard pages / data and our specific pages / data.

After reading the ANT documentation, I think the devices will just ignore the pages that they do not expect to receive. But since our device is developed by us, we can make it interpret any extra page we send.

I can help you, it is very easy to understand how to add a n extra page:

1. start by copy the ant_lev_page_16.c / ant_lev_page_16.h and rename to your new page number, you will use this exiting files as a template for your new files
1.2 rename the structures and functions names

2. on ant_lev.c file, add you new page on the disp_message_decode()

Ok, please add this extra page to tsdz2 wireless to implement motor state control and error communications. Once it is working, I can then copy it to the remote control.

 

[casainho]

So, anyway we will need to expand the standard / or not use it as it should, because we need.

I think that being able to add extra or extra pages will give us much more flexibility (you may need even more field in the future development) as also separate very well the standard pages / data and our specific pages / data.

After reading the ANT documentation, I think the devices will just ignore the pages that they do not expect to receive. But since our device is developed by us, we can make it interpret any extra page we send.

I can help you, it is very easy to understand how to add a n extra page:

1. start by copy the ant_lev_page_16.c / ant_lev_page_16.h and rename to your new page number, you will use this exiting files as a template for your new files
1.2 rename the structures and functions names

2. on ant_lev.c file, add you new page on the disp_message_decode()

Ok, please add this extra page to tsdz2 wireless to implement motor state control and error communications. Once it is working, I can then copy it to the remote control.

Sorry but I am busy on next days. It will be easier for you to add the things step by step and debug / validate. On the remote side that you are more familiar, you can even start by just changing the page number from 16 to XX:

        static uint8_t p_message_payload[ANT_STANDARD_DATA_PAYLOAD_SIZE] = {
            ANT_LEV_PAGE_16,

to

        static uint8_t p_message_payload[ANT_STANDARD_DATA_PAYLOAD_SIZE] = {
            ANT_LEV_PAGE_XX,

and then use the SIMULANT to check that you are receiving that "new" page. After, replicate page16 and rename to that XX

- buttons_send_page16(): you can use this function as a template, copy it to send_page_xx()
- after setup the data you want to send, just like on buttons_send_page16(), call the sd_ant_acknowledge_message_tx() and that new page will be sent:

        ant_lev_page_16_encode(p_lev_message_payload->page_payload,
                               &(p_profile->page_16));

        uint32_t err_code;
        err_code = sd_ant_acknowledge_message_tx(p_profile->channel_number, sizeof(p_message_payload), p_message_payload);
        if (err_code != 0)
        {
            nrf_delay_ms(50);
        }

 

[rananna]

Sorry but I am busy on next days. It will be easier for you to add the things step by step and debug / validate. On the remote side that you are more familiar, you can even start by just changing the page number from 16 to XX:

@casaiho,
Currently, we have a hack that is working, and before I abandon it to implement another approach, I need to believe it has some chance of success, and right now I am not there.
It seems to be that either you follow the ANT LEV standard or you make a new custom protocol
I still do not see how adding a new page to the ANT LEV standard can work.
Ie: You mention using SIMULANT with a new page no. However, simulant has to be set up as a ANT LEV device to simulate communication with TSDZ2 wireless.
There will be no possibility to add an extra page to SIMULANT as only the ANT LEV standard pages are available for use.
We could possibly set up a custom ANT+ protocol to add a new page to TSDZ2 wireless that is ANT LEV + the new added page.
However, a custom ANT+ protocol on tsdz2 wireless would involve changing CHAN_ID_TRANS_TYPE from 5 to a new # and we would lose ANT LEV compatibility with garmins and other ANT LEV displays.

Could you please explain to me how the new page will maintain compatibility with the ANT LEV standard?

 

[rananna]

Just a thought - if your concern is that I am using the gearing fields that might have some utility in the future for the hack, I could instead use the regenerative assist levels defined in the ANT LEV standard.
These will certainly never be used in future for ebikes.
If your concern is a philosophical one that we must always use a standard as it is written, then we will have to find a way to make the extra page work.

 

[casainho]

@casaiho,
Currently, we have a hack that is working, and before I abandon it to implement another approach, I need to believe it has some chance of success, and right now I am not there.

Ok, I see.

Could you please explain to me how the new page will maintain compatibility with the ANT LEV standard?

My expectation is that the device will ignore any page that is outside of the profile - I have this expectation after reading the ANT+ documents.

Ok, I forgot that SIMULANT may not work as it may filter out pages outside of the profile... because if it could, would be easier to debug / validate and go by small steps.

Could you please explain to me how the new page will maintain compatibility with the ANT LEV standard?

I think that is not possible at all but If is like I think that the devices will filter out pages outside of the profile, then regular devices will simple ignore it and keep working, like if this change has no big impact.

My concern is philosophical because I think will be easier to understand, document, our specific changes if they are contained on a unique page. But first, the important is to have something working and being able to test it, so I agree with you.

 

[rananna]

My concern is philosophical because I think will be easier to understand, document, our specific changes if they are contained on a unique page. But first, the important is to have something working and being able to test it, so I agree with you.

so, how about this as a compromise.
I will use the existing gearing hack with the remote control to get it all working for now.
I will also add an issue to TSDZ2 wireless to add an extra page to ANT LEV .
When time permits, I will test this to see if it works, and if it does, remove the hack.

Do you agree?

 

[casainho]

My concern is philosophical because I think will be easier to understand, document, our specific changes if they are contained on a unique page. But first, the important is to have something working and being able to test it, so I agree with you.

so, how about this as a compromise.
I will use the existing gearing hack with the remote control to get it all working for now.
I will also add an issue to TSDZ2 wireless to add an extra page to ANT LEV to see if it all works.
When time permits, I will test this to see if it works, and if it does, remove the hack.

Do you agree?

I agree and probably implement the new page will not be the priority for some months

I am currently building a wireless board to debug the issue of assist level 3...

 

[rananna]

I agree and probably implement the new page will not be the priority for some months

I am currently building a wireless board to debug the issue of assist level 3...

Great! Issue added:

Add New ANT LEV page #33 Open
rananna opened this issue now · 0 comments
rananna commented now
Add a new ANT LEV page to communicate motor state information to the remote control.
Test to confirm that the new page does not interfere with normal ANT LEV communication with other devices

Good luck with the assist 3 issue - looks subtle....
I will work on getting the remote working with state control and LED signaling this week.

 

[beemac]

I am currently building a wireless board to debug the issue of assist level 3...

Since rananna didn't have the issue - I'll not erase mine in case it's useful for helping pin down the problem. I assume debugging is via SWD only? I might have some time later so I'll look into setting up everything to allow me to debug...

I went out for a little ride at lunchtime - all working fine - speed display much better. Human Power is still very high though... Do I need to recalibrate torque/battery resistance etc. with the new app - or are those settings stored in the motor controller?

 

[casainho]

I am currently building a wireless board to debug the issue of assist level 3...

Since rananna didn't have the issue - I'll not erase mine in case it's useful for helping pin down the problem. I assume debugging is via SWD only? I might have some time later so I'll look into setting up everything to allow me to debug...

I can not find the issue. The following code works as expected and I can see rt_vars.ui16_assist_level_factor[] working as expected, always sending the 0.028 or others values...

void rt_send_tx_package(frame_type_t type) {
    case FRAME_TYPE_PERIODIC:
      if (rt_vars.ui8_walk_assist) {
        ui8_usart1_tx_buffer[3] = (uint8_t) rt_vars.ui8_walk_assist_level_factor[((rt_vars.ui8_assist_level) - 1)];
        ui8_usart1_tx_buffer[4] = 0;
      } else if (rt_vars.ui8_assist_level) {
        uint16_t ui16_temp = rt_vars.ui16_assist_level_factor[((rt_vars.ui8_assist_level) - 1)];
        ui8_usart1_tx_buffer[3] = (uint8_t) (ui16_temp & 0xff);
        ui8_usart1_tx_buffer[4] = (uint8_t) (ui16_temp >> 8);
      } else {
        // if rt_vars.ui8_assist_level = 0, send 0!! always disable motor when assist level is 0
        ui8_usart1_tx_buffer[3] = 0;
        ui8_usart1_tx_buffer[4] = 0;
      }

I went out for a little ride at lunchtime - all working fine - speed display much better. Human Power is still very high though... Do I need to recalibrate torque/battery resistance etc. with the new app - or are those settings stored in the motor controller?

The calibration values are stored only on the TSDZ2 wireless board and on your 860C display - go there and grab that values.

 

[beemac]

I can not find the issue. The following code works as expected and I can see rt_vars.ui16_assist_level_factor[] working as expected, always sending the 0.028 or others values...

void rt_send_tx_package(frame_type_t type) {
    case FRAME_TYPE_PERIODIC:
      if (rt_vars.ui8_walk_assist) {
        ui8_usart1_tx_buffer[3] = (uint8_t) rt_vars.ui8_walk_assist_level_factor[((rt_vars.ui8_assist_level) - 1)];
        ui8_usart1_tx_buffer[4] = 0;
      } else if (rt_vars.ui8_assist_level) {
        uint16_t ui16_temp = rt_vars.ui16_assist_level_factor[((rt_vars.ui8_assist_level) - 1)];
        ui8_usart1_tx_buffer[3] = (uint8_t) (ui16_temp & 0xff);
        ui8_usart1_tx_buffer[4] = (uint8_t) (ui16_temp >> 8);
      } else {
        // if rt_vars.ui8_assist_level = 0, send 0!! always disable motor when assist level is 0
        ui8_usart1_tx_buffer[3] = 0;
        ui8_usart1_tx_buffer[4] = 0;
      }

What happens at motor on/off? - do any assist values get rewritten anywhere? I wondered if memory was being corrupted (e.g. zeroing the assist_level_factor array) that was refreshed during motor on/off... but I should probably try to get my head around how things fit together first from a control point of view before I make wild suggestions!

I went out for a little ride at lunchtime - all working fine - speed display much better. Human Power is still very high though... Do I need to recalibrate torque/battery resistance etc. with the new app - or are those settings stored in the motor controller?

The calibration values are stored only on the TSDZ2 wireless board and on your 860C display - go there and grab that values.

Ok cool thanks, will do.