I'll start with something with multiple hardware serial interfaces since you have GPS and Bluetooth peripherals planned. Unless you have objection to the form-factor, the Arduino Mega 2560 is a good candidate.
Good evening vlawton74,
don't worry about the choice of the arduino model, they are quite compatible with each other, and if you start with a simple model, it will not be very difficult to change for a more complete version.
Up to 1MHz signal rate apparently on that encoder, although I doubt you'll see that on a motorcycle suspension. You may want something a bit faster than a Mega if you expect anything really high speed though. Consider the Teensy range but be aware that the fastest ones are 3V3.
wildbill, he may need a fast model for the acquisition of quadrature signals, but as lawton74 says he is a beginner with the arduino, I advise him to test his functions one by one on a simple model like the Uno, it will be easier; under interruption, he will be able to go up far enough in frequency for his linear encoder. The transition to a future teensy will be easier.
Thanks for you help people.
So just to give you an insight on the project.
I have raced motocross since i was 13 (38 now) over the many years racing so many time i have heard people complaining about there suspension. 6 years ago i made a suspension diagnostic using the air pressure in the forks. Turned the pressure with a voltage encoder and mapped out the travel to pressure. It worked using a data logger working at 400 readings a second.
The only problem was in modern day suspension there is a high compression valve which give me a false reading.
No i want to have a permanent feature on the bike so if you ever go to the track and the bike doesn't feel quite right you can see what the forks are doing and adjust to the track conditions.
The only real way is a linear encoder so we know exactly what the fork is doing, the encoder is the hard part as i dont want false reading if the arduino isnt quick enough to keep up with the encoder. You cant get an absolute encoder 400mm long.
The specs i am looking at are:
400mm travel on average bike
Landing hard off a jump the forks travel at around 10 meters a second
Magnetic encoder as optical could get dirt on it
10 m/s of fork movement, indeed it is the high limit of the encoder. I had to realize the reading of an optical rotary encoder with a rather high frequency, I don't have any more the values in head, but that passed with old processors not very fast compared to those of today. Don't worry, it will be possible one way or another!
Well, if your forks are moving that quickly, you'll be getting about 900KHz signals from the encoder, so you will indeed require something fast.
PatMax has a point though, your project is likely to evolve as you discover what works and what doesn't. And as you destroy hardware. Maybe start with a genuine Nano and several clones while you're finding out what you really need.
Brilliant thanks.
I have a few friends that have programmed a few Arduino's (simple things) so im not totally in the dark.
I had a look on RS components and there is quite a few so thought i best ask before i ordered the wrong one.
My other option is a potentiometer but it will be a little harder to fix onto the bike and are more a testing equipment than a permanent fixture.
You might investigate linear encoders used on milling machines. There are add-on devices for the machine table for both the X direction and the Y direction.
Paul
What kind of resolution are you after? According to the specs, if you want to go up to 11 m/sec, the max resolution is 2.3 um but at 1200 kHz. If you can tolerate 75 um resolution, the frequency goes down by 32x
So if the fork encoder would be putting out 900khz would i need the clock speed of the Arduino to be faster than this so it wouldn't miss a increment?
As i cant get an absolute 400mm encoder they told me this one would be ok as it has a index and can be reset after every stroke to stop and false measurements.
Reading encoder signals you will need something that can execute several hundred CPU instructions between each pulse so the clock speed will need to be many times faster than the pulses being read.
Don't forget that if you want to know which way the suspension is going, you will have to read A and B which will cost you more time.
That encoder document mentions resolution in nM though, so if millimeter is enough, maybe that's not the equipment you really need. Something with lower resolution will be readable by a much less powerful controller.
Do note though that you can get a super fast processor for Teensy (hint) money.
Pat the problem i have is no one makes a 0.5 or 1mm increment encoder.
Im not after finding the fine tune on the suspension its purely to see what the suspension is doing.
