fixed docs/understood ant timeout issue/led pwr analysis

[rananna]

@casainho , I had to delete my fork, and start again with a new fork to avoid conflicts with a couple of files that would have required manual processing. I wish I understood enough about github to avoid this issue in future! Anyway, here are the changes in this PR:

1. Fixed the formatting issues in the power analysis docs
2. Added the measurement of LED current to the power analysis docs The average LED current when on is quite high, namely 4.6ma (RED), 4.0ma (GREEN) and 4.1ma (BLUE). We will certainly have to keep their use to a minimum on the remote. 3 Added long press of PLUS and MINUS for pageup/pagedown for the garmin. This seems very intuitive to me. I kept the single press of the ENTER key as we had before to be similar to the garmin remote.
3. I troubleshooted the issue with the garmin hanging up when there is no ebike. It turns out that this is related to the ANT timeout period. During these 30 seconds, the communication gets disrupted. We could shorten the search timeout to less than 30s, but this may cause problems with making a new connection. There does not appear to be any easy fix in firmware, so the need to configure the remote for ebike/garmin remains. Not really much of an issue with thie remote configuration options, but it is nice to know what is causing the problem. I just wish there was someway to address it. Maybe you or someone else skilled with ANT could fix it.
4. IF the garmin is disconnected, a new search was not automatically initiated. This is now fixed.
5. removed an unnecessary ANT_LEV message that was left in the code when I was debugging. This should speed up ANT_LEV communication a little bit.

[casainho]

About the LEDs, yes, it seems a lot of power!! And that power for each color, do you think they are bright enough? If they more than enough then maybe we can use PWM and use like 66% of the power? -- also, when combining a color, could be nice to reduce each one to 33% so total is 100% and not 300% -- this is just one idea, I do not know if PWM work on the LED pins but if it works, should not need extra processing power.

If we could make PWM working, maybe could be good for you to measure the same but like 50% to see if the current goes to near half of the 100% that you did measure.

I think motor should should turn on with a long press and turn off with the same long press. The startup process, including TSDZ2 startup takes some seconds and since is critical that user do not touch the pedals... I am thinking on this:

• power on: blink green during counting POWER long press (maybe 1.5 seconds) - user will have time to release the button if changes the idea
• TSDZ2 startup: blink green + blink red so user can see it very well and should not touch the pedals (maybe 6 seconds??)
• power off: blink red during counting POWER long press (maybe 1.5 seconds) - user will have time to release the button if changes the idea

I think that we should send a value / command by ANT to power on and other to power off. We also need to get status of the power on status by ANT. We need to find an efficient way to do all this. This commands and status should be the same sent by Bluetooth, by the mobile app.

[rananna]

Yes, the leds are really bright, and I think we could easily live with some dimming with Pwm, as long as the overhead for the clock doesn't eat up too much power. I will try it and let you know..

Regarding power On/0ff, why not use a bit in page 16 ack command? All data would be accessible by the remote and leds could be set as you describe. There is a System State bit field discussed in table 5.5 of can't lev docs. Maybe use bit 2 for low beam / high beam for power on/off? Status bits for power (not ready/ready) could be turn signal left (bit 1) in the system State bit field since we are unlikely to use this. Another available data field is "current regenerative level" in the travel mode State bit field (0-7 values like assist level, see table 5-4) that we could use for power on/off and status.