I have mini exercise bike. I try to find a way to log pedal RPM and position of Resistance Control Knob with time stamp. Knob turns about 5.5 x 360 degrees.

Bike looks like this and it shows also the knob:
http://miniexercisecycles.co.uk/

One option is to log to SD-card and another to Mac via TTL cable.

I don't have programming skills. :-(

Is this overkill for pedals $30?:
Rotary Encoder - 200 P/R Sparkfun COM-10790

How about these for Knob?:
Rotary Encoder 30 pulses with built in switch Bourns PEC11L-4220F-S0015
Rotary Encoder - Illuminated (RGB) SparkFun Rotary Encoder - Illuminated (RGB)
Photo Electric Counter
Motor Speed Sensor Module
Infrared Proximity Sensor 2-15cm - Sharp
QTR-1RC Reflectance Sensor Pololu 959
QTR-3RC Reflectance Sensor Array Pololu 2457
QTR-8RC Reflectance Sensor Array Pololu 961
QTR-L-1RC Reflectance Sensor (2-Pack) Pololu 2455
2-Channel Opto Distance Sensor
Adjustable Infrared Sensor Switch 3 - 80cm
VCNL4000 Proximity/Light sensor Adafruit 466
Wheel Encoder Sparkfun ROB-09208
2-Channel Optical Encoder / Velocity Measurement Kit

FTDI Friend + extras - v1.0 Adafruit 284
USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi Adafruit 954
DeadOn RTC
Cheapduino Mainboard DFRobot DFR0236
OpenLog

I'm clueless how to do this but i'm pretty sure some one has done similar project before.

Thanks in advance

 

One option is to log to SD-card and another to Mac via TTL cable.

I don't have programming skills. :-(
[Snip]
I'm clueless how to do this but i'm pretty sure some one has done similar project before.

Without programming skills, how are you gonna get anything on an SD-card?

If you're hoping to get anyone to help out, even a little bit, don't just describe what and where - provide hard links - you've been there, so it should be easy and we have no reason to search for stuff you've already found.

I think you're being overambitious with this projectgiven your lack of skills in this and when it comes to exercise (or mini exercise as is the case here), a full body mirror provides an excellent log, which even factor in snacks and in-between meals

Further, to be absolutely blunt, but not in any evil way, your post have all the trademarks that you may quickly become what's known as a "help vampire" http://www.skidmore.edu/~pdwyer/e/eoc/help_vampire.htm and such beasts we all fear. Hoping you'll prove me wrong though +- +- +-

 

Without programming skills, how are you gonna get anything on an SD-card?

If you're hoping to get anyone to help out, even a little bit, don't just describe what and where - provide hard links - you've been there, so it should be easy and we have no reason to search for stuff you've already found

Thanks for answer. I havent found much yet. I searched for sensors in one online shop and those sounded like usable in this project.

I found these two pages but i have no idea how to combine two different sketches and that second link reads only 1 sensor but my project needs two:
http://computers.tutsplus.com/tutor...-data-logger-to-an-arduino-project--cms-21713
http://www.circuitsathome.com/mcu/programming/reading-rotary-encoder-on-arduino

 

Even before you settle on a data acquisition system and method you need to select your sensors. I looked at the information on the MagneTrainer Mini Fitness Cycle. Where they mention "Adjust the pedal resistance with the knob on the front of the bike. The multi-turn knob provides precise, gradual control over pedal resistance".Many small machines like this I have seen the tension knob moves in and out, does it do that on this machine? Even knowing knob position won't tell you much. It won't for example define the force required to turn the pedals. I would look inside the machine for a convenient place to pickup the rotational speed, then select a sensor. Actually the machine has a display which shows speed, is that displayed as RPM? You may be able to use that signal.

As mentioned, lacking programming skills can make this challenging. However, there are small inexpensive data acquisition systems like this one which are used for data logging and really, for what you are looking to do, no actual programming is required. The link is merely an example.

Ron

 

Even before you settle on a data acquisition system and method you need to select your sensors. I looked at the information on the MagneTrainer Mini Fitness Cycle. Where they mention "Adjust the pedal resistance with the knob on the front of the bike. The multi-turn knob provides precise, gradual control over pedal resistance".Many small machines like this I have seen the tension knob moves in and out, does it do that on this machine? Even knowing knob position won't tell you much. It won't for example define the force required to turn the pedals. I would look inside the machine for a convenient place to pickup the rotational speed, then select a sensor. Actually the machine has a display which shows speed, is that displayed as RPM? You may be able to use that signal.

As mentioned, lacking programming skills can make this challenging. However, there are small inexpensive data acquisition systems like this one which are used for data logging and really, for what you are looking to do, no actual programming is required. The link is merely an example.

Ron

Thanks.

I'm really interested these small inexpensive data acquisition systems, but your link is missing.

Knob moves out. If i know position, i can calculate accurately enough how big resistance is.

>You may be able to use that signal

How i could do this? I have always wanted to log numbers in various electronics displays.

 

Oh once again I forgot the link. Here is a link to a basic data acquisition starter kit. The link happens to be DATAQ and I know they distribute globally but there are others. Devices like this include the basic software and are very easy to setup.

Since the tension knob does move in and out you could possibly use a type of LVDT as a sensor. LVDT is Linear Voltage Displacement Transducer. A simple resistive type is all you need to measure the In/Out travel of the knob. You do not need an inductive or expensive version. All you need is a simple resistive LVDT with likely maybe 1.0" of travel. I am in the US so I relate to inches. Possibly to keep it inexpensive something from China maybe.

I noticed the display included speed so I figure there is some sort of speed sensor in there, maybe you could use a signal from it and maybe not? I only mentioned it. The trick with measuring rotational speed is managing to get a rotational speed sensor mounted in there somewhere. Without seeing the internals it is hard to suggest a sensor. The data acquisition system I mentioned does allow for pulse inputs. If you read the data sheet and manual they tell you how to set it up.

Ron

 

Oh once again I forgot the link. Here is a link to a basic data acquisition starter kit. The link happens to be DATAQ and I know they distribute globally but there are others. Devices like this include the basic software and are very easy to setup.

Since the tension knob does move in and out you could possibly use a type of LVDT as a sensor. LVDT is Linear Voltage Displacement Transducer. A simple resistive type is all you need to measure the In/Out travel of the knob. You do not need an inductive or expensive version. All you need is a simple resistive LVDT with likely maybe 1.0" of travel. I am in the US so I relate to inches. Possibly to keep it inexpensive something from China maybe.

I noticed the display included speed so I figure there is some sort of speed sensor in there, maybe you could use a signal from it and maybe not? I only mentioned it. The trick with measuring rotational speed is managing to get a rotational speed sensor mounted in there somewhere. Without seeing the internals it is hard to suggest a sensor. The data acquisition system I mentioned does allow for pulse inputs. If you read the data sheet and manual they tell you how to set it up.

Thanks again. I think i need to find out how to just add another sensor to this tutorial. It has RTC and SD-card and 1 sensor already. It has really good detailed instructions. Attaching sensor to right places outside of machine is not problem, but i'm not sure what type of sensors are best. Maybe rotary encoder to knob and infrared proximity sensor to pedal.

http://computers.tutsplus.com/tutor...-data-logger-to-an-arduino-project--cms-21713

 

Using an Arduino is an option which will work fine with a few small additions like the RTC (Real Time Clock) for the date time group stamp and the addition of the SD card for memory. There are literally hundreds if not thousands of code samples out there to build on for acquiring data and writing the data to a SD (memory) card to be read later. You could also even add a display to the Arduino to see what you were data logging in real time as you record your data. It's just a matter of deciding how you get the data (Sensor(s) and how you interface your sensors to the Arduino.
Placing a rotary encoder on the knob shaft you can count the knob rotations. Something to consider if you go this route is if the knob is being turned in or out. This is where a quadrature type position encoder like this one can be used. Using quadrature allows you to know if the knob count is incrementing Up or Down (In or Out). Again, as I mentioned earlier, without actually seeing one of these machines opened up it is hard to say how to mechanically interface or mount the sensors or which sensors to use.

Ron

 

Using an Arduino is an option which will work fine with a few small additions like the RTC (Real Time Clock) for the date time group stamp and the addition of the SD card for memory. There are literally hundreds if not thousands of code samples out there to build on for acquiring data and writing the data to a SD (memory) card to be read later. You could also even add a display to the Arduino to see what you were data logging in real time as you record your data. It's just a matter of deciding how you get the data (Sensor(s) and how you interface your sensors to the Arduino.
Placing a rotary encoder on the knob shaft you can count the knob rotations. Something to consider if you go this route is if the knob is being turned in or out. This is where a quadrature type position encoder like this one can be used. Using quadrature allows you to know if the knob count is incrementing Up or Down (In or Out). Again, as I mentioned earlier, without actually seeing one of these machines opened up it is hard to say how to mechanically interface or mount the sensors or which sensors to use.

Thanks. Tutsplus link has RTC and SD card, it only lacks support for 2nd sensor. I have now bunch of sensors which probably work in this project. I just don't know how to add support for that 2nd sensor to Tutsplus sketch.

 

I found this from net. It sends data to computer:

void setup() {
  Serial.begin(9600);
}

void loop() {
  int myvalue = analogRead(A0);
  Serial.println(myvalue);
  delay(50);
}

Can i just do this:

void setup() {
  Serial.begin(9600);
}

void loop() {
  int myvalue1 = analogRead(A0);
  Serial.println(myvalue1);
  int myvalue2 = analogRead(A1);
  Serial.println(myvalue2);
  delay(50);
}

Moderators note : Please use code tags for pieces of code

 

It's not quite that simple.

Here is an example of your code as applied to an Arduino Mega uC:



Here is what your code will look like when monitored:



You are looking at two analog channels over and over again in a loop with a small .050 sec delay. You don't even know which channel is which. In this case I grounded both channel inputs so they read zero. You need to understand how an input channel works and how to convert the data to usable engineering terms like Volts, Amps, PSI, RPM, and other engineering units. Starting with the analog input channels, each analog input on the Arduino I am using is setup for a 0 to 5 volt input. Each channel uses a 10 bit conversion (2^10 = 1023 bits) so based on an input between 0 and 5 volts the A/D conversion will return between 0 and 1023. That value needs to be converted to an engineering unit value doing the math within your code. This is why I say there is much more to doing this. Additionally, we are only looking at an Analog In Channel at this point and not looking at counting pulses for example for a tachometer speed.

If you plan to use an Arduino I suggest you buy an Arduino of your choice and start experimenting with it from the very beginning basics.

Ron

 

It's not quite that simple.

>You don't even know which channel is which

Maybe code below fixes it.

> counting pulses for example for a tachometer speed

That seems to be kinkier.

void setup() {
Serial.begin(9600);
int pedal = 0;
int knob = 0;
}

void loop() {
int pedal = analogRead(A0);
Serial.print("Pedal=");
Serial.println(pedal++);
int knob = analogRead(A1);
Serial.print("Knob=");
Serial.println(knob++);
delay(50);
}

>how to convert the data to usable engineering terms like Volts, Amps, PSI, RPM, and other engineering units

When i have data logged to computer, i can use script i have to do the conversion.

Moderators note : Please use code tags for pieces of code

 

Well I do believe...

With a few minor changes to your code we get this:



Which looks like this:



Later today I'll do a little more with this and try to give you a few ideas. I will also tray and explain a few details later. While I have this Arduino Mega sitting here I have not done much with it. My Arduino stuff was given to me.

Ron

 

Here is something you can think about doing. Below is a rough version of some code and the results:

void setup() {
  // initialize serial communication at 9600 bits per second:
  Serial.begin(9600);
}

// the loop routine runs over and over again forever:
void loop() {
  // read the input on analog pin 0 and pin 1.:
  int sensorValue0 = analogRead(A0);
  int sensorValue1 = analogRead(A1);
  // Convert the analog reading (which goes from 0 - 1023)
  // to an enengineering unit (0 - Something):
  float RPM = sensorValue0 * (500.0 / 1023.0) - 9.00;
  float Torque = sensorValue1 * (100.0 / 1023.0) - 1.80;
  // print out the values you read:
  Serial.print("1. ");
  Serial.print("Rotational Speed = ");
  Serial.print(RPM);
  Serial.print("  RPM");
  Serial.println();
  // delay for about 1/2 second for stability
  delay(500);
  // Print the next set of values
  Serial.print("2. ");
  Serial.print("Torque Energy = ");
  Serial.print(Torque);
  Serial.print("  FtLb.");
  Serial.println();
  delay(500);
}

Setting this code up in Arduino looks like this:



Now if we view this using the Arduino Serial Monitor we see something that looks like this:



While I know you mentioned doing the conversion to Engineering Units later using some script. I find it easier to do in the initial code. In this case I assume two sensors, the first sensor is 0 to 500 RPM and outputs a 0 to 5 Volt signal, so 0 to 5 Volts = 0 to 500 RPM. The second sensor is 0 to 100 FtLb of torque outputs 0 to 5 Volts. You can see in the code sample how the engineering units were derived and later printed. During the example I used an input of 2.5 volts to analog inputs 0 and 1.

Consider that while novel a 10 bit analog to digital conversion is not exactly great. There will always be quantization errors. Leave room in your code to offset these errors.

float RPM = sensorValue0 * (500.0 / 1023.0)[COLOR=#0000ff][B] - 9.00[/B][/COLOR];
float Torque = sensorValue1 * (100.0 / 1023.0) [COLOR=#0000ff][B]- 1.80[/B][/COLOR];

float RPM = sensorValue0 * (500.0 / 1023.0) - 9.00;
float Torque = sensorValue1 * (100.0 / 1023.0) - 1.80;

Remember also that as I mentioned early on, programming is not my forte. If I would have had to rely on my programming skills during my career I would likely have starved to death. So now you have a little more to think about. Long as you have more channels maybe you would want a few body monitors? You could for example monitor your pulse rate and body temperature during exercise?

Ron

 

Long as you have more channels maybe you would want a few body monitors? You could for example monitor your pulse rate and body temperature during exercise?

Thanks a million!!

Now all that looks so simple that i can add more stuff to it now that i understand little bit of it. I didn't think i could add pulse rate etc but i think i will add these later.

 

Just a thought - if doing conversions in the main loop and using an incremental sensor (like the quadrature sensor), rather than an absolute sensor for the torque knob, I'll recommend to read it in an interrupt routine, as it might otherwise loose steps and so give you a wrong number.

The rev-counter might also be best in an interrupt routine.
Interrupt on one pin of the QD and read the other in the routine. If the other pin is high it's moved CW and CCW if it's low (or v.v.) - very fast to do and the only extra bit in that routine is incrementing or decrementing a (long) integer counter variable based on the direction.

Each time you read this variable to convert or whatever, it should be reset (with interrupts disabled for the shortest possible time.
A timer interrupt would be my choice in reading and converting the pulse counter variable into a velocity value.

What's with the analog inputs?
Are you gonna fit analog sensors?
RTC and rotational encoders are purely digital (and hence quicker to read).

 

Just a thought - if doing conversions in the main loop and using an incremental sensor (like the quadrature sensor), rather than an absolute sensor for the torque knob, I'll recommend to read it in an interrupt routine, as it might otherwise loose steps and so give you a wrong number.

The rev-counter might also be best in an interrupt routine.
Interrupt on one pin of the QD and read the other in the routine. If the other pin is high it's moved CW and CCW if it's low (or v.v.) - very fast to do and the only extra bit in that routine is incrementing or decrementing a (long) integer counter variable based on the direction.

Each time you read this variable to convert or whatever, it should be reset (with interrupts disabled for the shortest possible time.
A timer interrupt would be my choice in reading and converting the pulse counter variable into a velocity value.

What's with the analog inputs?
Are you gonna fit analog sensors?
RTC and rotational encoders are purely digital (and hence quicker to read).

Thanks for answer. I didn't know that digital sensors are faster and better. I'm okay with rotational encoders or what is best.

Your other tips about interrupt routines etc are way too advanced to me but these sounds cool.

 

Just a thought - if doing conversions in the main loop and using an incremental sensor (like the quadrature sensor), rather than an absolute sensor for the torque knob, I'll recommend to read it in an interrupt routine, as it might otherwise loose steps and so give you a wrong number.

The rev-counter might also be best in an interrupt routine.
Interrupt on one pin of the QD and read the other in the routine. If the other pin is high it's moved CW and CCW if it's low (or v.v.) - very fast to do and the only extra bit in that routine is incrementing or decrementing a (long) integer counter variable based on the direction.

Each time you read this variable to convert or whatever, it should be reset (with interrupts disabled for the shortest possible time.
A timer interrupt would be my choice in reading and converting the pulse counter variable into a velocity value.

What's with the analog inputs?
Are you gonna fit analog sensors?
RTC and rotational encoders are purely digital (and hence quicker to read).

Soren, many thanks for the suggestions because as I mentioned this stuff is far from my forte. Now I figure it this way and was going to get into the interrupt routines likely today. My take is nothing being read needs speed in readings. As to RPM I had given thought to using a HALL effect sensor. How much does the use of interrupts slow things down? For these applications I was thinking not enough to matter. So what is your take? I would love some input in this thread from somone familiar with the Arduino programming environment.

Thanks
Ron

 

Hi Ron,

My take is nothing being read needs speed in readings.

Seen as single events, you're right of course, but how to deal with an incident where a sensor pulse knocks the door, while the main loop is out for lunch with conversions and friends. I see no other way to handle this, with a minimum of errors, than by interrupts.

As to RPM I had given thought to using a HALL effect sensor. How much does the use of interrupts slow things down? For these applications I was thinking not enough to matter.

A unipolar Hall switch might do well, if it's possible to mount one or more magnets on the wheel (the magneto-resistive arrangement doesn't spin), but I think it would be easier to make contrasting stripes/patches along the edge of the main wheel and use two opto-reflex sensors - or a single one rather, whichever way it's spun gives exercise and only if Susannah want's to log front leg muscle exercise separate from back leg muscle ditto will the direction info be needed.

Not having seen the guts of this particular machine, I'd use opto for the tension knob as well, to be absolutely sure that the powerfull magnets won't interfere with sensor readings.

So what is your take? I would love some input in this thread from somone familiar with the Arduino programming environment.

My take? I'll gladly help out where I can, but risking an immense amount of flak, I'll have to admit that I see the Arduino as a toy controller board (akin to paint-by-numbers), where only a select few have made anything unique and 99.9% of users feed of the aforementioned. Just call me pedantic, but in my circles, a sketch is something involving pencil, paper and an idea and a shield is something protecting you from swords and other medieval weaponry - too much cuteness factor when we already have good and descriptive words like programs and extension modules.

Sorry, just my take on the Arduino and the rest of the world, calling anything something-duino, like there was nothing but Atmel controllers, which aren't too high on my list either, or I wouldn't have left them behind about 15 years ago. So, I've never even held an Arduino in my hand. Locally, a RasPi is much cheaper than an Arduino btw.
[/Rant]

Oh, there's a good side about it as well. Since lots of people builds little robots and for reasons I can't guess adds GPS modules and what not, prices has fallen tremendously, so don't tell them, that the precision of a GPS is way too low, to run a robot reliably in eg. a garden, where it may plane all the roses and leave the weed untouched

Besides language and register differences and so on, any solution will be the same on a higher level of abstraction though and while I'm not familiar with the Arduino pseudo-C (I'd do better on the assembly level), I think I'm capable of anything but the exact syntax.


For starters, it would be best to get an exact overview of which parameters are to be measured, like RPM, torque/tension, pulse rate and whatever.

Then, we can discuss what secondary data that can be drawn from those, like calories burned, a work harder or slow down indicator based on the peak pulse rate that is calculated from age, weight and general fitness minus some percentage IIRC (such can be found when we're there) and whatever else can be calculated from the data at hand, involving the RTC as well.

At that point we'll know if further sensors are needed and we can begin to sketch out a block diagram of the whole enchilada, while things like a reliable and non intrusive (read: non annoying) pulse sensor can be made (I'm biased towards an earlobe sensor, either wired or with a small transmitter for not feeling too wired into the machine.

When a fairly logical hardware block diagram is done, we can write pseudo code or draw up an old skool flow chart, but I absolutely hate Nassi Shneiderman diagrams like this

While there are software to draw one and then convert it automatically to C-code, they're ugly compared to the beauty of a flow chart, in my eyes at least

That way, we get the opportunity to actually give Susannah (and whoever will read this in the future) a fishing rod and show her how to use it, rather than just throw her a bunch of fish.


I wasn't able to dig out much on the machine, but the magnets prey on a small wheel (probably copper or aluminum for high eddy currents), which is connected to the main wheel by a belt.

They claim it's patented and judging from a number of patents, that are virtually the same thing in several disguises, a magnet brake on an exercise machine, it might be, but I haven't found it, however, I found 5 other similar patents and got bored looking any further.
On the flip side, I know of an eSpinner (for spinning yarn), where the site owner has put up a very official patent grant, not mentioning that the patent was revoked shortly after its grant (probably just trying to scare off the competition or embellish on his rather amateurish build product)

It's easy peasy to make a magnet brake anyway, a slab of copper and some neodymium magnets, with an arrangement to move the magnets relative to the copper and you're set.
If you haven't tried it already, try dropping a neo down a copper tube - quite an eye opener about eddy currents (it's like slow motion in real time).


So, what sensors are needed and what functions would be nice to have?
It would be good to get a single post summing them up in a concise form.

 

I didn't know that digital sensors are faster and better. I'm okay with rotational encoders or what is best.

With an analog sensor, you need to convert it to digital form in whatever bit width your A/D-C uses. When you can just read a single bit from a sensor that gives out a pulse.
For eg. RPM, you'll have a number of pulses for each revolution of the wheel (more pulses per rev means a higher update rate or a higher precision on instantaneous displayed values). There's no need to use AnalogRead to get those pulses and the result would always be the same (1023), so nothing gained, but time lost.

Your other tips about interrupt routines etc are way too advanced to me but these sounds cool.

Interrupts are not harder than any other programming. Just imagine that you have your programs main loop running and when a sensor signals an interrupt, the controller "puts in a bookmark" where it was, takes off to handle the interrupt and then returns to continue where it left off.
I'm not sure if it's the breaking up of linearity, that makes some think that it's harder than any other programming, but as soon as you get the hang of it, you'll find that it's sometimes easier than straight linear programming, as you don't have to worry about getting to a certain point of your code in time, like when using polled reading, which can include a lot of waiting for eg. a sensor to click.
Anyway, I'm sure there exists lots of libraries on the subject, so, to quote George... You gotta have faith