Measured data representation

[ceties]

Hello, I'm trying to decode data recieved over RS232 from Monark Ergometr. There is no datasheet on the web and the company hasn't replied to my plea since now. They force people to use their software. So I'm trying and a I'm alredy quite desperate. I know that each packet has exactly eight bytes. I know that it sends RPM and if the weight is loaded or not, maybe something else, maybe some header but not likely. I thought that first four values could be "if the weigh is loaded" and the remaining four could be the RPM. I was trying to represent the data in all ways. Double, integers I was playing with endian form. No success at all to obtain meaningful information. I just want to ask, if you have some idea how the data could be stored. The RP progress should look like on attached picture. And the information about the image will be probably just change of one bit. Thanks to all

Message Edited by ceties on 11-26-2007 02:04 PM

[Kenny_K]

Do you have a copy of their software so that you can see what the actual RPM and weight loading is??  what you could then do is correlate the data from the RS232 to that which is being displayed by the software.  You could load the weight and then unload it, to see what changes in the transmitted data.

I am surprised though that they have not responded to you, most companies do not have a problem letting you write your own software, unless they are charging extra for the software.

[ceties]

Hey Kenny,

I did exactly what you suggest but with no effect. I'm also surprised that they didn't reply.

Here is the link to the bike if anybody is interested.

[ceties]

Hello I came back to this project after a while. I got some information from Monark but It still remains cryptic to me. Could somebody help me out? I would like to count the rpm from the received data. From the answer I do not understand if the interruption time is included in the sent data or if I just simply have to scan the port fast enough and just read the time when the interruption arrives and from that to compute the rpm.

The reply from Monark:

The data coming from the bike into the PC over the RS232 connection is just a timer interupt. This is comming for each full rotation of the flywheel and one when the basket is falling down (start). Everything else is calculations in the PC software.

-----

And here are some data. The row begining with 80h represents the interruption from the wheel sensor and C0h is when the basket with the weight is triggered.

80 03 01 03 0D 07 0A 06

80 03 01 07 03 07 02 04

C0 03 01 08 0C 0C 09 05

80 03 01 0B 0A 06 0A 04

80 03 01 0D 0F 05 08 01

So this represents two revolutions of the wheel then basket trigger and then another two revolution. When I measured I revolved with the wheel slowly (cca 0.3Hz)

Any help would be appreciated.

[Kenny_K]

It appears the monarch website is down, so I cant look at the bike again to remember what it looks like.  I am not sure what the basket is for.

You can probably search the serial data string for 80, and then mark it with a timestamp.  And then when you get another 80, you can measure the difference in time.  So you have had one revolution over X seconds, and then calculate the RPM from that.

Message Edited by Kenny K on 01-29-2009 07:14 AM

[ceties]

Yeah Kenny that is exactly what I intend to do if I do not figure out what the data could mean else. Here is the bike info but it doesn't help to decode the data at all.

[MartonLitkei]

Hey, may I join the codebreaking quest?

I transformed a bit the data you gathered:

\80\03\01\03\r\n

\07\n\n\
06\80\03\01\07\03\07\02\04\C0\03\01\b\f\f\t\05\80\03\01\0B\n\n

\06\n\n
\04\80\03\01\r\n

\0F\05\b\01

I think it makes some sense, could you provide some more data you recorded?

Regards,

Marton

NI Hungary

[ceties]

I measured those data more then year ago. They should contain the sequence of padling on the bike (80h interruption from the flywheel - 8bytes), the basket is triggered then (C0h interruption, 8bytes) and the wheel slows down(80h, 8 bytes). Thanks Marton for your time. If you find something I will buy you (virtual) beer. Otherwise I will try the constant reading of the port and measuring the time between the "pulses".

Message Edited by ceties on 02-04-2009 09:28 AM

[MartonLitkei]

Thanks for the VIs!
I guess the bits in the byte somehow represent parellel channels.

If you have a look at the attached VI you can see that a few channels make sense. The last three ones are mystery for me (anyway they are simmetric somehow. Might be an ECG signal without the 13Hz filter)

Regards,

Marton