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

[casainho]

@casainho,
For the remote I fixed the latest bugs , updated the docs and submitted a release candidate Pull request for your testing.

@casainho & @rannanna

I had a bit of time today and thought it would be nice to actually write some code instead of copy pasting and bug fixing! I wanted to put some led control in the wireless controller - as it would be really useful when running headless or if the phone is in your pocket (and you don't have a remote of course!). I didn't want the led sequences to block - so I've knocked up a simple led sequence player that can be clocked at whatever rate we want. It works ok - but haven't done a pull request as it needs a bit more testing - and I need to create all the sequence definitions from rananna's docs.

https://github.com/4var1/TSDZ2_wireless/blob/led-alert/EBike_wireless_TSDZ2/firmware/ledalert.c

You can queue up led sequences with a single call - and let it get on with it.

If I get some more time later I'll post an exciting video...

NRF SDK already has a queue library, did you check it?

Also we need to set LED PWM value and not only on and off, because for instance the green LED is to strong - it is hard to the eyes, I really need to less strong, maybe half of the power. For example current blink for assist level seems like a flash but I wish it to be half that strong but twice the time.

Also I would like to understand the power impact -- the TSDZ2 wireless firmware should follow the same ideas as the remote, to save power.

 

[beemac]

@casainho,
For the remote I fixed the latest bugs , updated the docs and submitted a release candidate Pull request for your testing.

@casainho & @rannanna

I had a bit of time today and thought it would be nice to actually write some code instead of copy pasting and bug fixing! I wanted to put some led control in the wireless controller - as it would be really useful when running headless or if the phone is in your pocket (and you don't have a remote of course!). I didn't want the led sequences to block - so I've knocked up a simple led sequence player that can be clocked at whatever rate we want. It works ok - but haven't done a pull request as it needs a bit more testing - and I need to create all the sequence definitions from rananna's docs.

https://github.com/4var1/TSDZ2_wireless/blob/led-alert/EBike_wireless_TSDZ2/firmware/ledalert.c

You can queue up led sequences with a single call - and let it get on with it.

If I get some more time later I'll post an exciting video...

NRF SDK already has a queue library, did you check it?

Also we need to set LED PWM value and not only on and off, because for instance the green LED is to strong - it is hard to the eyes, I really need to less strong, maybe half of the power. For example current blink for assist level seems like a flash but I wish it to be half that strong but twice the time.

Also I would like to understand the power impact -- the TSDZ2 wireless firmware should follow the same ideas as the remote, to save power.

rananna stopped using pwm because there was an issue with it - I'm using the same method he is now to illuminate the LED. I can look to add brightness if it's available.

I looked in the SDk for any LED examples but didn't see anything obvious except the softblink libs that rananna has also discounted. What sample are you referring to?

 

[casainho]

rananna stopped using pwm because there was an issue with it - I'm using the same method he is now to illuminate the LED. I can look to add brightness if it's available.

I looked in the SDk for any LED examples but didn't see anything obvious except the softblink libs that rananna has also discounted. What sample are you referring to?

It is unfortunate we can not use PWM low power. Can you give a look at it, maybe @rananna missed something?

And I was talking to this: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_queue.html?cp=7_5_0_3_36

 

[beemac]

@casainho,
For the remote I fixed the latest bugs , updated the docs and submitted a release candidate Pull request for your testing.

@casainho & @rannanna

I had a bit of time today and thought it would be nice to actually write some code instead of copy pasting and bug fixing! I wanted to put some led control in the wireless controller - as it would be really useful when running headless or if the phone is in your pocket (and you don't have a remote of course!). I didn't want the led sequences to block - so I've knocked up a simple led sequence player that can be clocked at whatever rate we want. It works ok - but haven't done a pull request as it needs a bit more testing - and I need to create all the sequence definitions from rananna's docs.

https://github.com/4var1/TSDZ2_wireless/blob/led-alert/EBike_wireless_TSDZ2/firmware/ledalert.c

You can queue up led sequences with a single call - and let it get on with it.

If I get some more time later I'll post an exciting video...

NRF SDK already has a queue library, did you check it?

Also we need to set LED PWM value and not only on and off, because for instance the green LED is to strong - it is hard to the eyes, I really need to less strong, maybe half of the power. For example current blink for assist level seems like a flash but I wish it to be half that strong but twice the time.

Also I would like to understand the power impact -- the TSDZ2 wireless firmware should follow the same ideas as the remote, to save power.

rananna stopped using pwm because there was an issue with it - I'm using the same method he is now to illuminate the LED. I can look to add brightness if it's available.

I looked in the SDk for any LED examples but didn't see anything obvious except the softblink libs that rananna has also discounted. What sample are you referring to?

Looking at some of the comments in the nrf lib we're both using - looks like if you want anything other than red LED it's going to be a power drain on the remote:

static void bsp_board_leds_init(void)
{
#if defined(BOARD_PCA10059)
// If nRF52 USB Dongle is powered from USB (high voltage mode),
// GPIO output voltage is set to 1.8 V by default, which is not
// enough to turn on green and blue LEDs. Therefore, GPIO voltage
// needs to be increased to 3.0 V by configuring the UICR register.
if (NRF_POWER->MAINREGSTATUS &
(POWER_MAINREGSTATUS_MAINREGSTATUS_High << POWER_MAINREGSTATUS_MAINREGSTATUS_Pos))
{
gpio_output_voltage_setup();
}
#endif

 

[beemac]

rananna stopped using pwm because there was an issue with it - I'm using the same method he is now to illuminate the LED. I can look to add brightness if it's available.

I looked in the SDk for any LED examples but didn't see anything obvious except the softblink libs that rananna has also discounted. What sample are you referring to?

It is unfortunate we can not use PWM low power. Can you give a look at it, maybe @rananna missed something?

And I was talking to this: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_queue.html?cp=7_5_0_3_36

Ah ok - yes I use a very simple implementation of a ring buffer in my code - like the one I stuck on the motor RX ISR. Not sure it's worth using that one instead - it's about three lines of code it would replace!

i think rananna opened a case with nordic about the pwm conflict with the softdevice - he didn't remove it lightly - had spent a lot of time on it.

 

[beemac]

rananna stopped using pwm because there was an issue with it - I'm using the same method he is now to illuminate the LED. I can look to add brightness if it's available.

I looked in the SDk for any LED examples but didn't see anything obvious except the softblink libs that rananna has also discounted. What sample are you referring to?

It is unfortunate we can not use PWM low power. Can you give a look at it, maybe @rananna missed something?

And I was talking to this: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_queue.html?cp=7_5_0_3_36

Ah ok - yes I use a very simple implementation of a ring buffer in my code - like the one I stuck on the motor RX ISR. Not sure it's worth using that one instead - it's about three lines of code it would replace!

i think rananna opened a case with nordic about the pwm conflict with the softdevice - he didn't remove it lightly - had spent a lot of time on it.

pwm aside if we want to show led sequences without blocking - I think this is a reasonably good solution - certainly for the controller.

I neatened up the header so it's easier to see how to define the sequences.

https://github.com/4var1/TSDZ2_wire...ke_wireless_TSDZ2/firmware/include/ledalert.h

 

[rananna]

rananna stopped using pwm because there was an issue with it - I'm using the same method he is now to illuminate the LED. I can look to add brightness if it's available.

I looked in the SDk for any LED examples but didn't see anything obvious except the softblink libs that rananna has also discounted. What sample are you referring to?

It is unfortunate we can not use PWM low power. Can you give a look at it, maybe @rananna missed something?

And I was talking to this: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_queue.html?cp=7_5_0_3_36

Yes, I was unhappy to lose the power saving features of PWM in the latest release candidate.
The nordic library is buggy when used with a softdfevice, and doesn't play well with interrupts.
It is too complex for our needs.
But all is not lost.
I think we are over-complicating the problem by using the PWM library
The reason PWM works is by creating the perception of a dimmer light by quickly flashing the LED on and off.
In the lastest release I have a simple function to quickly flash the led upon connection (to the motor, and ANT) that looks like this:

void fast_flash(uint8_t led_idx)
{
  //quickly flash led if at limits
  for (int i = 0; i < 10; i++)
  {
    bsp_board_led_on(led_idx);
    nrf_delay_ms(10);
    bsp_board_led_off(led_idx);
    nrf_delay_ms(100);
  }
}

I think that we simply need to create another led driver function with a 50% duty cycle (for 1/2 pwr and brightness) using a timer, and reduce the delay so that the perception of flicker is lost. (it will simply look dimmer. as it is flashing so fast)
In other words, a much simpler pwm implementation.

This approach can works in the remote as we only have a three use cases;
1. LED Fast flash (10 flashes/sec) for 'x' ms
2. LED slow flash (two flashes/sec) for 'y' ms
3. LED full on for 'z' ms
x,y,z are variable times depending on use case
If we implement the homemade PWM on/off code for each of these cases it will both reduce power and decrease brightness.
this will eliminate any softdevice conflicts and work well with button interrupts.

thoughts?

 

[beemac]

rananna stopped using pwm because there was an issue with it - I'm using the same method he is now to illuminate the LED. I can look to add brightness if it's available.

I looked in the SDk for any LED examples but didn't see anything obvious except the softblink libs that rananna has also discounted. What sample are you referring to?

It is unfortunate we can not use PWM low power. Can you give a look at it, maybe @rananna missed something?

And I was talking to this: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_queue.html?cp=7_5_0_3_36

Yes, I was unhappy to lose the power saving features of PWM in the latest release candidate.
The nordic library is buggy when used with a softdfevice, and doesn't play well with interrupts.
It is too complex for our needs.
But all is not lost.
I think we are over-complicating the problem by using the PWM library
The reason PWM works is by creating the perception of a dimmer light by quickly flashing the LED on and off.
In the lastest release I have a simple function to quickly flash the led upon connection (to the motor, and ANT) that looks like this:

void fast_flash(uint8_t led_idx)
{
  //quickly flash led if at limits
  for (int i = 0; i < 10; i++)
  {
    bsp_board_led_on(led_idx);
    nrf_delay_ms(10);
    bsp_board_led_off(led_idx);
    nrf_delay_ms(100);
  }
}

I think that we simply need to create another led driver function with a 50% duty cycle (for 1/2 pwr and brightness) using a timer, and reduce the delay so that the perception of flicker is lost. (it will simply look dimmer. as it is flashing so fast)
In other words, a much simpler pwm implementation.

This approach can works in the remote as we only have a three use cases;
1. LED Fast flash (10 flashes/sec) for 'x' ms
2. LED slow flash (two flashes/sec) for 'y' ms
3. LED full on for 'z' ms
x,y,z are variable times depending on use case
If we implement the homemade PWM on/off code for each of these cases it will both reduce power and decrease brightness.
this will eliminate any softdevice conflicts and work well with button interrupts.

thoughts?

If that's all you need then maybe what I've done is too complex but it's pretty compact and does allow you to do what you need quite easily and without blocking whilst you show a sequence. I was thinking to implement more error codes on the controller for instance if brake sensors aren't connected, or temperature is exceeded as two examples. The more I think about it - the more I like 'headless mode' so thinking about how to still give almost complete feedback without a display at all..

{LED_RED,WAIT_MS(1000),LED_GREEN,WAIT_MS(1000),LED_BLUE,WAIT_MS(1000),LED_OFF,WAIT_MS(1000),LED_END_SEQUENCE,LED_END_SEQUENCE},         //LED_SEQUENCE_TEST_MESSAGE

    {LED_BLUE,WAIT_MS(50),LED_OFF,WAIT_MS(50),LED_REPEAT_LASTX,CMDS_RPT(2,10),LED_END_SEQUENCE,LED_END_SEQUENCE},                           //LED_SEQUENCE_BLUE_FLASH10

    {LED_GREEN,WAIT_MS(50),LED_OFF,WAIT_MS(50),LED_REPEAT_LASTX,CMDS_RPT(2,10),LED_END_SEQUENCE,LED_END_SEQUENCE},                          //LED_SEQUENCE_GREEN_FLASH10

    {LED_BLUE,WAIT_MS(250),LED_RED,WAIT_MS(250),LED_MAGENTA,WAIT_MS(250),LED_GREEN,WAIT_MS(250),LED_CYAN,WAIT_MS(250),LED_YELLOW,WAIT_MS(250),
    LED_WHITE,WAIT_MS(250),LED_REPEAT_LASTX,CMDS_RPT(7,2),LED_OFF,WAIT_MS(50),LED_END_SEQUENCE,LED_END_SEQUENCE}                            //LED_SEQUENCE_SPECTRUM.

 

[casainho]

Low-power PWM library
The low-power pulse-width modulation (PWM) library provides functions to generate a pulse-width modulated output signal while using minimal power. The signal can be used, for example, to change the intensity or the color of LEDs.

This library uses an application timer and is therefore not very accurate. It can be used to control, for example, LEDs, but for peripherals that need a high accuracy, you should use the PWM library instead.

@rananna, maybe you could use one app timer with frequency of 10x, so to have 10% duty_cycle, the LED would be on only 1 cycle interrupt from the 10 cycles, and so on.

 

[beemac]

My STLink-v2 is setup for flashing the TSDZ2 via Speed sensor connection.

Is it possible to make the nRF52840 dongle flash connection via this connector, I.E. is the SWDIO and SWDCLK pins available. My STLink-v2 is in a shrink-wrap, so can not see wiring. Thinking NO. So I will be opening up the shrink-wrap.

Ebike_wireless_bootloader-schematic.png

P.S. I have asked this question to ECO-Bike will reply with answer

I don't really understand the question - you don't flash anything to do with the nrf with that connector...

Read the docs for the Open Source firmware first if you haven't already flashed your motor.

Mine is enclosed with heat shrink so don't know the pinout. We do use it to flash the boot loader to both nRF52840s do we not?

20210208_133032.jpg
ECO-Cycles reply: for anyone else that may have this STLink-V2
"Hi,
It's just the 3.3v, GND, and SWIM.
We used to do the 5v, GND, SWIM, and RST, but the above works more reliably.
Here is the wiring colors for the 6 pin line:
brown: 3.3v-5V (VCC)
black: SWIM
orange: ROUND (GND)
red/purple: RESET (RST) - NOT USED
green: headlight 6V – NOT USED
white/yellow : speed sensor input – NOT USED"

Ok - so that cable is setup for flashing the motor controller that uses SWIM/GND - you need to get at the SWCLK/SWDIO pins that a standard stlinkv2 clone also has to flash the nrf. See the pictures in the docs.

 

[casainho]

I was thinking to implement more error codes on the controller for instance if brake sensors aren't connected, or temperature is exceeded as two examples. The more I think about it - the more I like 'headless mode' so thinking about how to still give almost complete feedback without a display at all..

Be careful with to many options - just recently a new user told the remote instructions were confuse with the information for current options.
Maybe would be better a LED signal for a general error and so user should connect the phone and see more details about the error.

Even myself on the Garmin Edge, when I saw that signal about possible motor over temperature and I could not understand what was that and I did not find anywhere on Internet - that gave me a frustration feeling about the Garmin Edge!!

I am now thinking more about how LEV defines the things to be simple for user understand, like maybe would be better to have as default a field showing percentage of motor power where 100% is the max value on the configurations - If I would do today the 860C and SW102 firmware. The same for the current, temperature and so on. There is a lot of things to do, on the mobile app and the Garmin CIQ fields...

 

[beemac]

I was thinking to implement more error codes on the controller for instance if brake sensors aren't connected, or temperature is exceeded as two examples. The more I think about it - the more I like 'headless mode' so thinking about how to still give almost complete feedback without a display at all..

Be careful with to many options - just recently a new user told the remote instructions were confuse with the information for current options.
Maybe would be better a LED signal for a general error and so user should connect the phone and see more details about the error.

Even myself on the Garmin Edge, when I saw that signal about possible motor over temperature and I could not understand what was that and I did not find anywhere on Internet - that gave me a frustration feeling about the Garmin Edge!!

I am now thinking more about how LEV defines the things to be simple for user understand, like maybe would be better to have as default a field showing percentage of motor power where 100% is the max value on the configurations - If I would do today the 860C and SW102 firmware. The same for the current, temperature and so on. There is a lot of things to do, on the mobile app and the Garmin CIQ fields...

Ok but there are still times when you need immediate feedback - and having to get a phone out is not really immediate but I get that we don't want to make it too complex.

I was really aiming to overcome the thread blocking whilst showing a sequence or even single led flash - and that's what I've solved. It also allows more complex led sequences - but that's a bonus!

I've yet to get any fancy devices so the ANT/LEV side of things doesn't really interest me at the moment. It's the mix of coding, building bikes and being able to ride further and faster that I like!

 

[rananna]

Low-power PWM library
The low-power pulse-width modulation (PWM) library provides functions to generate a pulse-width modulated output signal while using minimal power. The signal can be used, for example, to change the intensity or the color of LEDs.

This library uses an application timer and is therefore not very accurate. It can be used to control, for example, LEDs, but for peripherals that need a high accuracy, you should use the PWM library instead.

@rananna, maybe you could use one app timer with frequency of 10x, so to have 10% duty_cycle, the LED would be on only 1 cycle interrupt from the 10 cycles, and so on.

Yes, that is what I was recommending in my previous post regarding the alternative pwm technique.
I will try it and see how it works

 

[beemac]

Low-power PWM library
The low-power pulse-width modulation (PWM) library provides functions to generate a pulse-width modulated output signal while using minimal power. The signal can be used, for example, to change the intensity or the color of LEDs.

This library uses an application timer and is therefore not very accurate. It can be used to control, for example, LEDs, but for peripherals that need a high accuracy, you should use the PWM library instead.

@rananna, maybe you could use one app timer with frequency of 10x, so to have 10% duty_cycle, the LED would be on only 1 cycle interrupt from the 10 cycles, and so on.

Yes, that is what I was recommending in my previous post regarding the alternative pwm technique.
I will try it and see how it works

* A long press of the [**POWER**] key will turn the motor ON or OFF. A **WHITE** LED will start flashing, and will continue flashing until the motor is on, at which time a **BLUE** LED will briefly flash. If the motor is turning off,

Would be nice if this matched the app - how about 5 yellow flashes - then 5 green flashes when motor connects?

 

[rananna]

Low-power PWM library
The low-power pulse-width modulation (PWM) library provides functions to generate a pulse-width modulated output signal while using minimal power. The signal can be used, for example, to change the intensity or the color of LEDs.

This library uses an application timer and is therefore not very accurate. It can be used to control, for example, LEDs, but for peripherals that need a high accuracy, you should use the PWM library instead.

@rananna, maybe you could use one app timer with frequency of 10x, so to have 10% duty_cycle, the LED would be on only 1 cycle interrupt from the 10 cycles, and so on.

Yes, that is what I was recommending in my previous post regarding the alternative pwm technique.
I will try it and see how it works

* A long press of the [**POWER**] key will turn the motor ON or OFF. A **WHITE** LED will start flashing, and will continue flashing until the motor is on, at which time a **BLUE** LED will briefly flash. If the motor is turning off,

Would be nice if this matched the app - how about 5 yellow flashes - then 5 green flashes when motor connects?

Sure, I will add it to the development plans.
After this last weekend's episode, I plan to only update the repo infrequently, and then only after extensive testing.

 

[casainho]

@rananna, I think I was able to install the Garmin CIQ SDK: https://www.youtube.com/watch?v=Lm3NHhUGvJU


And do you know that now we are able to open an app while on an activity? this means an EBike app could be developed to control TSDZ2:


And I was able to created a new project but something is failing on compiling, still, the SDK was installed on /home/user/.Garmin/ConnectIQ

 

[rananna]

@rananna, I think I was able to install the Garmin CIQ SDK: https://www.youtube.com/watch?v=Lm3NHhUGvJU


And do you know that now we are able to open an app while on an activity? this means an EBike app could be developed to control TSDZ2:


And I was able to created a new project but something is failing on compiling, still, the SDK was installed on /home/user/.Garmin/ConnectIQ

I was stalled at installing the sdk.
When I launched the sdkmanager in ubuntu I get the following window that cannot be resized and I am stuck.

I had to install the sdk in windows and use eclipse.

 

[Tiger_one]

Wish I could help, but just not experienced enough. I'm sure you have seen the info on "WAVE COUNTER" in https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Fpwm.html.

15bit register for 4 PWM channels.

I'll try and hush now.

 

[beemac]

* A long press of the [**POWER**] key will turn the motor ON or OFF. A **WHITE** LED will start flashing, and will continue flashing until the motor is on, at which time a **BLUE** LED will briefly flash. If the motor is turning off,

Would be nice if this matched the app - how about 5 yellow flashes - then 5 green flashes when motor connects?

Sure, I will add it to the development plans.
After this last weekend's episode, I plan to only update the repo infrequently, and then only after extensive testing.

I'm getting there - have tried to follow your instructions - but have added some new ones. Is easy to change the sequences - I'm more finding what the right triggers are in the code.

Wireless controller on - blue flash
Bluetooth connection successful - blue flash x 5
Motor on start - yellow flash x 5 (yellow does look very green however as the red led isn't as bright)
Motor ready - green flash x 2 + green long flash
assist up/down - green flash (or red flash if at limits)
Walk assist - blue flashing (I need to tune this - too many get queued up - so takes a few secs to clear when stopped) - also think blue should be for bluetooth messages only perhaps.
Bluetooth connection lost - blue flash x2 + red long flash
Power off - red flash x 2, red long flash

[youtube]r3JArxrrf9w[/youtube]

 

[casainho]

Wish I could help, but just not experienced enough. I'm sure you have seen the info on "WAVE COUNTER" in https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Fpwm.html.

15bit register for 4 PWM channels.

I'll try and hush now.

The idea is to use the PWM low power mode, it exists as they provide on their library: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Flib_low_power_pwm.html

 

[casainho]

Wireless controller on - blue flash
Bluetooth connection successful - blue flash x 5
Motor on start - yellow flash x 5 (yellow does look very green however as the red led isn't as bright)
Motor ready - green flash x 2 + green long flash
assist up/down - green flash (or red flash if at limits)
Walk assist - blue flashing (I need to tune this - too many get queued up - so takes a few secs to clear when stopped) - also think blue should be for bluetooth messages only perhaps.
Bluetooth connection lost - blue flash x2 + red long flash
Power off - red flash x 2, red long flash

* Bluetooth connection successful - not needed as the user has the same feedback on the mobile phone
* Bluetooth connection lost - not needed as the user has the same feedback on the mobile phone

And I will only accept a pull request with that code IF is the same for the wireless remote.

 

[beemac]

Wireless controller on - blue flash
Bluetooth connection successful - blue flash x 5
Motor on start - yellow flash x 5 (yellow does look very green however as the red led isn't as bright)
Motor ready - green flash x 2 + green long flash
assist up/down - green flash (or red flash if at limits)
Walk assist - blue flashing (I need to tune this - too many get queued up - so takes a few secs to clear when stopped) - also think blue should be for bluetooth messages only perhaps.
Bluetooth connection lost - blue flash x2 + red long flash
Power off - red flash x 2, red long flash

* Bluetooth connection successful - not needed as the user has the same feedback on the mobile phone
* Bluetooth connection lost - not needed as the user has the same feedback on the mobile phone

And I will only accept a pull request with that code IF is the same for the wireless remote.

I am currently using the same method to light the LED - and that is easy to change if we find a lower power way of doing it.

I can't use rananna's method for sequences in the controller as it blocks the thread - which is ok on the remote as all processing is interrupt driven but on the wireless controller a pause for 250ms (for instance) whilst showing a LED is not acceptable.

 

[rananna]

Wireless controller on - blue flash
Bluetooth connection successful - blue flash x 5
Motor on start - yellow flash x 5 (yellow does look very green however as the red led isn't as bright)
Motor ready - green flash x 2 + green long flash
assist up/down - green flash (or red flash if at limits)
Walk assist - blue flashing (I need to tune this - too many get queued up - so takes a few secs to clear when stopped) - also think blue should be for bluetooth messages only perhaps.
Bluetooth connection lost - blue flash x2 + red long flash
Power off - red flash x 2, red long flash

* Bluetooth connection successful - not needed as the user has the same feedback on the mobile phone
* Bluetooth connection lost - not needed as the user has the same feedback on the mobile phone

And I will only accept a pull request with that code IF is the same for the wireless remote.

I am currently using the same method to light the LED - and that is easy to change if we find a lower power way of doing it.

I can't use rananna's method for sequences in the controller as it blocks the thread - which is ok on the remote as all processing is interrupt driven but on the wireless controller a pause for 250ms (for instance) whilst showing a LED is not acceptable.

I am testing a simplified PWM technique that uses a timer, and so far it is testing well.
I have found that a 20% duty cycle (20% on time) with a 10 millisecond cycle time is still very visible and give no perception of flicker. This means 20% of the power consumption!
Further, I can reduce the green led duty cycle to 10% to get the same apparent brightness as red and blue as it is much brighter.

I want to implement it into the code and test thoroughly.
@casainho, I will probably give you a PR tomorrow for this.

 

[beemac]

Wireless controller on - blue flash
Bluetooth connection successful - blue flash x 5
Motor on start - yellow flash x 5 (yellow does look very green however as the red led isn't as bright)
Motor ready - green flash x 2 + green long flash
assist up/down - green flash (or red flash if at limits)
Walk assist - blue flashing (I need to tune this - too many get queued up - so takes a few secs to clear when stopped) - also think blue should be for bluetooth messages only perhaps.
Bluetooth connection lost - blue flash x2 + red long flash
Power off - red flash x 2, red long flash

* Bluetooth connection successful - not needed as the user has the same feedback on the mobile phone
* Bluetooth connection lost - not needed as the user has the same feedback on the mobile phone

And I will only accept a pull request with that code IF is the same for the wireless remote.

I am currently using the same method to light the LED - and that is easy to change if we find a lower power way of doing it.

I can't use rananna's method for sequences in the controller as it blocks the thread - which is ok on the remote as all processing is interrupt driven but on the wireless controller a pause for 250ms (for instance) whilst showing a LED is not acceptable.

I am testing a simplified PWM technique that uses a timer, and so far it is testing well.
I have found that a 20% duty cycle (20% on time) with a 10 millisecond cycle time is still very visible and give no perception of flicker. This means 20% of the power consumption!
Further, I can reduce the green led duty cycle to 10% to get the same apparent brightness as red and blue as it is much brighter.

I want to implement it into the code and test thoroughly.
@casainho, I will probably give you a PR tomorrow for this.

Ah that's good - and really handy that you can get green to have more balanced brightness.

@casainho - I don't see how we can have anything other than something like what I've written in the controller code. Either we need a separate state machine for each led event - to turn on/off or whatever - or we use something like i've put together that manages the state when clocked. We can't just turn on leds, wait, turn off etc. that's not going to work.

 

[casainho]

@casainho - I don't see how we can have anything other than something like what I've written in the controller code. Either we need a separate state machine for each led event - to turn on/off or whatever - or we use something like i've put together that manages the state when clocked. We can't just turn on leds, wait, turn off etc. that's not going to work.

I agree to do the best possible for power saving and sharing the code. If rananna can not do it, then I hope you will be able to do it. Rananna is working on the wireless remote and you on the wired remote. The board, buttons and LEDs are just the same, so I think the code should be the same.