Attempt at cheap homemade version of Harmony

[Oran]

I've now got the Arduino to log cadence as well as speed. I had to modify the cycle computer code so that it also works with timer 2. This means increasing the interrupt to 10kHz instead of 1kHz as the timer is 8bit instead of 16bit and can only count up to 256 not 65536.

Here's an example of some cadence and speed data.


I was out on a ride and found a good cadence so decided to stop adjusting the potentiometer and removed the planet from it. I continued for 30 miles and the following graph is the resulting summery of the cadence values. I know its good at maintaining a steady cadence but this graph proves it.



Since then I have left the potentiometer untouched and have commuted to work a number of times. I find my cadence is sometimes too high or too low but its no more than the difference between gears on a derailleur bike. The simplicity of not worrying about the pot position is rather nice, like riding a single speed.
I should now be very easy to find the relationship between potentiometer position and the resulting average cadence. With this information I can assign a value to a button or switch position and know what cadence I will get. Just need to put the planet back on the pot and keep logging data until I find my favourite cadence values.

[Oran]

Recently I've been experimenting with Bluetooth communication with the Arduino using serial communication. Part for fun to see how it works but also with the possibility of changing setting using a mobile app. As I want to minimize the number of buttons on the handlebars it would be useful to know how many different cadence setting I’m most comfortable with. Also it is proving difficult using the data to narrow down what my preferred cadences are. So I setup this on a mobile app, each button sends a number via Bluetooth to a module attached to the Arduino's serial monitor pins RX0 and TX1.



Using the data I have logged it was easy to find the relationship between potentiometer value and resulting cadence. With this I created an Arduino program that takes a number from the phone app via Bluetooth and enters an equivalent potentiometer value into the servo position equation. It worked very well and once the Bluetooth is connected it stayed connected and made instant changes to my cadence. It was even possible to notice the difference between 65 and 68rpm. Having my phone on the handlebars and continuously on is not very practical for everyday use but great for experimenting with cadence settings. If I don’t think buttons on the handlebars will be waterproof and reliable enough I’ve thought of something else. An indexed downtube shifter attached by cable to a linear potentiometer which can be in a waterproof enclosure.

What I really want to use the Bluetooth for is to change between different modes. I’ve discovered that there is no perfect equation for calculating the servo position. What helps improve shifting when accelerating is annoying as the bike slows on a hill. I’ve so far created 3 different modes.



The first I’ve been using for a while it’s generally good for most riding. There’s a delay in when the shifting starts so that the hub remains in full underdrive up until around 5mph. Allows cadence to increase when starting and ensures proper down shifting when the bike slows on a steep hill. Keeps a reasonably constant cadence over the speed range although it drops slightly at higher speeds which I prefer.



City mode has the shifting start almost as soon as the wheel starts to move. This helps counteract shifting lag during acceleration which can create a spike in cadence see graph below. Cadence stays higher as the speed increases.



This one uses an equation that deliberately makes cadence vary inversely proportional to speed. This I find good for undulating roads with short steep hills. The sort of situation where power out varies considerably and would require constant cadence alterations. It tends to encourage big changes in speed which helps to even out power output. On the down hills a bigger gear helps build up speed and momentum. As a hill is climbed the bikes momentum is used up before the speed drops and cadence increases by which time it’s easier to climb the remainder of the hill slowly.



I know for what is suppose to be an automatic bicycle I'm adding a lot of different user inputs but its just so easy to make modifications and get it working to perfection. In its current state its possible to just set the cadence to say 75rpm and forget about it, would be perfectly rideable.

[Normand_Nadon]

The main issue with these hubs is that Fallbrook won't change their idea that such a device is maintenance free... There is no such thing as a maintenance free CVT... It works by friction, hense wear occurs, it is undeniable!

I love this hub, don't get me wrong! I would just appreciate that Fallbrook realises that this product needs some sort of maintenance when used heavily and that they start selling parts and fluids to maintain them!

BTW Oran, you are amazing... Would you be living in the area, I would hire you in my shop right away!

Envoyé de mon SAMSUNG-SGH-I747 en utilisant Tapatalk

[Oran]

The app is a good idea, I can see it having potential for helping to refine the shifting. Will be interesting to see what useful data can be gathered from the phones motion sensors. Its something my code is missing, a method of increasing cadence to match required increase in power output due to gradients and acceleration. The other possibly more reliable method would be to measure the force on the pedals. Likely to be expensive as its basically a power meter that's required. I was going to investigate the sensors used on ebikes to detect pedal pressure so that the motors assistance matches riders effect.

I've had a lot of hubs apart and made modifications but not so far done a service on a hub. As Narmand said in the last post and I agree there is no such thing as maintenance free. I should really investigate replacement oil but I've yet to locate some that's affordable and I believe will work. Needs to have a high traction coefficient.
When it comes to protecting these hubs from harm I've never been that bothered about it. I tend to like to give things hard use but not abuse and try to fix anything before it becomes a reason for failure. Fallbrook have always been happy to replace hubs and they are all prototypes at the end of the day. I'm doing them a favour by finding the weaknesses so the next model will be stronger. I did work on trying to reduce stator wear but this should be fixed in the N380s. An oil change every 10,000 miles would be good for extending the hubs life. Without replacement oil I've fitted magnets in my N380 when it was new. They are effective at collecting the more harmful steel particles.

If you're referring to the design of our servos, the code that runs it and protecting the hub. I can only see the speed of shifting and doing so too fast under load being a potential issue. Now that I know the stator wear is a simple metal hardness issue I haven't seen any evidence that shifting has an affect on the life of a hub. I've always shifted under load during acceleration and with the powerful servo I'm using its even more so.

I have heard about the reliability issues with the Harmony and about the new version being more robust. Over the years I've written a lot about the issues with older model hubs. I believe these as you say have been dealt with. When it comes to issues with the Harmony servo I have no experience of it apart from a 5 min ride at a bike show. Anything with servo's and electronics is going to be less reliable due to the increased complexity. There are several possible failure points. The servo must be able to withstand being stalled as the shifting will lock up under some conditions and under high pedal load. The electrics have to be resist to vibration and be waterproof, along with all the wiring, sensors and user inputs. Correct operation relies on inputs from sensors which can go wrong.
Making something that will continue functioning without attention is a real challenge. I would consider my setup to be very reliable but things have gone wrong over the past 2000 miles. An Arduino failed, the servo plug came loose and the derailleur position switch got moved out of alignment. The last two are entirely down to things I could have done better. From a customer perspective who had spent money if those things had happened I probably wouldn't be happy.
The best designs are the ones that are as simple as possible, easy to fault find and made up of easy to replace modular parts.

Narmand I appreciate your compliment, you should be careful what you say or I'll be moving over to Canada :-)

[Oran]

This is the data logging setup I've been using. The wires have broken again at the connection to the header pins and I've got more than enough data for the moment so its time to rethink it. I've just ordered a data logging shield for an Arduino Nano to give it a go. I'd like to incorporate it into my new two Arduino design so I always have the option to log data if I want to.




Next stage of the project is to work on the user interface. I have a few ideas and I'm not sure at the moment if any of them will be the perfect solution. Part of me wants it to be a bicycle that you just switch on and ride with very few extras to get damaged by weather. Maybe have a switch to change between two cadences and modes changeable by mobile app and Bluetooth. This is what I've been using for the past couple of weeks and it works quite nicely. The potentiometer isn't that great when it comes finding the right cadence, it needs some form of indexing. A downtube shifter attached by cable to a linear potentiometer which can be in a waterproof enclosure has potential. There's also a possibility of adding a potentiometer to the original shifter which I think could work nicely. Would make it very easy to use like a normal bike only better. Both would need some sort of spring arrangement to tension the shifter in the same way as the derailleur would.

Next option is to go all fancy and add a display. There are some impressive looking touch screens available which have a user interface that is fully customizable and dealt with by the screens own possessor. This make the Arduino programming very simple in comparison. This opens up all sorts of options to input different modes change cadence and display information such as speed, cadence, battery voltage etc. The disadvantage is increased power consumption, waterproofing and being able to see it in full sun and press the right bit when the bike is moving.

So a couple of decisions to be made, Bluetooth or LCD touch screen and potentiometer in a shifter or simple switch.


Also I would be interested to see how accurate I can get it to maintain a cadence. In its current state its perfectly fine and eventually I want to connect the servo to the hub via 2 gears which will help. There are times due to cable slack and the plastic shift interface that cadence can vary by around 10rpm as the shift direction changes. To fix this would require sending the cadence value from the data logging Arduino 2 to the main control Arduino 1. I'd add the cadence value into the main equation to make small alterations, speed would still mostly determine the servo position.
Would be interesting to see how well shifting by cadence sensor alone would work.

I quite like the idea of two Arduino's working together for reliability, see drawing. Both able to take control of the servo and send information between each other and know what to do if a response wasn't received. One would measure speed the other cadence. Under normal conditions the speed or main control Arduino 1 would do the shifting taking cadence values from Arduino 2 if required. If Arduino 1 failed Arduino 2 would take control of the servo and use Timer 2 for PWM instead of cadence measurements.



How everything is going to connect together and how far I want to take this I'm not sure about at the moment. Next stage is to get Arduino 2 data logging and receiving mode settings from Bluetooth. Then get Arduino 1 to receive mode and cadence values from Arduino 2 and make use of them.


Sent from my BV5000 using Tapatalk

[Normand_Nadon]

Damn, Americans did not even have Half that tech to land on the moon! Who knows what you are about to achieve?!

[Oran]

It is amazing the processing power available these days at such low prices, I would think a Raspberry pie could actually land a space mission on the moon. With the two Arduino's functioning its definitely what could be described as a smart bike and can now maintain a cadence with amazing accuracy.



The two Arduino's have most of their pins connected together although most aren't used but it adds extra support. I left pins D10 - D13 unconnected as they can be used for serial communication with the data logger. The data logger is not as important since I found an amazing app called Bluetooth Terminal/ Graphics. It not only logs data but also draws graphs live on my phone. Very useful to be able to see what's going on whilst riding the bike. On the topic of apps I've also found ArduinoDroid - Arduino IDE to be very useful for making quick modifications to the code, can't really believe it works on a smartphone. As my phone has reverse charging capability it can easily power the Arduino as well.



At the moment I have a simple I2C communication going between the two Arduino's. The additional Arduino is currently only measuring cadence and sending the value to the master when requested. An offset is calculated from the difference between the desired cadence and the actual cadence. This is then feed into the main equation.
Here's the first data I recorded with and without cadence correction. I did the same 7 mile length of road first section hilly the rest flat. Feels amazingly accurate when riding, a few rpms difference is undetectable. Makes a big difference not having a drop in cadence as the bike slows on a hill.




I forgot I was still in the small chainring for the first couple of miles which is why cadence goes so high.


The resulting frequency graph appears to be 1rpm out, need to update the value in the servo position equation.

Whilst this simple offset proportional to difference in cadence works well under the right conditions it all goes wrong if there is to big a change in cadence. An oscillation is setup during acceleration or when I start pedaling again. Will be a nice little challenge to work out how to dampen this whilst not reducing the responsiveness. The other option is to write some code to disable the cadence correction until a period after I start pedaling.

[Oran]

Having now got a way of maintaining cadence with good accuracy I've been thinking more about the user interface. I've now made the potentiometer more usable by dividing up the 1024, in my case into 7, so that each cadence setting has an assigned range of values. The only problem with this is that sometimes the potentiometers position falls between two cadence settings and it shifts rapidly between them. Attaching an indexed shifter would fix this.

Two buttons for shifting up and down is another option. Two buttons have the advantage of being simpler and any number of different cadences can be programmed. Disadvantage is not being as easy to use with vibration from poor roads or from different positions on the bars.

I've had success making the cadence correction more usable mostly by deactivating it at times when it gets into an oscillation. First I set the offset to 0 when my cadence is below 12rpm of the set cadence. Before the offset would go to -300 when I stopped pedaling as it was trying to bring the cadence up. This resulted in a too low a ratio when I started pedaling again and helped an oscillation to begin.

Next I programmed the unused handlebar switch as an on on off switch for the cadence correction. I found this useful and made me think about when it needed to be deactivated. What I've now programmed is a simple timer so that I have to pedal at more than 45rpm for 7 seconds before cadence correction will start. This works really well, if I stop pedaling it's deactivated and the timer is reset. It's still not perfect, if I'm not applying much torque to the pedals it can still setup an oscillation. It only really happens if im at too high a cadence, not much of a problem for me. I'll experiment with how the offset is calculated and see what averaging can do.

I've analysed some data and plotted these graphs that have been helpful for checking the values I've calculated for each cadence. The offset graph is even better at showing up the errors. 68rpm is perfect as the offset is centered around 0 the others are off by various amounts.


I haven't forgotten the touch screen idea and want to experiment with one in the future but waterproofing and power consumption is an issue. I'm finding that the Bluetooth connection to my smartphone is working nicely at the moment.

[Normand_Nadon]

For the in between potentiometer issue, try adding a dynamic deadband in your scale.... Or different switch up vs switch down values

[Oran]

For the in between potentiometer issue, try adding a dynamic deadband in your scale.... Or different switch up vs switch down values

That’s just what it needed a quick search found this code which works well. I like how the deadband can be changed easily.

int deadband = 10;
if (0 == valPrev)
{deadband = 0;
}
if((877 + deadband) < val)
{

}

else if (((731+deadband)<val) &&(val<=(877-deadband)))
{

}
Repeated 4 times with different values and then.

else if (val<(147-deadband))
{

}
valPrev = val;

I’ve also been experimenting with the multiplier that calculates the offset for cadence correction. Increasing it makes it very unstable and reducing makes the cadence less accurate. No improvements to be made there, it might just be the occasional oscillation might be the price to pay for accuracy. I will experiment with averaging next but if it adds a delay I won’t use it.



Sent from my BV5000 using Tapatalk