XEBEX V2 Air Rower Support

[namirda]

I have recently purchased a Xebex V2.0 air rower (https://www.getrxd.com/xebex-air-rower-2-0.html) and am generally pleased with it. It is a clone of the Concept C2 yet in New Zealand sells for about half the price. Unfortunately it does not have any inbuilt connectivity and so I thought I would try ORM.

I believe the rower has 6 magnets on the flywheel and the sensor gives a rather clean signal as shown in the yellow trace below. The P-P amplitude is about 8 volts when rowing hard.

I feed this signal through an optoisolator before it reaches my pi3B+ and the signal input to the pi can be seen in the blue trace above.

Both traces look rather clean and much as I expected – the yellow one being symmetric about zero and the blue one showing HIGH when the yellow is LOW and being pulled down when the yellow goes above a certain value.

ORM seems to be running OK (v1beta_updates). It detects this incoming data stream and shows (incorrect!) values for all parameters using the DEFAULT rowerProfile.

Raw data after a few strokes of very leisurely rowing looks like this :

You can see the typical shapes of the drive and recovery phases for about 12 strokes but there is something else going on. Zooming in gives these pictures :

In addition to the low frequency signal from the phases of the rower, there is also a higher frequency modulation due to the rotation of the flywheel. You can see the 6 data points per revolution of the flywheel from the 6 magnets but it looks as if they are not regularly spaced around the flywheel – three appear to be more closely spaced and then the next three are more widely spaced. Having read this discussion, I see that another possibility is that the polarity is not the same for all magnets.

Needless to say, ORM cannot handle data looking as wild as this. I have tried playing with the median filter and various flank lengths but the stroke detection is not working at all. I clearly need to do something with this input data to give ORM any chance.

Any suggestions? I’m reluctant to modify the rower at this stage because it is still under warranty.

One possibility would be to only process data from a single magnet per revolution of the flywheel and ignore the other 5. I have editted the raw csv file by hand which produces the curve shown below :

This reduced dataset looks nice and clean and I guess that ORM would handle it easily – although it is a bit wasteful of data!

Would it be possible to add a rowerParam to only select every nth data point for processing?

Thanks for any other insights or suggestions.

[Abasz]

Also, I had similar issues a while back, for me changing the input detection direction cleaned things up:
gpioTriggeredFlank: 'Up'

Have you tried changing the above to Down? Also if this machine has a reed instead of a hall you could experiment with increasing the gpioMinimumPulseLength: 50 so only longer impulses get detected.

I think sensor of the machine picks up noise (either bounce or something else). The fact that reducing the detected impulses cleans things up suggest this.

Would it be possible to add a rowerParam to only select every nth data point for processing?

This is possible to achive: you can increase the minimumTimeBetweenImpulses: 0.014, to a value that would cover at least two or more impulses.

[namirda]

Thanks for the response.

I have just tried setting gpioTriggeredFlank to "Down" but it made no visible difference. Why did you think it might?

As you can see from the pictures above, the data is very clean - almost no noise. The output pulses from the optoisolator are also very well behaved. The higher frequency modulation we can see in my pictures 2 and 3 above is either due to the position or perhaps the polarity of the magnets on the flywheel. This does not look like a random manufacturing issue - there is definitely a pattern to it.

I don't think minimumTimeBetweenImpulses can really help me here. It would have to be set very carefully to match a chosen cadence - if my strokes/min were to change much then the stroke detection would fail.

At the moment I cannot think of a better solution than to try to reduce the dataset to a single point per revolution of the flywheel. My javascript is not the best but I will dig a bit into the code and see what I can come up with.

[Abasz]

I have just tried setting gpioTriggeredFlank to "Down" but it made no visible difference. Why did you think it might?

I tested a concept 2 a while back with an esp8862 with mosfet logic level shifter and it produced exactley this kind of data and when I changed the edge detection it suddenly got very clean. this was my original data:

I still dont know why that happend. Originaly I assumed that I do not reach the guaranteed high detection threshold but that would mean that I have missing points. Any way.

As you can see from the pictures above, the data is very clean - almost no noise. The output pulses from the optoisolator are also very well behaved. The higher frequency modulation we can see in my pictures 2 and 3 above is either due to the position or perhaps the polarity of the magnets on the flywheel. This does not look like a random manufacturing issue - there is definitely a pattern to it.

Yes and that is strange. Magnet position is possible but these seems to me too big variation. This is magnet placement:

Notice that the difference is less than a millisecond for these these little teeth basically. In your chart the difference is like 3-4 milliseconds. That is an eternity :) Also if this is placement the size of these teeth should increase as the flywheel slows down as the effect of the misplacement gets bigger. Not to mention that on the oscilloscope picture the length of the signals seems rather equal. I would expect the timing difference to manifest there too.

I would suspect that its more like bounce from the sensor. I dont think its the polarity. If you have an unipolar hall sensor then it wrong polarity will not do anything to it, it just simply does not do anything. If you have bipolar than orientation is irrelevant. IF you have latching than one polarity switches on and remains on utnil the other polarity does not came and turns off.

But I also agree that it is not bounce probably as the number of impulses correspond to the 6 magnet you refer to (also bounce looks different any way).

This is a very interesing matter.

You could try to change the internal pull up of the Rpi sensor to pull down Gpio.PUD_DOWN,:

openrowingmonitor/app/gpio/GpioTimerService.js

Line 43 in 2934fef

pullUpDown: Gpio.PUD_UP,

I am just guessing for now as I still believe that this is some electrical matter that gets generated at the Rpi so oscilloscope does not pick it up like the signal is not being pulled up/down properly.

[JaapvanEkris]

Raw data after a few strokes of very leisurely rowing looks like this :

You can see the typical shapes of the drive and recovery phases for about 12 strokes but there is something else going on. Zooming in gives these pictures :

This actually is a familiar problem with many machines, including the Concept 2 RowErg and Model D.

Needless to say, ORM cannot handle data looking as wild as this. I have tried playing with the median filter and various flank lengths but the stroke detection is not working at all. I clearly need to do something with this input data to give ORM any chance.

Step 1, disable the median filter. It does more harm than good, and I'm really considering removing it completely for that reason. It is there for legacy reasons, but its interaction with the rest of the subsequent parts of the engine isn't too good.

ORM is tested almost daily on a Concept 2 RowErg, which has the exact same issue. We use a math-heavy approach that should be able to ignore these errors. Can you test by seting the machine profile to a Concept 2 RowErg? The key here is using the noisy data and let the flanklength be twice the number of magnets (=12 in your case)?

[JaapvanEkris]

In this case, the amplitude of the higher frequency oscillations (about 3ms) is so large that there will NEVER be 12 consecutive increasing/decreasing values to trigger the phase change - in fact it looks as if there will never be more than 3! As @Abasz said above, 3ms is an eternity! Or am I misunderstanding how flankLength works?

That is not how FlankLength works :)

FlankLength essentially draws a moving trendline of "FlankLength" number of datapoints. A bit like a moving average or a moving median, but a bit smarter. So, it should be able to absorb a lot of noise. But, I admit errors of nearly 20% is a lot.

These oscillations are certainly annoying for ORM but they are probably not noise. I believe the placement of the magnets must be by design and not random error - it is all so regular. Somehow the xebex PM is able to make sense of this complex signal to give consistent, believable results. I wish I knew how it works!

The Concept 2 does the exact same. Looks like some analog signal processing based on the sine-wave (a bit like frequency modulation).

For now I have taken the simplest possible approach and made some small changes to ORM so that only every n pulses are processed. I add the currentDt values for 6 consecutive pulses and pass the total time to ORM for further processing. The reduced raw data then looks like this:

Doesn't this look like a workable dataset - it is certainly very clean? Having done this, I suppose I should then change the numOfImpulsesPerRevolution from 6 to 1? Are there likely to be other changes required in the rowerProfile?

This looks pretty good. numOfImpulsesPerRevolution would indeed go to 1. Please observe that you also have to adjust minimumDriveTime and minimumRecoveryTime. Typically it has knock-on effects on minimumStrokeQuality and FlywheelInertia etc.

[JaapvanEkris]

Additional comment, as I hit myself in the head for over an hour over it. There is a stray /* (i.e. comment out everything that follows) in the default config.js that is placed there during installation. If it is there, all settings are rejected (including rower profile, etc.). So you could try with removing that darn thing.....

[namirda]

I have managed to get reasonably good stroke detection using my reduced dataset but still using numOfImpulsesPerRevolution of 6 and a minumumForceBeforeStroke of 10. However, when I change impulses to 1 then I cannot get stroke detection to work at all. I have tried a large range of values for minimum force, sprocket size and one or two other parameters but no luck.

What matching changes would you expect in other parameters as the impulsesPerRev changes from 6 to 1 (ie Flywheel spinning 6 times faster) using the same raw dataset?

I feel I am missing some diagnostics somewhere. The input data is so clean that stroke detection should be trivial based only on the change in slope of the currentDt - so one or more of the other parameters must be preventing the stroke transition - but which one?

Perhaps if I understood the various inter-relationships between the parameters better then it would be obvious but until then some simple diagnostics would be useful. Something like "Slope changed but Force below that required for transition" I will try to see if something like that could be easily inserted.

[JaapvanEkris]

I have managed to get reasonably good stroke detection using my reduced dataset but still using numOfImpulsesPerRevolution of 6 and a minumumForceBeforeStroke of 10. However, when I change impulses to 1 then I cannot get stroke detection to work at all. I have tried a large range of values for minimum force, sprocket size and one or two other parameters but no luck.

That is because almost all underlying calculations are based on angular velocity and angular acceleration, and you just increased it by a factor 6.

What matching changes would you expect in other parameters as the impulsesPerRev changes from 6 to 1 (ie Flywheel spinning 6 times faster) using the same raw dataset?

That is a tough one. Decreasing the number of datapoints has knock-on effects: it changes the accuracy of the measurements being done. That is the key issue.

I feel I am missing some diagnostics somewhere. The input data is so clean that stroke detection should be trivial based only on the change in slope of the currentDt - so one or more of the other parameters must be preventing the stroke transition - but which one?

Look at Flywheel.IsPowered() and Flywheel.isUnpowered(). That is the most logical place to insert a logging line.

You are right that some additional logging might be helpful here. In future versions I might split those two up and have the Finite State Machine in Rower.js report what is holding it back. But this might have a big impact on performance (some calculations aren't that nice), so that would require a lot of testing for general release.

Perhaps if I understood the various inter-relationships between the parameters better then it would be obvious but until then some simple diagnostics would be useful. Something like "Slope changed but Force below that required for transition" I will try to see if something like that could be easily inserted.

Have you seen https://github.com/JaapvanEkris/openrowingmonitor/blob/v1beta_updates/docs/rower_settings.md and https://github.com/JaapvanEkris/openrowingmonitor/blob/v1beta_updates_package_updates/docs/physics_openrowingmonitor.md ?

[namirda]

Thanks - I'll get onto that tomorrow. It's getting late here...

[Abasz]

I am still struggling to accept the fact that magnets are misplaced by this amount. To have such a big difference, magnets should be off by a visually noticable amount. So I think its important to understand the wiring and electornics, placement and type of the sensor etc.

In order to do this I would try to just take the cover off the flywheel. That can be easily done it should not void the warranty (actually one should clean it after longer periods as well as lubricate the bearings in the clutch to extend the lifetime). I am hoping that the magnets will be visible from this side and that could.

Meanwhile I found a video of a rower like that which is dissembled: https://www.youtube.com/watch?app=desktop&v=sM75PbWTlg4 (good shot is at 2:37). It shows I think a potentiometer connected to the leaver of the air vent. Interesting choice for getting the drag factor :)

Then at 4:18 there seems to be a wire going to the shaft that is like the conventional place for a hall sensor (if its indeed a hall sensor as I cannot really see properly). If its a hall sensor than the only way it produces those piramid waives is by using a linear hall sensor (which is strange choice). The strange part is that I dont really see the magents when the guy rotates the flywheel, while from the otherside there are clearly 6 screws which I suppose are the magnets or palces for the magents).

But I was also checking the video on the website and I can see that there are two plugs (3 wire and 4) assuming that the 3 is the potentiometer on for the air vent, I dont really understand why they need 4 for the sensor (hall sensors have 3). Concept 2's PM essentially uses 3 (signal, charge, gnd). In my view, having this many wires indicates that something else is going on there.

Finally some testing: Can you test the impulses with fully closed air vent (i.e. little drag) and fully open (i.e. full drag)? I would like to see the impact on the impulse times. Not the absolute time but rather how this affects the measurements copared to each other. Also once done can you send the data in csv or what ever as well so I can do some calculations?

[namirda]

Hi Abasz

Thanks for taking such an interest in this - much appreciated.

I think the youtube video you found must be for an earlier model. My rower is a V2 which looks a bit different. For a start there is no potentiometer attached to the lever of the air vent. Here is a picture of the sensor:

The cable you can see has only 3 conductors which go to the PM. I cannot find any signal on one of the wires - the other 2 contain the waveforms I have posted previously. There are also an additional 3 conductors which go to the PM from somewhere under the seat of the rower - I have assumed this to be the pickup for the optional heartbeat sensor which I do not have. In any case, the PM works without those 3 wires being connected. You can see the wiring here :

The wire you can see going downward connects to the rpi and is simply a T cable I made up to enable me to use the xebex PM and ORM at the same time.

I have removed the flywheel cover in the past but did not take any photos. Sadly there is nothing to see - I believe you would need to remove the flywheel to access the magnets and I don't want to do that just now.

Here are the two raw data files you requested each containing data for about 20 strokes, one using air vent position 1 and the other using position 10

Drag1_raw.csv.gz

Drag10_raw.csv.gz

[Abasz]

I've checked the data and now I am even more convinced that this cannot be magnet placement.

Basically the most notable effect of magnet placement that at higher drag and slower speed the errors should increase as the magnet takes more time to complete the path in between. Practically this should mean that when you select to approximately equal deltaTimes and check then ext once one should be slowing down proportionately quicker then the other for all points. Of course there are measurement errors, but if you choose a slow speed where there is enough time the effect of the measurement error can be neglected.

Now I was trying to find the pattern of these deviations at different speeds as those should be consistent if the magnets are palced differently, but rather I noticed that the pattern changes based on speed (which a sign of bounce/noise rather than magment palcement).

Please have a look at the below set. you can see that the pattern is at higher speed is 3 minus and then 3 plus. Then on slower this changes.

deltaTime	deltaTime Diff		deltaTime	deltaTimeDiff
32440	-2501		12550	-1065
28705	-3735		11365	-1185
28765	60,00000008		11200	-165,0000002
31400	2635		12200	1000
34535	3135		13460	1260
35395	860,0000001		13770	310,0000001
32865	-2530		12700	-1070
29055	-3810		11500	-1200
29145	90,00000023		11330	-170
31825	2680		12350	1020
34995	3170		13605	1255
35860	865,0000002		13930	325,0000002

I think it is important to understand how the sensor works/what kind of sensor it is. I am not even convinced that you really have 6 impulses per rotation. It is well possible that you have only 2 and the rest is noise.

So a still believe that something is strange. What I would try, is to ditch the optocoupler and try to bring the voltage down with a simple voltage devider. There should be no current here so theoretically it should be safe. Also if you have some parts a simple logic level shifter can work with a mosfet or an npn transistor. I used a BS170 for this purpose and worked very well. Something along the line (you can ditch the voltage devider on the gate I had it there as the BS170 is rated up to 16 or something volt and the C2 can theoretically produce 20+ volts so I wanted to be on the safe side, it should work with 8 np)

Also I think its worth playing with the input pull up / pull down as that is just one line change in the code.

[JaapvanEkris]

I have just tried setting gpioTriggeredFlank to "Down" but it made no visible difference. Why did you think it might?

Stupid question, what is the maximum frequency of your optocoupler? And can you have your scope report the time between peaks?

I agree with @Abasz that 30% deviation is a lot. I'm not suggesting you made errors here, but this level of noise is a lot, so it might be that we are missing something somewhere.

[namirda]

The optocoupler is the common PC817 combined with a 220 ohm current limiting resistor on the input. Max freq of the 817 is 80KHz according to the datasheet and so there should be no problem there.

The frequency of the input signal and the output pulses can be seen on the scope image I uploaded earlier - 59Hz in both cases.

[Abasz]

cannot find any signal on one of the wires - the other 2 contain the waveforms I have posted previously.

What does this mean? Hall has gnd, vcc and signal.

So basically you should see one with a stable voltage the other with the variable as signal and one should show gnd.

If this is not the case then the sensor is most likely not a hall so different treatment is necessary. Not to mention that with a hall they are generally open collector so the signal voltage is basically the pin voltage you connect them to (assuming pull up).

Where does the sensor gets its power? Is it from The pi? And the optocoupler ? Does it actually generate P-P 8v when you meadure without power source (C2 does as it has a power generator)

[namirda]

I took another look at the sensor this morning ....

With NOTHING other than the scope probes attached to any of the three wires (ie disconnected from the PM and rpi) I see the same 8VPP sawtooth signal between two of them and nothing on the third one. The resistance across the two wires containing the signal is about 120 ohms and the third wire is open circuit wrt the other two (resistance more than 100MOhm). This looks more like a simple pickup coil than anything else!

So this sensor has NO external power supply and yet produces enough voltage to directly power the optocoupler.

[Abasz]

I still think this is not magnet placement. The power generation requires precise placing (with a margin of error obviously) so I dont think this amount of volatility can come from that.

I am not familiar with this optoisolator chip, but I think the issue is electronic. In order to rule this out the electronics I would try a different circuit. When you measure with you oscilloscope the blue signal, is it connected to the Pie as well or just the scope?

[namirda]

The 817 opto chip chip is probably the the most common optoisolator chip out there. The same one is used in the Al-Zard DST-1R4P-P module shown in the concept c2 setup shown here

The probe is connected directly to gpio pin on the pi because I am using the internal pull up.

[Abasz]

Ok, so what could be done to understand the signals better is that you set the gpioTriggeredFlank: 'Both' so it gets triggered for rising and falling. Then add a log statement, logging rawCurrentTick within the sensor.on() callback function. This would give you timing data in us, allow you to see how long the high and low is detected. In case of having noise/bounce or other electric issue the high time should be inconsistent, meaning that one high is shorter than the other. You see magnets (as even these coils work with magnets) should be equal sized and should trigger high for an equal amount of time that is proportionate to the speed (i.e. at higher speeds high time is shorter than at lower speed but always proportionate to the low time). Now of course this would not actually make an progress in resolving the issue merely help understand the issue.

So to resolve the issue I see 3 options:

1. you either try to measure the points with a different device (e.g. purely with you oscilloscope) and somehow try to verify that what the Rpi sees, is seen by other devices,
2. you swap the opto to something else (voltage divider, logic level shifter etc.) for testing and see what data do these deliver. I suppose you can start with the voltage divider as that needs only 3 resistors and check the output voltages with scope so you do not damage the Pi accidentally.
3. you make a correction in code that it only use 1 pont in every 6.

I think point 3 is the quick and dirty and would be waste a lot of valuable data. But to achieve this I would add the implementation to the Gpio service with a simple counter that ignores incoming signals. This way you would need to set the number of impulses to 1 as the rowing engine would see one point per rotation.

  let i = 5;
  // Define the alert handler
  sensor.on('alert', (level, rawCurrentTick) => {
    if ((triggeredFlank === 'Both') || (triggeredFlank === 'Down' && level === 0) || (triggeredFlank === 'Up' && level === 1)) {
	
      if (i < 5){
	i++;
        return;
      }
      i=0;

Something along the line of the above should work. You initialize with i with 5 so you get the first impulse when you start the machine and then you ignore the next 5. Now of course this is not perfect because based on the data I see that the machine behaves differently at different speeds (produces different amount of point and noise) so for instance when you stop and restart it may have it self locked to a different set of points pattern. But the effect of this should probably be corrected by the engine.

[namirda]

Thanks for giving this so much thought....

The bottom line is that the sensor is self powered and gives a nice clean signal - albeit one which we do not completely understand. One day I will probably get around to removing the flywheel and reveal the mysteries hidden behind there!

I have no worries about the integrity of the opto output - it is exactly what I expect and hoped for given the input. I will work with that. I had already checked the ratio of the HIGH and LOW parts of the pulses as a function of speed (PWM power factor) and it is almost constant as I would expect.

I have already modified the code to reduce the number of input points. This results in a nice smooth currentDt curve (actually 6 of them!) and I now have reliable stroke detection. It might even be possible to combine the stroke detection from all 6 curves in some way to improve the stroke detection but it doesn't seem to be necessary because the data is so clean.

I still have not managed to get sensible metrics from ORM but I am getting closer. I have a pretty good idea of the metrics I expect ORM to produce and so it should be possible to tweek the parameters until I get there. I am currently making a number of ORM runs on the same reduced dataset to see how different drag factors, flywheel inertias etc effect the metrics - multivariant analysis is easier if you understand the different inter-relationships!

[JaapvanEkris]

I took another look at the sensor this morning ....

With NOTHING other than the scope probes attached to any of the three wires (ie disconnected from the PM and rpi) I see the same 8VPP sawtooth signal between two of them and nothing on the third one. The resistance across the two wires containing the signal is about 120 ohms and the third wire is open circuit wrt the other two (resistance more than 100MOhm). This looks more like a simple pickup coil than anything else!

That seems similar to the Concept 2 setup, where the coil powers the monitor. The first scope image with the optocoupler output overlayed on the sine wave doesn't show any signal bounce. But it is a weird signal.

[namirda]

@JaapvanEkris

After playing about a bit with the code and parameters, I have now managed to get very nice metrics using my sparse dataset (ie only processing 1 point in 6) - so very happy with that. The drag factor has a 'goodness of fit' of 1.000 (??) and changes from about 110 to 190 as I move the drag pointer on the rower. So all good - thank you for ORM.

However, it would probably be even better if I could utilise all the datapoints instead of throwing most of them away!!

I tried applying a 6 point runsum on the raw data using Excel and it nicely removes all the issues due to magnet placement (or whatever it is!) - it simply averages everything out over one revolution of the flywheel.

I then ran ORM again on this smoothed data using nmagnetsPerRev of 6 and got a very similar result to that obtained using the sparse dataset. Very similar drag factors and the same perfect goodness of fit.

I then tried to use ORM to do this pre-filtering - I made a small change to StreamFilter.js so that StreamFIlter.push() sets cleanDatapoint to the average instead of the median. I believe this should be the same as my external runsum.

Using this approach, everything works much as before except that now the dragfactor calculation returns a much lower 'Goodness of Fit' (about 0.3) where it was 1.000 when I used pre-smoothed input data.

I have spent quite a bit of time trying to find out the reason for this but so far have failed. I suspect it may be obvious to you why this is going wrong - if it is then I would be very grateful for a hint!

Thanks

[JaapvanEkris]

Using this approach, everything works much as before except that now the dragfactor calculation returns a much lower 'Goodness of Fit' (about 0.3) where it was 1.000 when I used pre-smoothed input data.

I have spent quite a bit of time trying to find out the reason for this but so far have failed. I suspect it may be obvious to you why this is going wrong - if it is then I would be very grateful for a hint!

This is because the drag calculation will always use dirty data, as it is designed to be robust against noise, and actually tends to act pretty bad when confronted with filtered data (a regression model handles real noise a lot better than artificially cleaned data). Given your specific situation, this might be different, but in essence that is the issue. The noise in the signal in the recovery results in a lot of deviations from the line it draws to calculate the drag. Essentially, the "Goodness of Fit" of the dragfactor is telling you that your datastream is noisy, which you already knew :).

Setting it to 0.30 for the acceptance of the dragfactor has no weird effects, so is quite acceptable (although some control freaks like me want that perfect 1.0, but in the end, who cares?).

You might need to look at how your stroke detection behaves, as it also uses goodness of fit based on the raw data, so requiring a slope fit of 0.34 (typicall install) might be a bit ambitious.

[namirda]

Absolutely! Thank you

I have now created a simple preFilter class which will optionally perform a running average of length numOfImpulsesPerRevolution on the input data and that solves the problem for me. Perfect 1.0

I believe that simple prefiltering like this should remove ALL artifacts which are due to magnet misplacement so long as the data is otherwise clean. It's probably not helpful if there is bounce or other spikes to contend with.

I am not sure if the result is any better than the earlier sparse approach but it feels better to actually use all the data!!