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

casainho said:
We can provide motor assistance as soon user makes a specified minimum amount of force on the pedals, even before they start rotating.

Of course we can, but what is the sense?! The motor will produce only heat and no mechanical power in this case.
I don't think that with this function the acceleration at a traffic light is measurably different than without the function...

regards
stancecoke
 
stancecoke said:
casainho said:
We can provide motor assistance as soon user makes a specified minimum amount of force on the pedals, even before they start rotating.
Of course we can, but what is the sense?! The motor will produce only heat and no mechanical power in this case.
You mean there is no sense in using a throttle, just like electric motor cycles or cars does?
 
casainho said:
vadda said:
hydrinium.h2 said:
Has anyone had a difficult time finding working LM35s for the temperature sensor? I've bought 2 lots of 10 from different vendors and I can't get it to work on the open source software. The bike just doesn't register any change from the sensor. I guess part of the problem is that they're from ebay and chinese knockoffs, but you would think that 1 in 20 would be ok. I've tested the bike with TMP36 and a 10k potentiometer and they both report values that change with input so I don't think its my soldering job.

Yes,
after several attempts from different sellers, I bought them on Amazon choosing the product based on feedback
You guys should report negatively that sellers on eBay.

Well for future reference the bad LM35s were:
62AB LM35DZ from xiumeche-0 - 9/10 just didn't work, 1/10 was reported 20 degrees lower than actual temp
89015 LM35DZ from wonder_2018 - These seemed to work vaguely but they fluctuated output wildly between actual temperature and 0. Possibly due to the 5v reference voltage fluctuating in my raspberry pi ADC setup?
Both didn't register on the bike.

Actually I've read its a common issue for analog temperature sensors to fluctuate readings due to movement, fluctuation in reference voltage etc, and that a capacitor is recommended to smooth output. But the TMP36 gives pretty smooth readings on the same setup so I don't think this level of fluctuation is within spec.
 
casainho said:
You mean there is no sense in using a throttle, just like electric motor cycles or cars does?

It makes no sense to push current through the motor windings when the motor doesn't turn.
The efficiency of a electric motor is simply exactly zero at zero rpm.

motorcurve.gif


On a car or motorcycle you can't avoid that. On a bicycle you can avoid it.

But we had this discussion for several times now.

regards
stancecoke
 
casainho said:
buba said:
Startups: We need to confirm that the user is rotating the pedals to enable assistance.
I don't agree on this, otherwise the throttle alone could not be used. We can provide motor assistance as soon user makes a specified minimum amount of force on the pedals, even before they start rotating.

We agreed that it is best that you test the coming beta and then we can have further discussions about this particular topic. I think why you like the pedal-assistance-without-pedal-rotation is because it engages the motor very quickly. Something that can be solved with minimum cadence without pushing current through a stationary motor.


casainho said:
buba said:
So we do this by increasing the minimum cadence measured by the system and thus get a more responsive startup.
Again, a more responsive startup is using the torque sensor. Or why do we have a torque sensor on this motor?

I have previously mentioned that the torque sensor is slower to react than a good cadence sensor. So if only using the torque sensor it will be slower to disengage the assistance.

Again, not saying what to do. Just asking to discuss this after we all have the chance to test the beta.
 
casainho said:
buba said:
Startups: We need to confirm that the user is rotating the pedals to enable assistance.
I don't agree on this, otherwise the throttle alone could not be used. We can provide motor assistance as soon user makes a specified minimum amount of force on the pedals, even before they start rotating.


Besides running the risk of burning out a stationary motor that is very dangerous. For example a cycle trail crossing a main road and weight is placed on the pedal waiting for the traffic and the bike takes off in front of a car? Needs to be rotation and torque, belt and braces.
 
stancecoke said:
casainho said:
You mean there is no sense in using a throttle, just like electric motor cycles or cars does?
It makes no sense to push current through the motor windings when the motor doesn't turn.
The efficiency of a electric motor is simply exactly zero at zero rpm.

motorcurve.gif

As we can see on the graph, motor torque is max exactly at zero rpm and that is what is needed at startup: motor torque.

stancecoke said:
On a car or motorcycle you can't avoid that. On a bicycle you can avoid it.

But we had this discussion for several times now.

I can understand that purists don't want to use a throttle. Not everyone is in good health condition so a throttle or torque sensor used as a throttle at startup, to save the knees or reduce the peaks of effort, is an important feature.


Rafe said:
Besides running the risk of burning out a stationary motor that is very dangerous. For example a cycle trail crossing a main road and weight is placed on the pedal waiting for the traffic and the bike takes off in front of a car? Needs to be rotation and torque, belt and braces.
Our firmware already works like this (v0.19.0, v0.18.0, etc) and there is no risk of burning the motor because there is a specific protection to that. And if you don't like this feature you can just keep it disabled. If like me you prefer to use this feature, you keep your brakes pressed on trail crossing and just release them when you want (this is valid if you want to keep the throttle pressed or you hit throttle by mistake) - at any time you hit the brakes and the motor immediately stops.
 
my opinion is that a starting system based on too sensitive cadence is a risk. Just move the bike by touching the pedals and part forward. a quarter turn of delay is a security
 
andrea_104kg said:
my opinion is that a starting system based on too sensitive cadence is a risk. Just move the bike by touching the pedals and part forward. a quarter turn of delay is a security
If you see, the suggestion you give means loosing the sensitive/fast reaction that Buba seems to be working so hard to get. Also means user will need to make most of the initial effort to start moving the bicycle, which I prefer to pass to motor and not to me. How to have all of this flexibility?

Maybe this could be a configuration to user:
- how many PAS impulses (quarter turn would be 5)
- how many kgs on pedals (my legs weigh 10 kgs, so could be something like 15 kgs)

Still I think that start with cadence = 0 should be an option as it is now.
 
In fact in the 18 version and later in the 19 the start, without boost, is a bit weak, on my mtb it takes almost half a pedal stroke and takes a little time to reach the maximum power. I don't care because I have very short gearshifts. But I can compare with the brose of the turbo levo which is much more progressive and modular.
I tried the boost, it's really nice, but I'm afraid the blue gear is very stressed.
So improvements in effort sensor management are welcome.
I still can't understand how the dual cadence mode will be, if the engine will become like a bbs.
I think that anyway the work of buba must be respected and before judging it must be tried.
Since it will be a very different thing from version 19 I think that if you don't like it you will be able to stay on 19 which is very good anyway.
As I said, a very sensitive cadence can be dangerous, even if you move the bike by hand, if you hit the pedals the bike starts.
Furthermore, in the cadence mode I think it is essential to have the brake cut offs.
Finally, if the problem is starting with zero frequency, if up until now it has not given problems it can be maintained like many other options.
 
buba said:
chri27.5 said:
good morning,
a question for buba & casainho,
Has it ever happened to you that the motor suddenly remains on while you are pedaling and continues to turn without ever stopping?
Thank you for your wonderful job that with patience and dedication you carry on.
Excuse my English
Thank you

Good morning,

Hmm... As a developer I have several times forced the motor to run and have created several private versions that do continuously run for testing. But have never had a motor-run-away problem on a stable release with my personal settings. But I think there are certain cases and situations where it maybe is possible to force a motor-run-away on a stable release. Not sure though. Have nonetheless actively worked to eliminate all possible safety problems in the next version.

Have you experienced any problems? If so, please let me know! Also include your settings when it happened and the overall situation that caused it. I will try to help!

Hi Buba,
thank you very much for your interest in me, the problem was intercepted by marcoq is solved, since I use a vlcd5.
I wanted to congratulate you on the work you are carrying out in 2.0, I fully agree and approve of the changes you have implemented, so before challenging your work people should test the changes and then discuss them.
I understand that every developer has his beliefs, but we must accept that being many, each one has the right to choose his own solution which he considers the best.
I think you deserve respect for everything you've done.
Casainho if a great genius, and in Italy everyone recognizes him, but let me give you a hint, let's finish his work, so let's test if everything is ok.
after the tests you can modify the code to your liking, perhaps creating two versions, this would be a great thing for the community, every one is free to choose what to use.
Excuse me if I intruded and thank you so much for your wonderful work.
Chri27.5
 
Rafe said:
casainho said:
buba said:
Startups: We need to confirm that the user is rotating the pedals to enable assistance.
I don't agree on this, otherwise the throttle alone could not be used. We can provide motor assistance as soon user makes a specified minimum amount of force on the pedals, even before they start rotating.

Besides running the risk of burning out a stationary motor that is very dangerous. For example a cycle trail crossing a main road and weight is placed on the pedal waiting for the traffic and the bike takes off in front of a car? Needs to be rotation and torque, belt and braces.

I appreciate your understanding, Rafe!

I am so scared of doing something that can result in someone getting injured. That would destroy me! (So please be safe everyone!) This is why I am trying to take the safest path at all times. But I still try to offer a great experience and make it overall better. And having spent over a month of constant developing I took some decisions that can help us move forward to a beta quicker.

I hope everyone understands that this project is dynamic and will always change and evolve. So what is offered in the next beta is not final.



andrea_104kg said:
In fact in the 18 version and later in the 19 the start, without boost, is a bit weak, on my mtb it takes almost half a pedal stroke and takes a little time to reach the maximum power. I don't care because I have very short gearshifts. But I can compare with the brose of the turbo levo which is much more progressive and modular.
I tried the boost, it's really nice, but I'm afraid the blue gear is very stressed.
So improvements in effort sensor management are welcome.
I still can't understand how the dual cadence mode will be, if the engine will become like a bbs.
I think that anyway the work of buba must be respected and before judging it must be tried.
Since it will be a very different thing from version 19 I think that if you don't like it you will be able to stay on 19 which is very good anyway.
As I said, a very sensitive cadence can be dangerous, even if you move the bike by hand, if you hit the pedals the bike starts.
Furthermore, in the cadence mode I think it is essential to have the brake cut offs.
Finally, if the problem is starting with zero frequency, if up until now it has not given problems it can be maintained like many other options.

Thank you for your opinion, andrea_104kg!

I can assure you I would never release something that will make the experience lesser in any way. And certainly not more dangerous. It is just more responsive. It is very hard to explain so that is why I can not wait for you to try it out!

Also, I would appreciate your feedback and opinions of the 0.20.0 compared to the Brose. So I hope you will post some interesting notes in the future!
 
chri27.5 said:
buba said:
chri27.5 said:
good morning,
a question for buba & casainho,
Has it ever happened to you that the motor suddenly remains on while you are pedaling and continues to turn without ever stopping?
Thank you for your wonderful job that with patience and dedication you carry on.
Excuse my English
Thank you

Good morning,

Hmm... As a developer I have several times forced the motor to run and have created several private versions that do continuously run for testing. But have never had a motor-run-away problem on a stable release with my personal settings. But I think there are certain cases and situations where it maybe is possible to force a motor-run-away on a stable release. Not sure though. Have nonetheless actively worked to eliminate all possible safety problems in the next version.

Have you experienced any problems? If so, please let me know! Also include your settings when it happened and the overall situation that caused it. I will try to help!

Hi Buba,
thank you very much for your interest in me, the problem was intercepted by marcoq is solved, since I use a vlcd5.

Glad it was solved! :)



chri27.5 said:
I wanted to congratulate you on the work you are carrying out in 2.0, I fully agree and approve of the changes you have implemented, so before challenging your work people should test the changes and then discuss them.
I understand that every developer has his beliefs, but we must accept that being many, each one has the right to choose his own solution which he considers the best.
I think you deserve respect for everything you've done.

Wow...! Means a lot, grazie mille, Chri27.5! Hopefully we will have some great discussions soon and improve the 0.20.0 in many more ways!
 
Okay, this was a challenge but automatic calibration: done!

I have now completed the automatic calibration process of the cadence sensor for those that are interested in using a more tuned cadence sensor. For anyone not interested there will still be a standard setting where it will operate just as before. But still greatly improved compared to 0.19.0.

Will clean up the code and work through the night to validate everything so it is finished for tomorrow. Am working as fast as I can to get to a beta. Sorry guys.
 
buba said:
I have now completed the automatic calibration process of the cadence sensor for those that are interested in using a more tuned cadence sensor.

I took a look at your changes in the code, two comments:

Code:
ui8_cadence_sensor_magnet_pulse_width = (uint32_t) (ui16_cadence_sensor_ticks_counter_min_high / ui16_cadence_sensor_ticks_counter_min_low) * 100;

would be better :wink: :

Code:
ui8_cadence_sensor_magnet_pulse_width = (uint32_t) (ui16_cadence_sensor_ticks_counter_min_high * 100) / ui16_cadence_sensor_ticks_counter_min_low;


You put very much code in the fast loop (motor.c). You would better keep the fast loop as clean as possible and do all not time critical calculations in the main loop....

regards
stancecoke
 
Hi all, i have noted that removing the battery the trip counter is resetted... Is possible to store trip counter in eeprom for next versions? Sometimes is useful to park the bike without the battery that can be removed for charging... would be nice if trip counter wouldn't be resetted in this situation...
Thanks in advance
 
buba said:
casainho said:
Still I think that start with cadence = 0 should be an option as it is now.

And it is very easy to add if you still feel it is needed after testing the 0.20.0.

Hi guys, I have recently installed the brake switches bought a year ago and never installed due to lack of time, and I must say that enabling "startup without pedal rotation" the feeling especially at the start is fantastic. Even in motion when you use the brakes to slow down and continue to make a slight force on the pedals, the engine restart is very fast as soon as you release the brake.
I believe this setting must be activated only if the ebrake are present. So for do that we can enable it only after the firmware has detected the ebrake!

A safety solution could be:
When the engine is started by the torque sensor, a delay of 2-3 seconds (maybe less or configurable parameter) before stopping the current if there is no pedal movement, it may be enough to prevent engine damage!
And to restart the engine the first time, after a wheel lock situation, confirm the movement of the pedals before the engine starts.
But, let's wait to see the beta first
Thanks You guys!!!
 
I also start using startup without pedal rotation. Never had problems with safety with bike "running away", only pedals are twitching a bit when resting feet on pedal on traffic lights stop. Startup with only pedal rotation is pretty slow, especially on v0.19.0.
I vote not to remove this option.

Update: adjustable minimum torque sensor / PAS rotation threshold would be good.
 
stancecoke said:
buba said:
I have now completed the automatic calibration process of the cadence sensor for those that are interested in using a more tuned cadence sensor.

I took a look at your changes in the code, two comments:

Code:
ui8_cadence_sensor_magnet_pulse_width = (uint32_t) (ui16_cadence_sensor_ticks_counter_min_high / ui16_cadence_sensor_ticks_counter_min_low) * 100;

would be better :wink: :

Code:
ui8_cadence_sensor_magnet_pulse_width = (uint32_t) (ui16_cadence_sensor_ticks_counter_min_high * 100) / ui16_cadence_sensor_ticks_counter_min_low;


You put very much code in the fast loop (motor.c). You would better keep the fast loop as clean as possible and do all not time critical calculations in the main loop....

regards
stancecoke

That seems to be taken from some older commit. Please take a look at the latest:

https://github.com/leon927/TSDZ2-Smart-EBike/tree/testing-pwm-acc

No calculations are done in the fast loop. Just a switch and a couple of ifs. Execution time is the same and depending on what case you are looking at it is even faster. Especially as other things have been improved in the fast loop so in the end it should be as fast or faster.

But thank you for looking at the code and giving feedback!
 
mauri_78 said:
Hi all, i have noted that removing the battery the trip counter is resetted... Is possible to store trip counter in eeprom for next versions? Sometimes is useful to park the bike without the battery that can be removed for charging... would be nice if trip counter wouldn't be resetted in this situation...
Thanks in advance

There are three distance measurements:

- Odometer (saved in EEPROM)

- Trip (saved in EEPROM)

- Distance since power on (not saved in EEPROM)

This means that all except one are saved in the EEPROM if you power down the system with the ONOFF button. Only the "distance since power on" is reset every time. Let me know if something is not working and we will fix it!
 
I noticed ADC torque sensor calibration min value fluctuates +-5 each start.
Is there downside to increase sample count twice, for example, to 32? As I understand each reading is only 10ms.
 
buba said:
Demion said:
I noticed ADC torque sensor calibration min value fluctuates +-5 each start.
Is there downside to increase sample count twice, for example, to 32? As I understand each reading is only 10ms.

Solved in the coming 0.20.0 :) It calibrates perfectly every time.

Wonderful work Buba!! :D :D :D
 
Back
Top