Tsdz2 firmware open source adapted to vlcd5, vlcd6 and xh18

chri27.5 said:

today marcoq has officially published on jobike that it will no longer release any version, its work ends like this.

Click to expand...

sorry I just can't understand that trouble. The configurator was originally developed by me, Casainho and Xnyle as open source for the kunteng firmware.
Anybody can decompile marcoq's .jar file within three minutes with e.g. this online java decompiler.

I just deleted my fork, including the wiki. As I don't use no TSDZ2, it's no loss for me.

regards
stancecoke

I do not think Marcoq acted in bad faith but simply did not understand his obligations and possibly still does not. On the Jobike forum the discussion is about the configurator being based on work by Stancecoke, when it should be about the OSF.

https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fwww.jobike.it%2Fforum%2Ftopic.asp%3FTOPIC_ID%3D76426%26whichpage%3D57

Casainho raised the issue with him many months ago on Github.

https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display/issues/3

I am no expert on the GPL, but as I understand it is applicable because this is a derivative work of the OSF... the configurator is useless on its own without the OSF plus it essentially communicates with the OSF project through the configuration data and by calling the compile/program batch scripts.

Also, sorry to hear that Stancecoke, thank you for your efforts and providing a valuable service.

I highly respect the efforts of marcoq for developing the Java configurator for easy configuring OSF for default displays.
I think other people did too, because nobody had recompiled the java gui before and published as another fork.
As I understand this should be an easy job for people with Java experience.
So nobody has used or stolen the intellectual property of marcoq.

I can imagine that marcoq was unpleasent surprised after the publication without his permission, but I hope he will see that there was no bad intention and hope that he will develope the configurator further.
If this should not be the case then I thank marcoq for the work he has done for us; people with tsdz2 and default display.

@stancecoke, it is a pity that you ended the service for marcoq's fork, but I understand your reasons. Thanks for the service you have given.

Hi. I made fork a while ago too. There was no much interest in it, but famichiki tested it, and contacted me in PM recently.
If someone interested, I will quote here more information about it.

Demion said:

Based on OpenSource-EBike-firmware/TSDZ2-Smart-EBike (casainho, buba, endlesscadence) and added TSDZ2 VLCD display protocol code (hurzhurz, marcoq), no other changes at all.
All configs are in config.h. Need to configure manually and compile by yourself.
https://github.com/Demion/TSDZ2-Smart-EBike/tree/vlcd_v0.18.2
https://github.com/Demion/TSDZ2-Smart-EBike/tree/vlcd_v0.19.0

Click to expand...

Demion said:

My fork is exact copy from original OSF no changes at all except, adding support of VLCD5/VLCD6 displays and default configuration (to run without display if needed).

Need first enabled it set DISPLAY_VLCD_CONTROL_FUNCTIONS to 1.
Turning on light (holding light button) will switch on / off (toggle)

Code:

0 - lights
1 - street mode
2 - boost mode
3 - power limit enable
4 - switch to show data
after switching 4
0 - lights
1 - show pedal power / 10
2 - show voltage
3 - show current
4 - switch back to controls

Click to expand...

Demion said:

You select assist level 1 hold lights button screen backlight should lighten up. That means street mode is enabled.
If you want to disable street mode then you should hold lights button (still on assist level 1) until screen backlight turns off.
If you want to keep street mode but turn off backlight or turn on/off lights you need to switch to assist level 0 and then press lights button.
After you switched feature on / off you can select any assist level you want to ride.
Same for other features.
After you turn on lights at level 4 your 1-2-3 levels switches will show some data as error code. For instance 52v voltage will be E52, 10a current will be E10.
It will not show speed in that mode though. That is the limit of VLCD screen, unfortunately.

P.S. maybe on VLCD5 you need to press power button twice to turn on / off lights and backlight and toggle features.
On VLCD6 it is hold assist up to turn on lights and backlight, hold assist down to turn on walk / cruise mode.

Click to expand...

Demion said:

Code is triggered when light switch state is changed (from on to off or vice versa) then checks if assist level 4 was previously set on for data display. Then corresponding function (or data display) is switched on if lights on or switched off if lights off, accordingly. Assist level 0 (off) is reserved for switching backlight and/or lights on/off without changing any settings.

Click to expand...

Btw I plan working on esp8266 module for TSDZ2 to control ebike from phone with bluetooth next spring / summer.
I might as well add VLCD support to v0.20.0, but it may take a while (about month).
If someone interested to make GUI (Java) to change configs, contact me PM.
Thanks.

famichiki said:

On the Jobike forum the discussion is about the configurator being based on work by Stancecoke

https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fwww.jobike.it%2Fforum%2Ftopic.asp%3FTOPIC_ID%3D76426%26whichpage%3D57

Click to expand...

Of course you can find the link to the GNU licence in the readme of the Kunteng repo.
We developers are all hobbyists and spend many hours of our sparetime with this hobby. We all publish our code, so anyone can improve the work and share it with the community...

regards
stancecoke

Demion said:

Hi. I made fork a while ago too. There was no much interest in it, but famichiki tested it, and contacted me in PM recently.
If someone interested, I will quote here more information about it......

Click to expand...

Nice to see you here again, you say then that your fork only was a temperary one and that you go with sw102, so I thought you ended the project then with v0.19
I know about your fork for vlcd5-6 display's and on regulary base I have mentioned this too to others (like famichiki) in this topic.
I was especially surprised by the simplicity you had forked v18 and v19 to vlcd5/6. (only two different files with kt-lcd3 OSF)
I have xh18 display and know that the behavior isn't the same as the vlcd5-6 displays, that is why I never had tried and stay with marcoq's build, that has smoothed out this behaviour. Marcoq build has a lot more different files than your build.
I am no developer so I didn't know how and what was done for solving that xh18 behaviour.
I am certainly interested in your build and will be satisfied too with editing config.h only.
If there is a template with default settings it looks to me that changing these settings is not the most difficult part as famichiki already stated here. The java gui is the most easiest method for that, but in the first place not necessary.

stancecoke said:

....
Of course you can find the link to the GNU licence in the readme of the Kunteng repo.....

Click to expand...

I can imagine that some things can be overseen. I hope marcoq will see this too and will pick up development of the Java gui again.
As said, nobody has used or stolen his intelectual work, so everyone have respected what he has done.

It is not only basically modifying single file ebike_app.c but actually just changing few functions.
1. add init_default_config() to set default configs that are not configurable with VLCD;
2. change uart_receive_package() & uart_send_package() to support VLCD protocol;
3. config.h just configuration defines.
My idea was using original OSF with little modifications as possible.
I havent followed forum much since end of summer. I myself still using VLCD6 with v0.19.0 fork.
I was planning to use SW102, but now thinking soldering small esp8266 to serial TX, RX and controlling from Android with Bluetooth (which will be optional) would be more interesting for me.
I think VLCD fork might be useful who still want to just use VLCD5/VLCD6/XH18 (or no display at all).

As I know, Marcoq, done more modifications such as motor tuning, implementing eMTB mode even before v0.20.0, changing behavior of walk assist and other.
I havent looked in all changes, although Marcoq VLCD protocol code was very useful to get started.
Although I think first one who actually documented VLCD protocol is hurzhurz.
https://github.com/hurzhurz/tsdz2/blob/master/serial-communication.md

Regarding XH18. Looking at Marcoq vM0.19.C only difference between XH18 and VLCD6 is Error Code numbers. What problems do you encounter?
I only have VLCD6, so can not test myself VLCD5 and XH18.

Porting to v0.20.0 should not be that difficult, I will look into it when I have more free time.

Java Configurator should be as easy as modifying text in config.h, setting path and calling compile_and_flash.bat.
I just have no much experience in Java and GUI designing.
If someone wants to help with that feel free to PM me. Or I will give it a try myself later. I guess we can use stancecoke OSEC Parameter Configurator as GUI template.

Update: btw with differences in error codes and battery levels, curious how original firmware detects display model? Probably some bit in packet, anyone figured that out?

Demion said:

It is not only basically modifying single file ebike_app.c but actually just changing few functions.
.......
I think VLCD fork might be useful who still want to just use VLCD5/VLCD6/XH18 (or no display at all).
.....
Regarding XH18. Looking at Marcoq vM0.19.C only difference between XH18 and VLCD6 is Error Code numbers. What problems do you encounter?
I only have VLCD6, so can not test myself VLCD5 and XH18.

Porting to v0.20.0 should not be that difficult, I will look into it when I have more free time.

Java Configurator should be as easy as modifying text in config.h, setting path and calling compile_and_flash.bat.
.....

Click to expand...

I refer indeed to the different error nrs., but I thought something more was also different as mbrusa did encountered with his mods to display the measured values. I don't know how he solved this with his last mod for the configurator.
Ofcourse is an "all in one" solution the most easy method and I thank marcoq for that what he had done, but for porting in the first place it is not especially needed.

Elinx said:

As said, nobody has used or stolen his intelectual work

Click to expand...

Sorry, the ones who should be angry are Xnyle, Casainho and me, as marcoq uses our "intellectual work" ignoring the rules of common open source developing...

@Demion: I'll write a short tutorial how to get started with Netbeans and the editing of the GUI!
regards
stancecoke

stancecoke said:

......
Sorry, the ones who could be angry are Xnyle, Casainho and me, as marcoq uses our "intellectual work" ignoring the rules of common open source developing........

Click to expand...

Ofcourse you are right.
I was not talking about the use of your sources, but of marcoq's "tsdz2 OSF design " with java.
For what I know, nobody has used his "design" as a base as he did with yours.
I still don't understand how marcoq could overseen the open source commitment by using the source code.

I think we are all interested in the best development of TSDZ2 original displays with OSF, therefore I want to thank marcoq for the configurator and all the other programmers that made the porting possible.
I think the best way forward is to focus the work on the buba's v0.20, which is to date the most complete. We are here to help with our tests, impressions and suggestions.
Hope you guys keep working to bring this project even further.
Happy end of 2019!

stancecoke said:

Elinx said:

As said, nobody has used or stolen his intelectual work

Click to expand...

Sorry, the ones who should be angry are Xnyle, Casainho and me, as marcoq uses our "intellectual work" ignoring the rules of common open source developing...

@Demion: I'll write a short tutorial how to get started with Netbeans and the editing of the GUI!
regards
stancecoke

Click to expand...

You're right Stancecoke ... the GUI that I created was born from your source code ... but this does not justify that you can take my work to decompile it ... edit it and publish it without asking me ... I would have been glad that I had involved myself because I believed in a cooperation between users ... acknowledged that the GUI is a GPL and not simply an Open Source I would have personally sent you my source code ... let me be clear I have always worked for the community !!!!

marcoq said:

........ let me be clear I have always worked for the community !!!!

Click to expand...

Hello Marcoq, glad to see you here.
I can imagine you are upset about the publication without letting you know before this happens.
But on the other hand. You was the only one that worked on it.
Nobody of the community has used your configurator as "his/her" work, so IMHO everyone has respected your work and still do.
I hope you want to work further on your configurator for the community.

marcoq said:

I would have been glad that I had involved myself because I believed in a cooperation between users ...

Click to expand...

So, just make your Java code public, then everybody is happy. There is really no secret in it.

regards
stancecoke

stancecoke said:

marcoq said:

I would have been glad that I had involved myself because I believed in a cooperation between users ...

Click to expand...

So, just make your Java code public, then everybody is happy. There is really no secret in it.

regards
stancecoke

Click to expand...

Stancecoke ... I will be wrong ... but if you think you have acted correctly towards me ... then we have nothing more to say to each other.

regards
marcoq

marcoq said:

but if you think you have acted correctly towards me

Click to expand...

If I had kown, that you would react like you do actually, I would have asked you first.
I was really happy, that you brought my idea of the Java GUI to the TSDZ2 project, thank you for that. But I'm not happy, if someone uses my code and then doesn't publish his sources. That's not my understanding of open source development.
I hope you will contribute to the project in an open manner in the future.

regards
stancecoke

stancecoke said:

marcoq said:

but if you think you have acted correctly towards me

Click to expand...

If I had kown, that you would react like you do actually, I would have asked you first.
I was really happy, that you brought my idea of the Java GUI to the TSDZ2 project, thank you for that. But I'm not happy, if someone uses my code and then doesn't publish his sources. That's not my understanding of open source development.
I hope you will contribute to the project in an open manner in the future.

regards
stancecoke

Click to expand...

There are many things to do in this project ... including the porting of the 0.20 version ... better if with the implementation of bluetooth (as mentioned by Demion) ... now I will rest for 2 weeks ... for a some time I have to disconnect the plug ... eventually we update in January.

Regards.
marcoq

marcoq said:

...........
There are many things to do in this project .... .... ... eventually we update in January.
..........

Click to expand...

Then it will be a happy new year

stancecoke said:

@Demion: I'll write a short tutorial how to get started with Netbeans and the editing of the GUI!

Click to expand...

I looked through OSEC.java code. It seems pretty simple to use. I edited few JLabel in Notepad++. It also compiles well without Netbeans using makeJar.bat.
I think adding your repository as git submodule to TSDZ2 fork just for JavaConfigurator tool not best idea.
I hope adding links in app to your repository stancecoke/BMSBattery_S_controllers_firmware and original OpenSource-EBike-firmware/TSDZ2-Smart-EBike will be sufficient.
Thanks all for great work.

Demion said:

I looked through OSEC.java code. It seems pretty simple to use.

Click to expand...

:thumb:

Demion said:

I hope adding links in app to your repository stancecoke/BMSBattery_S_controllers_firmware and original OpenSource-EBike-firmware/TSDZ2-Smart-EBike will be sufficient.

Click to expand...

Yes of course, if you share your resulting java code :wink:

regards
stancecoke

IMHO making a new configurator should be the lowest priority, and anyway the config.h file needs to be finalised first. Much of the angst around Marcoq's fork has been because of the inability for others to update the configurator and Marcoq not having time to make changes to it. Even if a new one was built for Demion's version and it was opensource, it's extra complexity that may hinder further development.

Simplicity is the beauty of Demion's versions and allow anyone to easily build on his work. If you look at his config.h file, it's nicely laid out and is very simple to understand and edit. It could probably be made even easier by minor work such as separate basic & advanced settings and adding further explanations.

I find it difficult to think that anyone who has got to the stage of being able to flash the OSF firmware would actually need a separate configurator and could not edit the config file directly.

A configurator was necessary to use Marcoq's version because there was no other way to edit the settings, there was no user editable config file that put all the settings into one place. All the defines were only inserted into the code at configurator run-time and then removed again immediately after. Even if a user wanted to hard code a setting they could not. And in fact I found the 2-step Compile then Program buttons to be a little annoying, over the simpler original Compile & Program batch file.

If a new configurator was to be built it should output a config.h in exactly the same beautiful format as Demion's user editable file. A configurator should be a bonus feature, not one that is essential. This gives users the choice of manually editing the file or automatically generating one, or even manually tweaking a previously automatically generated one.

That all said, I had a brief look at the possibility of making a simple configurator as a single html file that could be run locally in any browser using a form that outputs to a text file. It was trivial and I had a basic example working in a few minutes. Possibly this could be the way to go, make a quick-start configurator for new users with only essential settings like battery and options like lights, brakes etc. Then later if they want to change advanced settings they will be more familiar with the process and can edit the config.h file instead.

But probably the best thing that could be done initially is to ensure there is a concise Readme explaining how to edit the config file and compile & flash. Because information like this is spread all over and hard to find for a new user. The config.h file itself should be self explanatory as much as possible.

So please consider whether a configurator is really needed as we all only have limited resources and need to keep focused, plus keeping things simple will allow for quicker and easier updates in the future.

I like the idea of famichici.
I too was suprised by the simplicity Demion has ported v0.18 and v.019 to vlcd/no displays. Only missing part was support for xh18 display, but that shouldn't be a big problem.
Eventually a minimal gui/script for import config.h, compiling and flashing should be handy, but not needed in the first place.
Every development have their bugs. The more complex, the more bugs. But also less easy to find.

IMHO for the layout of config.h we could maybe be as close as the list of v.020 configurations for lcd3.

View attachment Configuration Menu TSDZ2 FW v020.pdf

It's always easy after someone thought about it and made it first. For this reason it was not correct not to ask marcoq for anything.
Here in Italy there are now hundreds of those who use the marcoq system and are simple mountain bikers who know nothing about compilers, java, etc. This was the big advantage. If you do not think about this you risk that it remains a beautiful thing but only for IT technicians who go mountain biking. An ordinary cyclist doesn't even think about learning how a compiler works, nor does he start studying all the parameters. The web is full of many beautiful projects understandable only to a small group of people. This is what makes the difference. With the gui of marcoq a cyclist with minimal effort programs the engine, with other systems it doesn't. You have to decide who the project is intended for, then everything is possible. this is my opinion ..

andrea_104kg said:

An ordinary cyclist doesn't even think about learning how a compiler works, nor does he start studying all the parameters.

Click to expand...

Have you tried compiling for yourself? There is nothing required to learn, no parameters or settings, it's all automated and surprisingly simple. The scariest part is simply the word "compiler". However to try with Marcoq's you'll need to copy your generated config.h file as I mentioned in a previous post, since it's not designed to be used this way.

Just click a single file called compile_and_flash.bat and it's done.

Clicking the Compile and Program buttons in the configurator does the exact same thing but in a two-step process, separately calling compile.bat then flash.bat which are also part of the original OSF. Even the same command window progress is displayed.

As for editing the config file, it's just a list of options and you enter the value next to them the same as you enter into the configurator boxes. But as I mentioned, this could be improved further.

What can I say. Windows users like "user friendly" GUI apps with buttons and are scared off by batch files and text file manual edits.
Anyway it is not even in question to make or not configurator app, cause it is just few days of work. One day to code, one day to test.
I agree documentation is necessary. Although most options are from original open source firmware and are documented in wiki.
Also configurator should just edit config.h file and call compile_and_flash batch file so that both ways (manual and configurator) are possible and optional, as famichiki mentioned.