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

[casainho]

May i ask whether there is already a working windows version/method so windows users can try to install the whole stuff? As i already posted here some weeks ago i successfully installed the firmware bootloader 0.0.9 once and i could see a TSDZ2_DFU device within the nrf connect app.

After flashing this DFU device with firmware 0.6.2 using the nrf connect app the device disappeard and couldn't be found anymore. I thought using stlink again to reflash the dongle with bootloader 0.0.9 (verified ok!) would make the TSDZ2_DFU device visible again for another try but it stays invisible. Holding down the devices button while un/plugging it to usb port does not seem to have any effect in terms of reseting the device and i believe that reseting is no more possible or the device is broken. Can someone WITHOUT using Linux confirm that there is already a working method for windows users? I tried using Linux on a virtual machine to flash the bootloader but my ubuntu installation was causing millions of other problems (i.e. missing graphic device/low resolution) so i gave it up.

See if you can use the full erase command, if you can you are done and then we can update the documentation for the next ones - this would be your contribution.

 

[Peacepirate]

i tried it some days ago with this different openocd.cfg file but with no effect.

 

[casainho]

i tried it some days ago with this different openocd.cfg file but with no effect.

You need to follow the Linux command sequence. The OpenOCD should behave the same - please post here the OpenOCD output when you execute the commands.

 

[casainho]

@rananna, now that the remote is finished, do you want the next challenge? - It would be to develop the custom Garmin fields to show the TSDZ2 data that ANT+ does not provide.

I would start to make numeric only fields but later try to provide also graphic fields with similar layout and colors of original Garmin graphic field of the heart rate.

And the communications need to be Bluetooth and for connected to Garmin Edge on the firmware side is already done as it will be the same as the mobile phone - I think the mobile app and Garmin Edge can not be connected simultaneously.

 

[rananna]

@rananna, now that the remote is finished, do you want the next challenge? - It would be to develop the custom Garmin fields to show the TSDZ2 data that ANT+ does not provide.

I would start to make numeric only fields but later try to provide also graphic fields with similar layout and colors of original Garmin graphic field of the heart rate.

And the communications need to be Bluetooth and for connected to Garmin Edge on the firmware side is already done as it will be the same as the mobile phone - I think the mobile app and Garmin Edge can not be connected simultaneously.

We already have an ANT + LEV enabled custom data field that displays a pretty comprehensive data set of information.

And, as you know, the latest version of garmin's monkeyC blue tooth enabled custom data fields can display both graphical and text data for any data missing from ant+ lev standard that we may wish to display.

However, before we spend too much time discussing how to implement blue tooth custom data on the garmin, I would first like to better understand why we need to do this. To answer that I need to know what additional data coming from the motor firmware needs to be displayed.
So, can you please provide a list of the destired additional data generated by the TSDZ2 firmware that you would like the garmin to display?

 

[casainho]

However, before we spend too much time discussing how to implement blue tooth custom data on the garmin, I would first like to better understand why we need to do this. To answer that I need to know what additional data coming from the motor firmware needs to be displayed.
So, can you please provide a list of the destired additional data generated by the TSDZ2 firmware that you would like the garmin to display?

All the data!! The idea is to be like on the 860C/SW102/Android app - the idea is that you choose which variable to see on the field, then the variable have a label and his own value (max and mins can be automatic).

The same data (all variables) that are available on the display are also available on the Bluetooth.

I guess I Garmin we will need to build a field for each variable, maybe that processed can be automated to be built with a script so finally we will need to upload one by one to the Garmin store.

 

[rananna]

However, before we spend too much time discussing how to implement blue tooth custom data on the garmin, I would first like to better understand why we need to do this. To answer that I need to know what additional data coming from the motor firmware needs to be displayed.
So, can you please provide a list of the destired additional data generated by the TSDZ2 firmware that you would like the garmin to display?

All the data!! The idea is to be like on the 860C/SW102/Android app - the idea is that you choose which variable to see on the field, then the variable have a label and his own value (max and mins can be automatic).

The same data (all variables) that are available on the display are also available on the Bluetooth.

I guess I Garmin we will need to build a field for each variable, maybe that processed can be automated to be built with a script so finally we will need to upload one by one to the Garmin store.

Ok, but although technically we can possibly display lots of info on the garmin I personally need to find motivation to actually implement that capability.

For example, the wireless problem statement was very clear and motivating to me: Provide a clean, wire free installation that implemented ebike control functionality. I was initially attracted to this project after having implemented a messy TSDZ2 wire harness on my bike, and it is very satisfying to have played a small part in accomplishing this objective.

However, to participate in developing a customized garmin display I need to have an answer to this question:

WHAT problem are we providing a solution for?

You already have developed a very flexible phone based blue tooth app that can be configured to display anything a user may wish to see.

Personally, During a ride, I find my ability to process information is limited to only a few variables. ANT LEV plus heart rate is about all I can manage. In fact ,we have a number of users on this forum that are happy with no information at all being displayed during a ride !

Although we might be able to do it, do we really need the garmin to be another configurable display like the Android app?

So, in summary, unless I can be convinced of a real need, I am not interested in participating in this development.




.

 

[casainho]

However, before we spend too much time discussing how to implement blue tooth custom data on the garmin, I would first like to better understand why we need to do this. To answer that I need to know what additional data coming from the motor firmware needs to be displayed.
So, can you please provide a list of the destired additional data generated by the TSDZ2 firmware that you would like the garmin to display?

All the data!! The idea is to be like on the 860C/SW102/Android app - the idea is that you choose which variable to see on the field, then the variable have a label and his own value (max and mins can be automatic).

The same data (all variables) that are available on the display are also available on the Bluetooth.

I guess I Garmin we will need to build a field for each variable, maybe that processed can be automated to be built with a script so finally we will need to upload one by one to the Garmin store.

Ok, but although technically we can possibly display lots of info on the garmin I personally need to find motivation to actually implement that capability.

For example, the wireless problem statement was very clear and motivating to me: Provide a clean, wire free installation that implemented ebike control functionality. I was initially attracted to this project after having implemented a messy TSDZ2 wire harness on my bike, and it is very satisfying to have played a small part in accomplishing this objective.

However, to participate in developing a customized garmin display I need to have an answer to this question:

WHAT problem are we providing a solution for?

You already have developed a very flexible phone based blue tooth app that can be configured to display anything a user may wish to see.

Personally, During a ride, I find my ability to process information is limited to only a few variables. ANT LEV plus heart rate is about all I can manage. In fact ,we have a number of users on this forum that are happy with no information at all being displayed during a ride !

Although we might be able to do it, do we really need the garmin to be another configurable display like the Android app?

So, in summary, unless I can be convinced of a real need, I am not interested in participating in this development.

Thanks, very clear to me now. And you did a big development, believe me!! You should be proud of.

I can't see the heart rate on our app and I think is not not a good idea to keep developing it as Garmin is much more advanced, see the navigation for instance and fitness. So I am better at using the Garmin than the mobile app.

What I miss is see things like motor current as that let me manage my battery range.
The same for motor temperature that is critical to me in some moments when I am fighting with the cars on a very busy and dangerous road near my house, I can't heat to much the motor and after have the assist very limited or stopped. The motor current and temperature are very important.

Once a field is ready to show some variable like motor current, than it can show any other.

The plan is to develop little as possible, following existing example for reading a Bluetooth characteristic, get all the variables like the mobile app does filter the one we want to show and finally show it.

My idea is not to make an app but just fields. The user can customize his Garmin display layout as usual and choose any of our variables to see.

 

[rananna]

@casainho,
I was thinking about your excellent 3d remote design in the context of serviceability and battery life.
A typical cr2032 battery has a nominal capacity of 225mah, which I de-rated in my life calculations to 80% or 180 mah. This led to life estimates of 1.5-2 yrs in modelled usage scenarios.
The cr2032 battery is 20mmx3.2 mm in size.
However, battery life can degrade in high (or low) temperatures, and these effects are difficult to model.
So, I wondered what the impact of a higher capacity lithium cell would have on the enclosure.
It turns out that an inexpensive high capacity 3v coin cell is readily available that increases lifetime by 4-5 times! This would essentially eliminate any battery anxiety concerns that users may have with the wireless remote.

See: https://www.amazon.ca/dp/B07FMPQ84J/ref=sspa_dk_detail_1?psc=1&pd_rd_i=B07FMPQ84J&pd_rd_w=tJGuO&pf_rd_p=2c17e944-5508-41c9-9e34-6115f0c88f84&pd_rd_wg=B7rJw&pf_rd_r=36TGPE7REQBRR521PAF0&pd_rd_r=519f2211-b6a9-4cae-a331-7557d9a85e2b&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUE3T0MyTDIyVE44VlgmZW5jcnlwdGVkSWQ9QTA5MTM5NTMxNklGTldXTVFPU0JWJmVuY3J5cHRlZEFkSWQ9QTA4OTgzNTQyTFFLSTlFRkdEOEhSJndpZGdldE5hbWU9c3BfZGV0YWlsJmFjdGlvbj1jbGlja1JlZGlyZWN0JmRvTm90TG9nQ2xpY2s9dHJ1ZQ==

They are 1000mah in capacity and are not a lot bigger, namely 24.5x7.7mm.

Using this battery would only slightly increase the case size.
I am not skilled enough yet with Freecad to make the necessary mods to your design to incorporate this battery.
Would you be willing to try out this modification?

 

[beemac]

Done.
PR added for both docs and code.
I didn't touch @beemac's code for remote signalling.
At the present time it is not in agreement with the wireless remote.

Oh - aren't you editing the led_event #define aliases? Ideally every led_play/now/next(yada) in code should be referencing a LED_EVENT_xxx constant (where xxx describes the event that's happening rather than describing the led flashes) - that maps in the header to a LED_SEQUENCE_yyy constant (where yyy describes the actual led flash sequence). If we do that then everything is easy to keep in sync between the remote and the controller led flashes... just update the mappings and both sets of code change.

yes, of course.
I was referring to the fact that you are currently not using the same sequences for the same events.

ie: brakes are blinking instead of solid, turn on is still yellow, etc

edit: I now understand what you were trying to tell me.
No, I did not use brake define sequence, rather I used a led flash sequence!
i will need to check these defines and update the code.

ok, definitions updated in the latest wireless remote PR

Just updated to the latest source - and flashed - not sure I like the new motor on wait sequence - red/blue flashing - I really need to get yellow working for 3.3v

 

[beemac]

i tried it some days ago with this different openocd.cfg file but with no effect.

Can you post your output from openocd - i use windows and have no problems - I've tested both methods described in the docs. I also have no issue with full erase.

Make sure you are using 5v - and post any error output so we can see what's going on please.

 

[casainho]

@casainho,
I was thinking about your excellent 3d remote design in the context of serviceability and battery life.
A typical cr2032 battery has a nominal capacity of 225mah, which I de-rated in my life calculations to 80% or 180 mah. This led to life estimates of 1.5-2 yrs in modelled usage scenarios.
The cr2032 battery is 20mmx3.2 mm in size.
However, battery life can degrade in high (or low) temperatures, and these effects are difficult to model.
So, I wondered what the impact of a higher capacity lithium cell would have on the enclosure.
It turns out that an inexpensive high capacity 3v coin cell is readily available that increases lifetime by 4-5 times! This would essentially eliminate any battery anxiety concerns that users may have with the wireless remote.

See: https://www.amazon.ca/dp/B07FMPQ84J/ref=sspa_dk_detail_1?psc=1&pd_rd_i=B07FMPQ84J&pd_rd_w=tJGuO&pf_rd_p=2c17e944-5508-41c9-9e34-6115f0c88f84&pd_rd_wg=B7rJw&pf_rd_r=36TGPE7REQBRR521PAF0&pd_rd_r=519f2211-b6a9-4cae-a331-7557d9a85e2b&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUE3T0MyTDIyVE44VlgmZW5jcnlwdGVkSWQ9QTA5MTM5NTMxNklGTldXTVFPU0JWJmVuY3J5cHRlZEFkSWQ9QTA4OTgzNTQyTFFLSTlFRkdEOEhSJndpZGdldE5hbWU9c3BfZGV0YWlsJmFjdGlvbj1jbGlja1JlZGlyZWN0JmRvTm90TG9nQ2xpY2s9dHJ1ZQ==

They are 1000mah in capacity and are not a lot bigger, namely 24.5x7.7mm.

Using this battery would only slightly increase the case size.
I am not skilled enough yet with Freecad to make the necessary mods to your design to incorporate this battery.
Would you be willing to try out this modification?

The Garmin Remote page says that: "Easily replaced CR2032 battery lasts up to one year, and features an automatic sleep mode to save battery life." -- so we are very good in having more than twice of battery duration. For my usage, I expect at least that time or even more.

Our remote is big compared to original VLCD5 remote or others and that is the only disadvantage, I need to have a big thumb to access the buttons, because the increase of height due to the space of battery + wireless board + wires. So i do not want to increase the size but decrease if possible.

I already looked at smaller batteries or simple use the same battery and see if I can reduce the height but the reality is that it took me several weeks to develop the remote and I am now tired, I do not want to do it anymore soon - sorry.

Also I just found that there are rechargeable CR2032 batteries that should work: https://www.nkon.nl/pt/rechargeable/ml2032.html

lir2450
https://www.nkon.nl/pt/rechargeable/lir2450-knoopcel-120mah.html

 

[shirk]

Sorry I might have missed it and it has been posted but I can't find the info.

Will this allow the Garmin app to control the assist level?

 

[rananna]

@casainho,
I was thinking about your excellent 3d remote design in the context of serviceability and battery life.
A typical cr2032 battery has a nominal capacity of 225mah, which I de-rated in my life calculations to 80% or 180 mah. This led to life estimates of 1.5-2 yrs in modelled usage scenarios.
The cr2032 battery is 20mmx3.2 mm in size.
However, battery life can degrade in high (or low) temperatures, and these effects are difficult to model.
So, I wondered what the impact of a higher capacity lithium cell would have on the enclosure.
It turns out that an inexpensive high capacity 3v coin cell is readily available that increases lifetime by 4-5 times! This would essentially eliminate any battery anxiety concerns that users may have with the wireless remote.

See: https://www.amazon.ca/dp/B07FMPQ84J/ref=sspa_dk_detail_1?psc=1&pd_rd_i=B07FMPQ84J&pd_rd_w=tJGuO&pf_rd_p=2c17e944-5508-41c9-9e34-6115f0c88f84&pd_rd_wg=B7rJw&pf_rd_r=36TGPE7REQBRR521PAF0&pd_rd_r=519f2211-b6a9-4cae-a331-7557d9a85e2b&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUE3T0MyTDIyVE44VlgmZW5jcnlwdGVkSWQ9QTA5MTM5NTMxNklGTldXTVFPU0JWJmVuY3J5cHRlZEFkSWQ9QTA4OTgzNTQyTFFLSTlFRkdEOEhSJndpZGdldE5hbWU9c3BfZGV0YWlsJmFjdGlvbj1jbGlja1JlZGlyZWN0JmRvTm90TG9nQ2xpY2s9dHJ1ZQ==

They are 1000mah in capacity and are not a lot bigger, namely 24.5x7.7mm.

Using this battery would only slightly increase the case size.
I am not skilled enough yet with Freecad to make the necessary mods to your design to incorporate this battery.
Would you be willing to try out this modification?

The Garmin Remote page says that: "Easily replaced CR2032 battery lasts up to one year, and features an automatic sleep mode to save battery life." -- so we are very good in having more than twice of battery duration. For my usage, I expect at least that time or even more.

Our remote is big compared to original VLCD5 remote or others and that is the only disadvantage, I need to have a big thumb to access the buttons, because the increase of height due to the space of battery + wireless board + wires. So i do not want to increase the size but decrease if possible.

I already looked at smaller batteries or simple use the same battery and see if I can reduce the height but the reality is that it took me several weeks to develop the remote and I am now tired, I do not want to do it anymore soon - sorry.

Also I just found that there are rechargeable CR2032 batteries that should work: https://www.nkon.nl/pt/rechargeable/ml2032.html

lir2450
https://www.nkon.nl/pt/rechargeable/lir2450-knoopcel-120mah.html

I certainly understand your reticence to modify the design. It IS a lot of work!

Anyway, I am not sure I am explaining well, so I just want to be sure we are understanding each other regarding my redesign suggestions.

I agree that your existing remote case is too high. I am suggesting an even thicker battery, which would make the remote higher by over 3 mm, right?

No, wrong.

I am suggesting you increase the overlap area (the part of the remote beyond the handlebar where the led hole is) by enough so that the battery is completely in this area.
That way, you gain two advantages:
1. You could make a pocket in the 3d print that would house the battery and completely eliminate the height of the battery in the enclosure. This would reduce the height of the existing design by 3 mm. It would also allow for larger capacity batteries if we wanted to do this.

2. You could add a removable cover to allow for battery replacement in this pocket.

Based on my battery life simulations, we would easily have 1 year of life with a 2032 battery. However, please do not assume you will have 2 years of life with a 2032 battery. IMO,This is overly optimistic. It is better to have an easily removed battery and replace annually.

Anyway, I certainly understand that you are done with the design for now.
If I get proficient enough with freecad, I will try to make these mods, or perhaps others may be interested in taking this on.

 

[rananna]

Sorry I might have missed it and it has been posted but I can't find the info.

Will this allow the Garmin app to control the assist level?

No, the design implements the ANT+ LEV protocol for assist changing.
The garmin app does not support this protocol.
Garmin edge bike computers do though, and you can change assist levels using one of these devices.

 

[casainho]

Sorry I might have missed it and it has been posted but I can't find the info.

Will this allow the Garmin app to control the assist level?

No, the design implements the ANT+ LEV protocol for assist changing.
The garmin app does not support this protocol.
Garmin edge bike computers do though, and you can change assist levels using one of these devices.

I can change the assist level of TSDZ2 on my Edge 830 using his touch screen and without installing any app - the Edge just supports changing the assist level as also showing the EBike battery state.

I need to write a specific page about how to use the ANT+ LEV / GPS displays.

 

[Filippods]

Hi, i'm testing the e-mtb with the latest firmware.
Is it possible that it is less responsive than mbrusa's firmware?
I mean, i have the feeling that it takes longer to understand how much power to deliver and that it is less precise.
Could it depend on some parameters? I also calibrated the torque sensor.

 

[beemac]

Hi, i'm testing the e-mtb with the latest firmware.
Is it possible that it is less responsive than mbrusa's firmware?
I mean, i have the feeling that it takes longer to understand how much power to deliver and that it is less precise.
Could it depend on some parameters? I also calibrated the torque sensor.

I haven't tested mbrusa's firmware - but the current firmware here doesn't implement 'startup boost'. It hasn't been carried over from the display fw and even then I believe it was recommended to not use as it's buggy. Otherwise the firmware takes I think one or two pedal rotations before assist kicks in..

It's something I'm interested in as I do find that sometimes getting going if you've stopped on a hill or similar isn't easy - esp on a 21kg+ ebike.

@casainho/anyone - what were the issues with startup boost? How buggy is it?

 

[casainho]

@casainho/anyone - what were the issues with startup boost? How buggy is it?

Better to discuss on original thread: https://endless-sphere.com/forums/viewtopic.php?f=30&t=93818&e=1&view=unread#unread

 

[casainho]

I certainly understand your reticence to modify the design. It IS a lot of work!

Anyway, I am not sure I am explaining well, so I just want to be sure we are understanding each other regarding my redesign suggestions.

I agree that your existing remote case is too high. I am suggesting an even thicker battery, which would make the remote higher by over 3 mm, right?

No, wrong.

I am suggesting you increase the overlap area (the part of the remote beyond the handlebar where the led hole is) by enough so that the battery is completely in this area.
That way, you gain two advantages:
1. You could make a pocket in the 3d print that would house the battery and completely eliminate the height of the battery in the enclosure. This would reduce the height of the existing design by 3 mm. It would also allow for larger capacity batteries if we wanted to do this.

2. You could add a removable cover to allow for battery replacement in this pocket.

Based on my battery life simulations, we would easily have 1 year of life with a 2032 battery. However, please do not assume you will have 2 years of life with a 2032 battery. IMO,This is overly optimistic. It is better to have an easily removed battery and replace annually.

Anyway, I certainly understand that you are done with the design for now.
If I get proficient enough with freecad, I will try to make these mods, or perhaps others may be interested in taking this on.

You proposed the battery CR2477 and in this place, right? - don´t you think it would increase to much the remote to front side making it looking bulky and more fragile in the event of a fall?

 

[rananna]

I certainly understand your reticence to modify the design. It IS a lot of work!

Anyway, I am not sure I am explaining well, so I just want to be sure we are understanding each other regarding my redesign suggestions.

I agree that your existing remote case is too high. I am suggesting an even thicker battery, which would make the remote higher by over 3 mm, right?

No, wrong.

I am suggesting you increase the overlap area (the part of the remote beyond the handlebar where the led hole is) by enough so that the battery is completely in this area.
That way, you gain two advantages:
1. You could make a pocket in the 3d print that would house the battery and completely eliminate the height of the battery in the enclosure. This would reduce the height of the existing design by 3 mm. It would also allow for larger capacity batteries if we wanted to do this.

2. You could add a removable cover to allow for battery replacement in this pocket.

Based on my battery life simulations, we would easily have 1 year of life with a 2032 battery. However, please do not assume you will have 2 years of life with a 2032 battery. IMO,This is overly optimistic. It is better to have an easily removed battery and replace annually.

Anyway, I certainly understand that you are done with the design for now.
If I get proficient enough with freecad, I will try to make these mods, or perhaps others may be interested in taking this on.

You proposed the battery CR2477 and in this place, right? - don´t you think it would increase to much the remote to front side making it looking bulky and more fragile in the event of a fall?

Not quite.
That\ would certainly make it far too big!
Let me try to illustrate with the existing 2032 battery.
my apologies for the rendering of the bottom part - I messed something up there, but it is properly to scale.
So what I did was add a 2032 battery just UNDER the shelf of the bottom part.
Of course we could design a pocket to hold this battery by redesigning the lower part and adding an access port to allow for easy replacement. This would allow the lower part wall height to be reduced 3mm, but add a bit of plastic UNDER the existing part.
See:


Now, from the top, you can see that there is only a minor offset needed from the placement of the existing battery. The lower part would only increase in size by around 8mm.

From the side, it just touches the handlebar mount, allowing for access from underneath:


Here is the front view:


I hope this gets the idea across.
Let me know what you think.

 

[casainho]

So what I did was add a 2032 battery just UNDER the shelf of the bottom part.
Of course we could design a pocket to hold this battery by redesigning the lower part and adding an access port to allow for easy replacement. This would allow the lower part wall height to be reduced 3mm, but add a bit of plastic UNDER the existing part.

I left a clearance of 8mm on purpose between the base and the handle bard, because the remote is in part on top of my brake levers - so your idea would not work because at least 8mm clearance is needed:

Here is a simulation for CR14250 battery, but even like that this battery is to big so will not work:

 

[rananna]

I certainly understand your reticence to modify the design. It IS a lot of work!

Anyway, I am not sure I am explaining well, so I just want to be sure we are understanding each other regarding my redesign suggestions.

I agree that your existing remote case is too high. I am suggesting an even thicker battery, which would make the remote higher by over 3 mm, right?

No, wrong.

I am suggesting you increase the overlap area (the part of the remote beyond the handlebar where the led hole is) by enough so that the battery is completely in this area.
That way, you gain two advantages:
1. You could make a pocket in the 3d print that would house the battery and completely eliminate the height of the battery in the enclosure. This would reduce the height of the existing design by 3 mm. It would also allow for larger capacity batteries if we wanted to do this.

2. You could add a removable cover to allow for battery replacement in this pocket.

Based on my battery life simulations, we would easily have 1 year of life with a 2032 battery. However, please do not assume you will have 2 years of life with a 2032 battery. IMO,This is overly optimistic. It is better to have an easily removed battery and replace annually.

Anyway, I certainly understand that you are done with the design for now.
If I get proficient enough with freecad, I will try to make these mods, or perhaps others may be interested in taking this on.

You proposed the battery CR2477 and in this place, right? - don´t you think it would increase to much the remote to front side making it looking bulky and more fragile in the event of a fall?

Not quite.
That\ would certainly make it far too big!
Let me try to illustrate with the existing 2032 battery.
my apologies for the rendering of the bottom part - I messed something up there, but it is properly to scale.
So what I did was add a 2032 battery just UNDER the shelf of the bottom part.
Of course we could design a pocket to hold this battery by redesigning the lower part and adding an access port to allow for easy replacement. This would allow the lower part wall height to be reduced 3mm, but add a bit of plastic UNDER the existing part.
See:

3d.png
Now, from the top, you can see that there is only a minor offset needed from the placement of the existing battery. The lower part would only increase in size by around 8mm.
top.png
From the side, it just touches the handlebar mount, allowing for access from underneath:

side.png
Here is the front view:
front.png

I hope this gets the idea across.
Let me know what you think.

I forgot to include the bottom view:

 

[casainho]

I forgot to include the bottom view:
bottom.png

Now I think I see, the 8mm clearance would be there more near the center of the handle bar that in the image I shared of my brake levers, would be ok. I wounder how are the others brake levers...

I think your idea will work, to remove about 3,5mm in Z a axis at expense to increase the Y axis.

And what would be the battery then?

 

[rananna]

I forgot to include the bottom view:
bottom.png

Now I think I see, the 8mm clearance would be there more near the center of the handle bar that in the image I shared of my brake levers, would be ok. I wounder how are the others brake levers...

I think your idea will work, to remove about 3,5mm in Z a axis at expense to increase the Y axis.

And what would be the battery then?

Well, I see no problem with keeping a 2032, as it would be easy to change annually. (assuming the design has an access port)