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

[rananna]

There is an overlap on P0.22 where the Brake pin overlaps with the TSDZ2_RX pin.
I also share your vision but I hardly believe that Casainho would agree to re assign the pin to another one that is free and not overlapping like P0.10. In this way we will have brake input and brake output next to each other.

For people that will never use the Garmin GPS or watch, the remote with the second board and the battery are of no real use.

Even there is no need to use a remote at all, everything is optional (only the wireless board is mandatory). You can use the wireless board to change the assist level and turn on/off the system, so, not even need of extra buttons.

There is no issue for us to use that other pin, I will update the schematic tomorrow.

Code changed.

 

[plpetrov]

There is an overlap on P0.22 where the Brake pin overlaps with the TSDZ2_RX pin.
I also share your vision but I hardly believe that Casainho would agree to re assign the pin to another one that is free and not overlapping like P0.10. In this way we will have brake input and brake output next to each other.

For people that will never use the Garmin GPS or watch, the remote with the second board and the battery are of no real use.

Even there is no need to use a remote at all, everything is optional (only the wireless board is mandatory). You can use the wireless board to change the assist level and turn on/off the system, so, not even need of extra buttons.

There is no issue for us to use that other pin, I will update the schematic tomorrow.

Thank you! I really liked your idea for merging the two projects together and have the same code for the boot loader and the LED control. Then I thought that you might have had eventually considered my previous proposal to keep the same code for the buttons also. The power button will be common for both the remote and the wireless controller, the plus and minus and the other two will remain optional.
So finally it will be quite a professional project for which the user will be able to compile a custom build or select one with a precompiled set of options.

 

[Beli]

I avoid soldering and use a surface mount coin cell holder like this:
https://www.aliexpress.com/item/32791160112.html?spm=a2g0s.9042311.0.0.27424c4dabB17n

I use one of that but it takes so much space compared to the battery and the board itself

This would be smaller:
https://www.aliexpress.com/item/4000847873214.html

However it's for soldering on PCBs.

May be with the combined code in a single repository we could have both the remote and the wireless controller running on a single board.

There shouldn't be much code needed for adding pins for buttons to the wireless board. But I already made this request before...

And why not a simple display connected to them.

Like my self made I posted earlier? :wink:

I'm still not sure if I go wireless with that display. At least a nRF evaluation board for trials should arrive on Monday...

Even there is no need to use a remote at all, everything is optional (only the wireless board is mandatory). You can use the wireless board to change the assist level and turn on/off the system, so, not even need of extra buttons.

???
Did you mean by using the smartphone?

 

[Filippods]

First sketch of the remote done, 3D printer friendly!





https://youtu.be/k8F_IKy4_Qg

I have to print it to verify the dimensions and tolerances, after that i will focus on impermeability and design.

What do you think about this first sketch?

 

[plpetrov]

yeah that sounds really good! is it not possible to roll it all up into one board? Then mount it say under the stem like they do with a Di2 controller?

The Di2 group set controller requires 2 sets of wires. One set goes to the brakes/shifters, (which is similar to our use case), however it also requires wires running through the frame to control the shifter. We could of course have only one board on the handlebar with wires going to the motor, but that would kind of defeat the idea of having a totally wireless solution. The wireless communication between the two boards eliminates all wires running up the frame from the motor.
We would also not want it under the stem as the led on the nrf52840 must be visible.
Hope that answers your question.

Have you considered direct wired control of the Di2 shifter without using all others Shimano components? In the past I came across some attempts to reverse engineer the protocol.
The shifter only for the IGH is about 90 Euro. In case you can control it with the combination of the wireless board and the remote, I will be immediately convinced to use also the remote!

 

[plpetrov]

And why not a simple display connected to them.

Like my self made I posted earlier? :wink:

You mean something like this one?
https://sites.google.com/site/mjrippe/vfd-tubes
It will be nice for a retro bike.

 

[casainho]

What do you think about this first sketch?

I must say I can not visualize, maybe only If I 3d print it, I will understand.

So, at least we know that we want to reuse the VLCD5 buttons, add the wireless board, the battery and space to wire the cables for the brake sensors. I hope you saw our previous messages where we tried to design something that would reuse only the VLCD5 board and buttons pad. But we decided to go with simple box for the wireless board only because it is simple as also will let us see the RGB LED of the board.

The only thing I think is important, maybe not possible? on your design, is to be like the VLCD5 keypad that you can install or remove from the handle bars without removing the other installed parts like the brake levers, etc, so, it should be easy and fast to install or remove from the handle bar.

 

[Filippods]

I must say I can not visualize, maybe only If I 3d print it, I will understand.

So, at least we know that we want to reuse the VLCD5 buttons, add the wireless board, the battery and space to wire the cables for the brake sensors. I hope you saw our previous messages where we tried to design something that would reuse only the VLCD5 board and buttons pad. But we decided to go with simple box for the wireless board only because it is simple as also will let us see the RGB LED of the board.

The only thing I think is important, maybe not possible? on your design, is to be like the VLCD5 keypad that you can install or remove from the handle bars without removing the other installed parts like the brake levers, etc, so, it should be easy and fast to install or remove from the handle bar.

I've tried to elaborate a design with removable keypad, but i think it will be too difficult to realize, most of 3d printers have too high tolerances to allow this, furthermore i've no idea on how to link a plug and play keypad.

In my design i reuse vlcd5 keypad (top housing), both leds are visible (bottom housing), there is a lateral housing for 2032 case, the 3 housings are linked by holes for wiring.
Based on what i've read on this topic i've designed also 2 brake connector housings, but not for shift sensor.

 

[beemac]

There is no issue for us to use that other pin, I will update the schematic tomorrow.

Code changed.

Amazing - thanks very much - I promise I won't mention wired buttons again until we get all the wireless stuff implemented!

 

[casainho]

In my design i reuse vlcd5 keypad (top housing), both leds are visible (bottom housing), there is a lateral housing for 2032 case, the 3 housings are linked by holes for wiring.
Based on what i've read on this topic i've designed also 2 brake connector housings, but not for shift sensor.

Ok, now I see... It seems a bit complex but good that you got it.

I think we did agree to use only the RGB LED, if that helps on your design, you can hide it.

I think allmost no one use a shift sensor - this is out of this project.

I think is ambitious to design the full remote and not the box only, but should be better as will be clean on the handlebar!!

And do not worry to be perfect, we can improve later with the feedback of real users... Is so cheap to design and 3D print again

One last wish is for later redesign using FreeCAD and, I guess will be easier after you did that hard work of the initial design.
I wish to play a bit with the 3D model, to increase at least the height to the handle bar, as I have some brake levers that I wish to put the remote partially on top of them...

 

[Filippods]

Ok, now I see... It seems a bit complex but good that you got it.

I think we did agree to use only the RGB LED, if that helps on your design, you can hide it.

I think allmost no one use a shift sensor - this is out of this project.

I think is ambitious to design the full remote and not the box only, but should be better as will be clean on the handlebar!!

And do not worry to be perfect, we can improve later with the feedback of real users... Is so cheap to design and 3D print again

One last wish is for later redesign using FreeCAD and, I guess will be easier after you did that hard work of the initial design.
I wish to play a bit with the 3D model, to increase at least the height to the handle bar, as I have some brake levers that I wish to put the remote partially on top of them...

Yes, it is a bit complex, but it's optimized for 3d printing, i designed that in order to be printable also by a very cheap 3d printer.

Both leds are visible, i can hide one or both of them... it's irrelevant for the design, you can freely choose!

Im going to print and test it!!

I never used FreeCad, i use Rhino 6, but i will try to export the project.

 

[casainho]

Both leds are visible, i can hide one or both of them... it's irrelevant for the design, you can freely choose!

Im going to print and test it!!

I am thinking to start with translucid/white silicone to fill the LED but I remember rananna mention a specific component for this.
I would prefer only the hole for RGB LED.

The board can be cut a bit, on the USB connecter. If you see it helps the design, do it.

 

[rananna]

Ok, now I see... It seems a bit complex but good that you got it.

I think we did agree to use only the RGB LED, if that helps on your design, you can hide it.

I think allmost no one use a shift sensor - this is out of this project.

I think is ambitious to design the full remote and not the box only, but should be better as will be clean on the handlebar!!

And do not worry to be perfect, we can improve later with the feedback of real users... Is so cheap to design and 3D print again

One last wish is for later redesign using FreeCAD and, I guess will be easier after you did that hard work of the initial design.
I wish to play a bit with the 3D model, to increase at least the height to the handle bar, as I have some brake levers that I wish to put the remote partially on top of them...

Yes, it is a bit complex, but it's optimized for 3d printing, i designed that in order to be printable also by a very cheap 3d printer.

Both leds are visible, i can hide one or both of them... it's irrelevant for the design, you can freely choose!

Im going to print and test it!!

I never used FreeCad, i use Rhino 6, but i will try to export the project.

Wow, this looks very interesting.
Unfortunately, I have a hard time visualizing the complete assembly in 3d in my head, but I really like the concept.
What would be the dimensions of the final assembly? I am especially interested in the height off the bar.
Looking forward to seeing your prototype!

 

[Filippods]

Both leds are visible, i can hide one or both of them... it's irrelevant for the design, you can freely choose!

Im going to print and test it!!

I am thinking to start with translucid/white silicone to fill the LED but I remember rananna mention a specific component for this.
I would prefer only the hole for RGB LED.

The board can be cut a bit, on the USB connecter. If you see it helps the design, do it.

I've already cut the usb connector as described in previous posts.

Ok, im going to cover Led2.

I prefer transparent silicone to make it waterproof!

 

[Filippods]

Ok, now I see... It seems a bit complex but good that you got it.

I think we did agree to use only the RGB LED, if that helps on your design, you can hide it.

I think allmost no one use a shift sensor - this is out of this project.

I think is ambitious to design the full remote and not the box only, but should be better as will be clean on the handlebar!!

And do not worry to be perfect, we can improve later with the feedback of real users... Is so cheap to design and 3D print again

One last wish is for later redesign using FreeCAD and, I guess will be easier after you did that hard work of the initial design.
I wish to play a bit with the 3D model, to increase at least the height to the handle bar, as I have some brake levers that I wish to put the remote partially on top of them...

Yes, it is a bit complex, but it's optimized for 3d printing, i designed that in order to be printable also by a very cheap 3d printer.

Both leds are visible, i can hide one or both of them... it's irrelevant for the design, you can freely choose!

Im going to print and test it!!

I never used FreeCad, i use Rhino 6, but i will try to export the project.

Wow, this looks very interesting.
Unfortunately, I have a hard time visualizing the complete assembly in 3d in my head, but I really like the concept.
What would be the dimensions of the final assembly? I am especially interested in the height off the bar.
Looking forward to seeing your prototype!

I've posted a link to a youtube video where i show the 3d design, sorry for the quality of the video.

The dimensions are the smallest possible, asap i will post the precise dimensions and other images

 

[rananna]

Both leds are visible, i can hide one or both of them... it's irrelevant for the design, you can freely choose!

Im going to print and test it!!

I am thinking to start with translucid/white silicone to fill the LED but I remember rananna mention a specific component for this.
I would prefer only the hole for RGB LED.

The reason I mention a specific component is because of the potential visibility issue of simply making a hole for the led
For small surface mounted leds, this is a particular problem as a good portion of the emitted light will simply be lost in the housing by using a hole.
We are also potentially compounding the problem by using pulse width modulation techniques to save power, at the expense of some brightness .
A good overview of led visibility issues can be found here:
https://www.ledsupply.com/blog/led-optics-explained/

Typically surface mounted leds use a press fit light pipe in the housing to capture most of the light and transmit it to the viewer.
https://www.bivar.com/five-things-every-engineer-should-know-about-led-indication/

A small press fit light pipe can be purchased in qty for not much money.
https://a.aliexpress.com/_mL04Vwz

This would be an issue for the diy user who wants only one though.....
If anyone has some ideas on this please let us know.

 

[casainho]

This would be an issue for the diy user who wants only one though.....
If anyone has some ideas on this please let us know.

I want first to test without it, because is important to have a small list of needed components and shops to source them. We can always improve later if we find it is really important.

That pipe should not be hard to install on our 3D printed case and use some glue to keep the water resistance.

 

[casainho]

Updated schematic of the remote: https://opensourceebike.github.io/

 

[rananna]

First draft of simplified user instructions:
https://opensourceebike.github.io/

Comments wecome!

 

[casainho]

First draft of simplified user instructions:
https://opensourceebike.github.io/

Comments wecome!

Is much better and I am pretty sure we will finish a good version even before all the important bugs on the firmware are solved

On the main page, I would only mention the page for a step by step to build the wireless board. I would never mention the bootloader but instead link to it on the specific build page.

Then also the same logic for the page step by step to build the remote.

I think the main page should present 1 or 2 very good pictures of the device and the advantages, to make desire on the user, for instance I really like your description you did: "There are over 100 configuration options that can be customized to fit any user’s particular requirements!"

And there must be space on the introduction to mention and link to 860C and SW102 displays, as the motor firwmware is just the same and some users my prefer the physical displays.

 

[casainho]

I've posted a link to a youtube video where i show the 3d design, sorry for the quality of the video.

The dimensions are the smallest possible, asap i will post the precise dimensions and other images

Can you please share the STL and STEP files so I can 3D print, even if far from perfect, since I am building my remote right now.

You can always do a pull request with that files to the remote repository, will be ok to share here the files and will then be on the project source files.

 

[rananna]

And there must be space on the introduction to mention and link to 860C and SW102 displays, as the motor firwmware is just the same and some users my prefer the physical displays.

Are you thinking that you would make a pass through connection on the TSDZ2 wireless module to allow users to connect displays if they wish and gain the advantage of the android app for configuration as well as an alternate control technique?
It seems to me if you did that it would merge both projects together.

 

[casainho]

And there must be space on the introduction to mention and link to 860C and SW102 displays, as the motor firwmware is just the same and some users my prefer the physical displays.

Are you thinking that you would make a pass through connection on the TSDZ2 wireless module to allow users to connect displays if they wish and gain the advantage of the android app for configuration as well as an alternate control technique?
It seems to me if you did that it would merge both projects together.

We still did not yet finish this project, so I think is to soon to increase the scope of the project. For now, I think the users will need to choose to use 860C and SW102 or the wireless system.

 

[rananna]

And there must be space on the introduction to mention and link to 860C and SW102 displays, as the motor firwmware is just the same and some users my prefer the physical displays.

Are you thinking that you would make a pass through connection on the TSDZ2 wireless module to allow users to connect displays if they wish and gain the advantage of the android app for configuration as well as an alternate control technique?
It seems to me if you did that it would merge both projects together.

We still did not yet finish this project, so I think is to soon to increase the scope of the project. For now, I think the users will need to choose to use 860C and SW102 or the wireless system.

Of course I agree, it far to early to do this, but down the road it would be very helpful to have a SINGLE source of information that new users could go to like https://opensourceebike.github.io/ that describes possible configuration options for your firmware in order of increasing complexity and features:
1. Basic firmware + 860 display
2. Basic firmware + 860 display + wireless control and configuration
3. Basic firmware + wireless control and configuration (optional ANT LEV display)
4 Basic firmware + wireless control and configuration ( optional ANT LEV display) + remote control

This might increase the interest in the firmware when a user can see the big picture and not have to gather info from lots of sources.

I just wanted to know if you agree on that vision for the future.

 

[casainho]

And there must be space on the introduction to mention and link to 860C and SW102 displays, as the motor firwmware is just the same and some users my prefer the physical displays.

Are you thinking that you would make a pass through connection on the TSDZ2 wireless module to allow users to connect displays if they wish and gain the advantage of the android app for configuration as well as an alternate control technique?
It seems to me if you did that it would merge both projects together.

We still did not yet finish this project, so I think is to soon to increase the scope of the project. For now, I think the users will need to choose to use 860C and SW102 or the wireless system.

Of course I agree, it far to early to do this, but down the road it would be very helpful to have a SINGLE source of information that new users could go to like https://opensourceebike.github.io/ that describes possible configuration options for your firmware in order of increasing complexity and features:
1. Basic firmware + 860 display
2. Basic firmware + 860 display + wireless control and configuration
3. Basic firmware + wireless control and configuration (optional ANT LEV display)
4 Basic firmware + wireless control and configuration ( optional ANT LEV display) + remote control

This might increase the interest in the firmware when a user can see the big picture and not have to gather info from lots of sources.

I just wanted to know if you agree on that vision for the future.

I think there is yet a lot of TODO on this wireless project. Also we need much more effort to prove this idea of wireless because is new, but a regular display is already established for ebikes.

And there are other new opportunities, making this system for other motors like the Bafang BSSHD which the OpenSource firmware is being developed. Also maybe the interest can grow and then the KT and Lishui firmware may also want to join. And I would prefer to develop the technology, like a better mobile app, to be able to easily adapt for that different motors and their specific configurations.
So, I would prefer to grow to support other motors and not just focus on TSDZ2 alone - because if we keep investing on the 860C and SW102 displays, that is a dead end and only for TSDZ2!! because is to hard to develop for that displays!! everyone can quick develop the mobile app but only VERY FEW can develop on the displays, it is too hard and so that will not happen!! The ANT+ LEV is a good example of a standard to be used on many different motors and hardware like the GPS displays that is hard to develop for, so, the solution is to simplify a lot the options / data for the motor.

I think in future we need to have a firmware to is easy to adapt for other motors and a mobile app that is easy to also adapt for other motors, like maybe a configuration file (JOSN??) to define which variables to use for configurations and for the main screen.