TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

casainho said:

I think there is a BIG issue with your pull request!! You should make small pull request, one pull request for each feature / bug (you gave the title "Higher cadence" to the pull request but it includes much more!!). That would be easier to make previous discussion of each feature / bug and also the testing. I understand it seems to make development kind of slow but has the advantage to involve the other developers and users, but make things going a bit slow, as for me, I need more time than you to review the code and understand it - going slow can be a good investment, I see the firmware getting more and more complex and can be a big issue if is hard for the users, I think we should take time to think very well the new additions.
I understand that you did previous discuss here some features, but it was to fast and not discuss all of them.

Can you please go back and submit small pull requests??

Click to expand...

Hi Casainho, thank you!

I think I need to explain something and why the sudden large pull request.

Back before you released the stable version 0.17.0 I was continually working on small pull requests with frequent updates. After my last merged pull request I asked you what to do for the next pull request and you said it would be good to implement the current ramp up (adjustable acceleration). So I started working on that together with another small update that introduced a new sub menu where users can switch to an experimental higher cadence version for the 48 V motor. I was close to submitting that when all of the sudden you released the stable version 0.17.0 even though I was still working on said improvements.

At that point I did not want to submit the pull request as users were downloading the stable version 0.17.0 and IF there were more bugs on 0.17.0 we should ONLY solve that particular bug and not add more firmware that is untested and prone to bugs. If I submitted my code with the new functionality users would be in a constant loop of updates, possible bugs and consequent patches. This is not how the stable version releases should work.

As such I waited and quietly observed this thread where all the great users are constantly giving input (THANKS!). If anyone would report something I was prepared to make a simple and fast change to the version 0.17.0 code and not introduce new firmware with new functions, just work on fixing that particular bug.

In the meantime I worked on a separate branch with the new functions as planned. Naturally, it grew.

Created an account on GitHub and learned everything just for this project and to make it easier for you, Casainho, to receive development from me. I learned how the code works in the last couple of weeks simply by reading line by line, from scratch. Implemented each and every function by my own implementation and with comments all over so that ANYONE can take over and understand the code. My mentality has always been KISS: Keep It Simple Stupid. And NEVER send you code that does not work.

I think if I have made these things and implemented the mentioned functions in less than a week on someone else’s code that I did not understand nor look at less than a week ago, it is really not that complicated for you who is vastly more experienced at this than me to understand the changes. I can even Skype with you or write down every piece of code you find strange and explain my thought process. I have done everything I can to lessen the work load.

This post is large enough. Hopefully you know that I also prefer smaller more frequent pull requests. Please, at least take a look at the code.

markjiizs said:

Buba, if meanwhile we can test whole buch of code, feel free to share source or hex

Click to expand...

Of course!

Here is my fork and the branch is called "higher cadence". There you will find the source code:
https://github.com/leon927/TSDZ2-Smart-EBike/tree/higher_cadence

Here is a quick and easy way to get the hex files. Created a folder on Google Drive:
https://drive.google.com/drive/folders/1HJMJc7cc9YsG1G83TUbpZwQxJcO2m023?usp=sharing

-----------------------------------------------------------------------------------------------------------------------------

By the way,

I always tried to have Marcoq and his great development in mind and make everything as modular as possible so he can easily develop and use these features on the OEM displays as well. This will make more users take the necessary steps to non-OEM displays in the future. Especially when they experience all the wonderful development Casainho and others have made.

buba said:

I can even Skype with you or write down every piece of code you find strange and explain my thought process. I have done everything I can to lessen the work load.

This post is large enough. Hopefully you know that I also prefer smaller more frequent pull requests. Please, at least take a look at the code.

Click to expand...

Ok, I will look at every commit on the pull request -- it will take some time and I will try to put comments on the pull request itself.

casainho said:

Rydon said:

Issue with coaster brake versions of the motor:

Click to expand...

The issue is that no one that develops uses that type of motor -- even If I had that motor for development, not having it on my ebike makes difficult to test and understand the needed specific features.

One question: does that motor uses a throttle??

I would make this specific work, to help for that specific motor version (this is a task for you )
1. We keep all pins definitions about the controller here (see bellow): https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/blob/master/src/controller/pins.h
2. Look at wiring on the motor controller: are the wiring the same or there are other pins connections to the board?? -- seeing the differences will help us to understand.

Click to expand...

Thanks Casainho! Coaster brake motors do not have throttle or walk assist for safety reasons. Because the motor does not freewheel the throttle would spin the cranks. These particular motors have 8 pin connectors but the throttle wire is not connected to the controller. I opened it up and looked.

Rydon said:

Coaster brake motors do not have throttle or walk assist for safety reasons. Because the motor does not freewheel the throttle would spin the cranks. These particular motors have 8 pin connectors but the throttle wire is not connected to the controller. I opened it up and looked.

Click to expand...

So, for that motor configuration, user would need to keep disabled the throttle and walk assist.

I do not have time right now to develop this, maybe other developers can and submit a pull request with the code.

buba said:

markjiizs said:

Buba, if meanwhile we can test whole buch of code, feel free to share source or hex

Click to expand...

Of course!

Here is my fork and the branch is called "higher cadence". There you will find the source code:
https://github.com/leon927/TSDZ2-Smart-EBike/tree/higher_cadence

Here is a quick and easy way to get the hex files. Created a folder on Google Drive:
https://drive.google.com/drive/folders/1HJMJc7cc9YsG1G83TUbpZwQxJcO2m023?usp=sharing

-----------------------------------------------------------------------------------------------------------------------------

By the way,

I always tried to have Marcoq and his great development in mind and make everything as modular as possible so he can easily develop and use these features on the OEM displays as well. This will make more users take the necessary steps to non-OEM displays in the future. Especially when they experience all the wonderful development Casainho and others have made.

Click to expand...

Hi Buba, I've just downloaded the hex files from the google drive (0.18 beta), tomorrow I will flash it on the bike to give it a try.
Is this release the so called "high cadence mode"? I have a 36v motor and I would like to make sure that everything is fine with the configuration.
I did not fully understand if those hex are based on casainho's v.0.17 plus your additions or some previous release (v.0.16?).
Thanks!

Buba, any chance of getting a disable throttle into the new 18.0 beta?
Since turning on the temperature protect disables the throttle that may be the best place to put it.

8: Motor Temperature Protection
Submenu 0:
0 = Throttle
1 = Motor Temperature Protection enabled
2 = Throttle disabled

Since walk-assist currently has an enable/disable feature that one is already good to go for coaster brake motors.

casainho said:

Rydon said:

Coaster brake motors do not have throttle or walk assist for safety reasons. Because the motor does not freewheel the throttle would spin the cranks. These particular motors have 8 pin connectors but the throttle wire is not connected to the controller. I opened it up and looked.

Click to expand...

So, for that motor configuration, user would need to keep disabled the throttle and walk assist.

I do not have time right now to develop this, maybe other developers can and submit a pull request with the code.

Click to expand...

Good to know, thanks Casainho. Appreciate all your work. Let me know if I can send you any other displays or TSDZ2 parts.

thineight said:

Hi Buba, I've just downloaded the hex files from the google drive (0.18 beta), tomorrow I will flash it on the bike to give it a try.
Is this release the so called "high cadence mode"? I have a 36v motor and I would like to make sure that everything is fine with the configuration.
I did not fully understand if those hex are based on casainho's v.0.17 plus your additions or some previous release (v.0.16?).
Thanks!

Click to expand...

Hi! The 0.18 beta has the high cadence mode for the 36 volt motor. I recommend to keep it at the standard setting though, at least until you are familiar with the new firmware. So if you have the 36 volt motor: set (1) in the "motor voltage type" sub menu under the configuration menu "Various". Take a look at the wiki for more info:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.18.X-%28beta%29

0.18.0 beta is based on the stable version 0.17.0 that Casainho and I worked on. It is not based on v.0.16.0.

Good luck and be safe!

Rydon said:

Buba, any chance of getting a disable throttle into the new 18.0 beta?
Since turning on the temperature protect disables the throttle that may be the best place to put it.

8: Motor Temperature Protection
Submenu 0:
0 = Throttle
1 = Motor Temperature Protection enabled
2 = Throttle disabled

Since walk-assist currently has an enable/disable feature that one is already good to go for coaster brake motors.

Click to expand...

I would absolutely implement that if it is desired, no problem at all! This will be fixed as soon as Casainho has reviewed the current pull request and is happy with everything. I can try to add that in the next pull request.

buba said:

Rydon said:

Buba, any chance of getting a disable throttle into the new 18.0 beta?
Since turning on the temperature protect disables the throttle that may be the best place to put it.

8: Motor Temperature Protection
Submenu 0:
0 = Throttle
1 = Motor Temperature Protection enabled
2 = Throttle disabled

Since walk-assist currently has an enable/disable feature that one is already good to go for coaster brake motors.

Click to expand...

I would absolutely implement that if it is desired, no problem at all! This will be fixed as soon as Casainho has reviewed the current pull request and is happy with everything. I can try to add that in the next pull request.

Click to expand...

I would leave throttle disabled by default and let user explicitly enable it. We can see throttle as something dangerous on this hardware combinations, so user must be sure that can enable it.

So for me would be:
0. Throttle disable
1. Throttle enable
2. Motor temperature sensor enable

i am using OSF ( open source firmware ) V 0.16
planned to try 0.18, is t necessary to erase tables before programming ?
actualy using 10s battery on a 36V motor, planned to build my 12S battery soon, did the motor with 12S gain rpm or is t necessary to activate " hight cadence mode " ?

saw that on v0.16 "cadence" was not displayed, jbalat asked and casainho said that it was necessary to use short press and long press on + button, is t it possible to use this button combinaison anytimes or in a special mode ?

regards .

casainho said:

I would leave throttle disabled by default and let user explicitly enable it. We can see throttle as something dangerous on this hardware combinations, so user must be sure that can enable it.

So for me would be:
0. Throttle disable
1. Throttle enable
2. Motor temperature sensor enable

Click to expand...

I completely agree. Functions such as throttle should always be disabled by default.

elem said:

i am using OSF ( open source firmware ) V 0.16
planned to try 0.18, is t necessary to erase tables before programming ?
actualy using 10s battery on a 36V motor, planned to build my 12S battery soon, did the motor with 12S gain rpm or is t necessary to activate " hight cadence mode " ?

saw that on v0.16 "cadence" was not displayed, jbalat asked and casainho said that it was necessary to use short press and long press on + button, is t it possible to use this button combinaison anytimes or in a special mode ?

regards .

Click to expand...

Nice of you to try it out!

I would always recommend to reset everything when installing new software with new functions. And then work through the menus to double check that everything is set to default values and as it should be by your prefererad values.

Regarding motor cadence: as you already know, the nominal voltage on the 36 volt motor should be around 36 volts. If you put anything more or less you effectively change the motors RPM. If you were to put double the voltage it would double the motors RPM.

In this case you wish to use a 12S battery, which is a battery with a nominal voltage of around 44 volts, on a 36 volt motor. That means that you will raise the RPM of the motor:

44/36 = 1.2222

Basically meaning that it will rotate 22 percent faster. Use the recommended motor voltage type settings and try it out before you select experimental modes.

If you were to use a battery with a nominal voltage of 48 volts instead, the ratio would be:

48/36 = 1.3333

Keep in mind that this is a simplified model.

Regarding cadence, not sure what you mean but I think it will be displayed. Take a look at the wiki and see if it answers your questions regarding cadence:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.18.X-(beta)

Buba : Regarding motor cadence: as you already know, the nominal voltage on the 36 volt motor should be around 36 volts. If you put anything more or less you effectively change the motors RPM. If you were to put double the voltage it would double the motors RPM.

In this case you wish to use a 12S battery, which is a battery with a nominal voltage of around 44 volts, on a 36 volt motor. That means that you will raise the RPM of the motor:

Click to expand...

Ok, that what i thanck
I tried 48v on a 36V motor ( TSDZ2 ) long time ago
12S is the better ratio for the rpm i want
I use 11s with marcoq set up with an other TSDZ2 ( for my sister ) as the user don t need faster rpm, the fact is that with 36v motor ( don t know if it s the same with 48V motor ) and stock firmaware, the use of the motor is very short, motor speen at maximum very quickly in mountain bike

buba said:

Here is my fork and the branch is called "higher cadence". There you will find the source code:
https://github.com/leon927/TSDZ2-Smart-EBike/tree/higher_cadence

Here is a quick and easy way to get the hex files. Created a folder on Google Drive:
https://drive.google.com/drive/folders/1HJMJc7cc9YsG1G83TUbpZwQxJcO2m023?usp=sharing

Click to expand...

hi buba

Before I go ahead flash and test this beta can you confirm that the controller firmware hex will work on both 6pin and 8pin controllers (I have 8 pin) and although the firmware is called higher cadence it also includes your walk assist and virtual throttle betas.


Thanks

buba said:

thineight said:

Hi Buba, I've just downloaded the hex files from the google drive (0.18 beta), tomorrow I will flash it on the bike to give it a try.
Is this release the so called "high cadence mode"? I have a 36v motor and I would like to make sure that everything is fine with the configuration.
I did not fully understand if those hex are based on casainho's v.0.17 plus your additions or some previous release (v.0.16?).
Thanks!

Click to expand...

Hi! The 0.18 beta has the high cadence mode for the 36 volt motor. I recommend to keep it at the standard setting though, at least until you are familiar with the new firmware. So if you have the 36 volt motor: set (1) in the "motor voltage type" sub menu under the configuration menu "Various". Take a look at the wiki for more info:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.18.X-%28beta%29

0.18.0 beta is based on the stable version 0.17.0 that Casainho and I worked on. It is not based on v.0.16.0.

Good luck and be safe!

Click to expand...

Hello, just back from the first wiring/connection of LCD3 with the v.0.18beta.
For info, my setup is LCD3 with a Y for the brake cut off, unfortunately the latter caused me 15mins of headache. In fact I had a trouble at the first power on because the display shown the full digits forever, same as Jbalat videos when he wired TX and RX the other way around. Since another user reported the issue again few post above I was worried that i swapped the wires, so I cut and inverted the TX and RX... unfortunately it ended up in same bad result.
I had the idea to unplug the brake sensors and to swap the wires again and... it worked. Before I had the brake sensor wire connected but it was away from the magnet as everything was not properly installed yet.

Bottom line is: if you have the brake sensors connected make sure the contacts are open, otherwise the display will not start correctly.

Said so, I made a quick setup in order to see if everything was in a good shape, but without proper road testing yet.
I set up the display light intensity to "0" (not "5") when the light state is OFF, and "80" when ON, but the first thing I observed is that on system power ON the light state goes to "5" and not to "0". If you enable the lights the display goes to 80, if you press again goes to 0 (no light), which is the value I set up in the configuration.
All in all: the display at power on does not keep the "light off" user setting. Possibly a bug?

Beside that the garage test was OK, the motor was working good. More testing to come.

Cheers.

Casainho, considering my post above I suggest you tu update the wiki to clearly state to disconnect the brake sensors (or make sure the magnet is connected to keep the circuit open) in order not to end up in frozen display at startup. Unfortunately the state is the same when TX and RX wirings are reversed, therefore the user may think that is the cause.

Thanks

Rafe said:

hi buba

Before I go ahead flash and test this beta can you confirm that the controller firmware hex will work on both 6pin and 8pin controllers (I have 8 pin) and although the firmware is called higher cadence it also includes your walk assist and virtual throttle betas.

Thanks

Click to expand...

Hello! Yes, it is supposed to work on both! And yes, it does include walk assist, cruise (virtual throttle) and all the other functions and features.

I managed to install 18 beta as well. For me the headache was is not clearing rom with option byte (had a strange issue when numbers in lower lcd3 row did not appear and when button is pressed the main kmh just blinked), other than that everything works as expected. Tomorrow will do a field test of ~80km In the appartment 5th level walk assist is too much

markjiizs said:

I managed to install 18 beta as well. For me the headache was is not clearing rom with option byte (had a strange issue when numbers in lower lcd3 row did not appear and when button is pressed the main kmh just blinked), other than that everything works as expected. Tomorrow will do a field test of ~80km In the appartment 5th level walk assist is too much

Click to expand...

That "bug" is known and happens when you do not reset to default values or configure every setting, in this case the Main Screen Setup. You really need a clean install if you do not want to look through the configuration menu and make sure that everything is as it should be.

When the firmware was installed it did not load the default values in the Main Screen Setup (see default values in the wiki). Thus, it took whatever values stored in the EEPROM. The firmware simply thought you did not want to display anything in the odometer field. The result: blinking kmh when pressing the ON/OFF button.

Solution for now is to either:

- Scroll through the configuration menu and make sure everything is set as desired
- Make a total reset so the default values are loaded and then configure as desired

thineight said:

I set up the display light intensity to "0" (not "5") when the light state is OFF, and "80" when ON, but the first thing I observed is that on system power ON the light state goes to "5" and not to "0". If you enable the lights the display goes to 80, if you press again goes to 0 (no light), which is the value I set up in the configuration.
All in all: the display at power on does not keep the "light off" user setting. Possibly a bug?

Click to expand...

Interesting... I have not altered or done anything to the display brightness code in beta 0.18.0. This leads me to believe that it is a bug carried over from previous firmware but no one noticed until now. Well done!

I tested v.0.15.0 and it worked as intended. So I tested v.0.16.0 and this version had no problems either. Tested the temporary v.0.16.1. It also worked. Then I started to test the v.0.17.0 betas and there I found a problem:

Between v.0.17.0 beta 1 and v.0.17.0 beta 2 the bug appeared.

It is a really simple fix and this will be addressed in the next pull request.

Very nice of you to report this!

buba said:

- Scroll through the configuration menu and make sure everything is set as desired
- Make a total reset so the default values are loaded and then configure as desired

Click to expand...

What I do and it works well for me is when I first start ST visual programmer it automatically presents pages of all zeros for both the programme memory and data memory, then I simply programme each tab with the zeros so nothing remains of the previous firmware. Then I write the new version into the programme memory.

This new beta of yours Buba did not even require a reset in the configuration menu and it was the easiest version to configure so far. Also the changes you have made inside the configuration menu have made it a lot easier to set up by adding those labels You really have done a great job.

I have not tested it on the road yet and am hopefully off on a reasonably long ride in the morning, weather dependent. I've tested walk assist indoors and that is looking good, the route I have planned has a 33% narrow footpath so that will prove it. I have left the current ramp setting on your default value but I am running on the metal gear at the moment. One thing I have noticed is that although I can see the manual throttle value vary in the advanced technical menu, the throttle does not actually drive the motor anymore whether cruise control/virtual throttle is enabled or disabled but I assume that is intended.


I can see you have put a great deal of time and effort into this and I am very grateful indeed.

Cheers

marcoq said:

casainho said:

marcoq, can you please create a new thread for user support to your branch?

Click to expand...

No problem casainho... I will create a new thread for OEM displays users. :thumb:

Click to expand...

Did this happen? If so, could someone post a link to the new FOS firmware with OEM display users thread? This is such an exciting development with a much easier way to get started with the Flexible Open Source firmware. Many times more people will get to use the amazing flexible opensource software if this development continues to maturity.

Rydon said:

marcoq said:

casainho said:

marcoq, can you please create a new thread for user support to your branch?

Click to expand...

No problem casainho... I will create a new thread for OEM displays users. :thumb:

Click to expand...

Did this happen? If so, could someone post a link to the new FOS firmware with OEM display users thread? This is such an exciting development with a much easier way to get started with the Flexible Open Source firmware. Many times more people will get to use the amazing flexible opensource software if this development continues to maturity.

Click to expand...

Is this https://endless-sphere.com/forums/viewtopic.php?f=30&t=98281&e=1&view=unread#unread what you are looking for?

buba said:

thineight said:

I set up the display light intensity to "0" (not "5") when the light state is OFF, and "80" when ON, but the first thing I observed is that on system power ON the light state goes to "5" and not to "0". If you enable the lights the display goes to 80, if you press again goes to 0 (no light), which is the value I set up in the configuration.
All in all: the display at power on does not keep the "light off" user setting. Possibly a bug?

Click to expand...

Interesting... I have not altered or done anything to the display brightness code in beta 0.18.0. This leads me to believe that it is a bug carried over from previous firmware but no one noticed until now. Well done!

I tested v.0.15.0 and it worked as intended. So I tested v.0.16.0 and this version had no problems either. Tested the temporary v.0.16.1. It also worked. Then I started to test the v.0.17.0 betas and there I found a problem:

Between v.0.17.0 beta 1 and v.0.17.0 beta 2 the bug appeared.

It is a really simple fix and this will be addressed in the next pull request.

Very nice of you to report this!

Click to expand...

Great, good to know it is a simple fix.. very minor bug but worth to fix it :thumb:

Today I had the pleasure to test the firmware v.0.18 beta along 60 km with about 500m climb, it was the first trip with the OpenSource Firmware other than some around-the-house test.
I admit I had a very good feeling, a bit hard to recall all the functions in KT-LCD3 but at the end it is just matter to getting used to.
Once again, thanks to casainho and all the active developers down here.

I tried the cruise control as it is a new funcion of this beta, and it works quite good given the fact that it may be a bit difficult to hold the DOWN button for a while. I consider it a sort of "emergency mode" (e.g. broken pedal) so it is good to have the chance to use it if needed! :thumb:

I did not properly try the WALK assist as the climb was on asphalt road, anyway I had the impression that the power to the chain was quite quick and strong at startup, is there a power ramp to optimize perhaps? If I remember correctly the walk assist from marcoq version was smoother.

The SOC appeared OK from 100% down to 40% when I finished the trip, I do not have the clue if the motor consumes less energy compared to the stock firmware because:
1. I never ran out of battery before (I have a 625 Wh battery)
2. The stock firmware battery indicator is strongly non linear and the first bar of battery lasts 50-60 km
I trust the expert that made the comparison from 100 to 0 on the same trip.

Now I would like to give a suggestion for a possible nice improvement: since you Buba developed a great experience on time and distance stuff on this motor, is it possible to implement a sort of "estimate distance left" indication?
I guess that all the needed data are already in place to do that, for instance I would use a sort of power_left variable (capacity - actual Wh consumed) and given the actual power from motor (W) you obtain the hours left. Multiply this value to the actual speed you obtain the left km before battery drains.

The actual power from the motor can be taken as moving average on the last 10s (in order not to have the results changing every second), updated every 5 s, and also the actual speed should be obtained from moving average on the same interval.

A pseudo code of what I have in mind is:
power_left := battery_capacity - Wh_consumed_since_last_charge
avg_motor_power := moving_average(actual_motorW, 10s) // calculated on the last 10 seconds or whatever is best
time_left := power_left / avg_motor_power // time left at this motor rate
avg_speed := moving_average(actual_speed, 10s) // average speed on the last 10 seconds or whatever is best
distance_left := avg_speed * time_left

The number can be shown in the SOC menu (n.2 if i remember correctly) or in a dedicated menu.

What do you thing about it? I think it is a nice feature to plan the assistance rate in order not to run out of battery specially in long trips .

Uh... quite a long post... i hope you manage to get to the end of it.

I successfully loaded v0.17 beta 4 following the github instructions and jbalat's video. Thanks to all, especially casainho, jbalat, and everyone who contributes to the github instructions. I have worked out a nice connectorized solution that connects throttle and brakes with waterproof connectors https://endless-sphere.com/forums/viewtopic.php?f=28&t=79788&start=4200#p1439930 I am now on the released v0.17.

The bike rides well, I love all the additional information on the KT-LCD3, overall great but some issues. The first ride had insane boost. The default assist multipliers (0.5 1.0 1.5 2.0 2.5) were not realistic. I could easily get 500 watts assist at 0.5.

Human Power Reading and unexplained change
For example 0.5 did not seem like 1.5X human power, it seemed like the assist was 3X too high, maybe 3.5X human power. Higher levels were weird. I would barely touch the pedals and get hundreds of watts. So I set the multipliers low (0.1 0.2 0.3 0.4 0.5 0.7 0.9 1.2 1.5) and went for a long ride to try to sort it out. First I figured maybe the torque sensor calibration was off, so I put assist to zero and looked to see if human power was reasonable. I maintained 13mph on the flat and displayed human power was 60W (cadence 72). bikecalculator.com estimates 80W, so the calibration seemed a bit low but not bad. But at Assist Level Multiplier 0.2 displayed motor power was similar to human power where it should have been 20% of human power. Still it rode nicely at 0.1 (motor W 1.5X human power) or 0.2 (motor W 2X human power). Assist was smooth.

And then, mid ride, the displayed human power went much higher. It was flattering, but I'm pretty old and I know I can't sustain 300W for long, but the bike was telling me I was! And the assist multipliers were now sort of accurate. At 0.5 motor power was about 1.5X human power. So before I got semi-realistic human power and 5X the boost multiplier, or, without changing the configuration, I got unrealistic human power and the multiplier was OK. But the assist was jumpier than before. At low assist the assist was jumpy where before the weird change it was smooth. I prefer the early misbehavior (decent human power W, excessive but smooth assist) to the later misbehavior. But with an intermittent problem like this I don't think I get to choose.

This is possibly related to what Rafe reported https://endless-sphere.com/forums/viewtopic.php?f=30&t=93818&start=1550#p1436734n

Throttle
The throttle worked on v0.17 beta 4, it doesn't work on the v0.17 final. It is wired and connected properly. In Menu 9 submenu 0 (ADC throttle) varies from 44 to 179 when I manipulate the throttle. But 9 submenu 1 (Throttle) always reads zero, and the throttle no longer spins the motor as it did with v0.17 beta4.

Human Power Display
Menu 9 submenu 5 (Pedal human power) always reads 0. Odometer field 4.0 (Pedal W) works

Rolling backwards
Compared to stock firmware the motor fights slow backwards movement (for example at a stop light). If I activate the brake sensor it resists less.

Torque Pulses
When I am stopped the bike sometimes jumps a little bit (Startup BOOST is disabled). Not enough to cause me to lose my balance, but it never happened on stock firmware. It seems not to happen if the brake sensor is active. With the stock firmware I did not bother with the brake sensors, and never needed them. They seem more needed with the Open Source Firmware.

I hope you guys can help on the human power and assist issue, that is the biggest problem by far.

buba said:

Rafe said:

hi buba

Before I go ahead flash and test this beta can you confirm that the controller firmware hex will work on both 6pin and 8pin controllers (I have 8 pin) and although the firmware is called higher cadence it also includes your walk assist and virtual throttle betas.

Thanks

Click to expand...

Hello! Yes, it is supposed to work on both! And yes, it does include walk assist, cruise (virtual throttle) and all the other functions and features.

Click to expand...

Hi Bubba

I gave 18.0 beta a 60 mile run today.

The good news is walk assist works a treat. I use 9 levels of pedal assist and to walk alongside the bike up a 33% climb I ended up selecting level 9 and bottom gear and it was faultless, really smooth constant speed (better than my BBSHD even) Plus I had two large panniers and a rear rack bag as well. You have done an excellent job on that.


The bad news is Cruise control. It works perfectly with a target speed set in the configuration menu, I settled on 12mph in the end and it cycled well between 11mph ish and 12mph, the default 15mph was fine too. But when I got adventurous and tried to test 'maintaining current speed' then after I pressed the down button it went straight to the previous 12mph setting and maintained 12mph with no button pressed. Fortunately I have the rear brake wired to cut out the motor and once I had slowed the bike below what must be the minimum speed for cruise control it came out of cruise control But as soon as I increased speed again the cruise control cut in again to maintain 12mph.Very scary and would have been very dangerous if I did not have the brake cut out as there was no quick way to stop the motor. In the end I had to switch the system off and back on and go into configuration to go back to target speed mode instead and continued the journey with no further issues in that mode. I don't know if it is practical but would it be possible to have an option to use the thumb throttle instead of cruise control?

Slightly bad news and may only affect a system using imperial miles. Function 7 wheel speed, 7.0 current, 7.1 average and 7.2 max display the MPH in the main field and kmph in the sub field and what ever function is selected it is displayed in the main field current speed display in all 8 display modes.

So really a big thumbs up for walk assist but cruise control has a serious bug in maintain current speed mode.


Hope that helps.