PM5 obsolete?

[JaapvanE]

As an expert in corporate strategy and management, I have yet to see a company whose downfall hasn't started with a "what we have is good enough" attitude. I would hate to see Concept 2's long history of continuous improvement, among other things, reflected in the PM development break.

I agree there is no room for complacency, but one should also be extremely carefull not to kill the biggest moneymaker.

As I see it, home users aren't the key buyers. Gyms and boathouses are, as they buy fleets at a time. And the PM5 and RowErg are extremely well tuned to that user group. Essentially, these people use it as a part of their training, and they just hop on the nearest machine they see.

For that group C2 certainly has room for improvement, especially when it comes to competitive athletes. It isn't on the PM5 side, but on the logbook side. I see a lot of monitors and their data, and to be honest: C2's logbook is bleak in comparisson with RP3, and extremely disappointing when comparing to RowsAndAll. The PM5 generates a lot of usefull data, ErgData recieves it, but nobody is recording. I have ORM automatically upload to RowsAndAll, providing a lot of data for analysis. I can compare my forcecurve on a given pace with any other forcecurve in the last two years. That is usefull information. I can see strokelength and drive length shortening up on the HM. C2's logbook doesn't record that data. That stuff is insightful, but is lacking in the C2 universe unless you buy additional apps.

I think the PM5 certainly needs a refresh, but it is in details. The USB port is on the back, which isn't intuitive if you use it to record user data. Put it front and center. Make sure it can use current USB drives, not just the ones from a decade ago. Perhaps make it more user aware, especially when the ErgData app is connected. For example, put a specific screen configuration on the PM5 based on the settings.

Some things are out of reach. The integration I mentioned with Garmin is tough. But extracting breathing data into a session is valuable. It could be as simple as requesting the latest rowing session and extracting the data from the FIT-file. This can't be done on the PM5 side, but it can be done on the logbook side.

[stevegaspars]

I have yet to see a company whose downfall hasn't started with a "what we have is good enough" attitude.

LEGO perhaps? The attempt years ago to evolve their core product nearly killed the company.

I don't think C2 are resting on their laurels. They surely must be weighing up arguments like this all the time. Their reputation for consistency, reliability and serviceability is what makes them special, and the market leader. Not the fancy whistles we come to expect from modern smart devices that last a fraction of the time.

[HornetMaX]

Personally I tend to agree that the PM5 feels & looks outdated and underpar with the rest of the hardware you get (which is stellar).

I do get the needs of primary customers (clubs & gyms), the pros of no plug needed, the fact that many users favor simplicity and just don't care about anything else. And yes, it gets the job done. But that's all.

Just rambling, but wouldn't it be possible to get the rower with the PM5 or with just the "minimal" hardware to run stuff on your own device (smarthphone/tablet) ? I guess that was Carl's suggestion: handle the high-frequency/low-latency stuff in minimal dedicated hardware, leave everything else up to a separate device (that people anyway already have at hand).

BTW, the device could connect via a good old short cable to the rower: I'd take that over any wireless connection if it lowers cost, power needs and especially connection issues. With modern phones/tables, maybe the phone could even provide power to the onboard device, if needed.

P.S.
I don't think so, but there's a tiny chance my opinion is unintentionally biased by the fat that the PM5 on my rowerg is experiencing troubles (you switch it off and it keeps switching back on, no end, until you pull the batteries out and keep them out for 1 few hours). It's out of warranty (just barely, when the problem started), so only option is replacement (230E in FR) or bear the hassle of pulling the battery basically after very session and hope this lasts until a PM6 is out: at least I'd could write the money down as an upgrade

[Sakly]

Just rambling, but wouldn't it be possible to get the rower with the PM5 or with just the "minimal" hardware to run stuff on your own device (smarthphone/tablet) ?

This would make the usage depending on the device, which can vary from very basic to high end performance hardware, you would have to deal with and test compatibility. The user could be forced to update his device only to use the rower.
A full featured and independently running PM5 enables every user and every environment to be used. That's the big advantage, no issue.

BTW, the device could connect via a good old short cable to the rower: I'd take that over any wireless connection if it lowers cost, power needs and especially connection issues.

The PM5 is capable of a cable connection. Old ergdata app was able to be used with an OTG adapter and USB cable, this was my go to. The new Ergata app does not support it any longer.

[JaapvanE]

Just rambling, but wouldn't it be possible to get the rower with the PM5 or with just the "minimal" hardware to run stuff on your own device (smarthphone/tablet) ? I guess that was Carl's suggestion: handle the high-frequency/low-latency stuff in minimal dedicated hardware, leave everything else up to a separate device (that people anyway already have at hand).

In essence, that is what the PM5 currently is. For high-frequency signal processing on the machine side, you need quite some CPU power. And for a user-acceptable connection scenario, you need some kind of screen to inform the user what is going on. Dsplaying the calculated metrics, as it currently does, is in essence a free bonus as the display is already there and the metrics can only be calculated on the high frequency part anyway.

With the new ErgData (or ErgZone or similar) you essentially in that setup already.

BTW, the device could connect via a good old short cable to the rower: I'd take that over any wireless connection if it lowers cost, power needs and especially connection issues. With modern phones/tables, maybe the phone could even provide power to the onboard device, if needed.

I know RP3 works with a cable, and admittingly, now that the EU forces everybody to standardize to USB-C, that might be a possibility. On the other hand, you don't want to force people to take their phone/tablet to row a few meters in a warmup for a training. And wired connections, especially to consumer products, are typically where the high wear and tear (abuse?) starts. I don't knw how well the RP3's do, but they are typically in the boathouses of national teams, where I think people are a bit more controlled than in the clubs.

I don't think so, but there's a tiny chance my opinion is unintentionally biased by the fat that the PM5 on my rowerg is experiencing troubles (you switch it off and it keeps switching back on, no end, until you pull the batteries out and keep them out for 1 few hours). It's out of warranty (just barely, when the problem started), so only option is replacement (230E in FR) or bear the hassle of pulling the battery basically after very session and hope this lasts until a PM6 is out: at least I'd could write the money down as an upgrade

Contact C2. Even in Europe (NL), their service is on par with the US.

I wouldn't hold my breath for a new monitor on the horizon. The Bluetooth certification website suggests that a new PM5 version 6 is in development (see here), suggesting a "version 6" has made it past BT qualification. When I count correctly, the official version listing of firmware only recognizes 5 PM5 versions. However, it has this status for over a year now, and BT certification usually is the last thing on the checklist. When I look at the official FCC certifications, nothing new is in the pipeline there (see the FCC list). Issue is that C2 has a history of low-key silent hardware updates, so they could have changed the entire interior and capabilities without telling anyone.

[HornetMaX]

Just rambling, but wouldn't it be possible to get the rower with the PM5 or with just the "minimal" hardware to run stuff on your own device (smarthphone/tablet) ?

This would make the usage depending on the device, which can vary from very basic to high end performance hardware, you would have to deal with and test compatibility. The user could be forced to update his device only to use the rower.

I don't see the problem. There could be guidelines on minimum phone specs that would work.
You have a powerful enough phone ? Good, you can get the rower without the PM5 (maybe save some money too), install the c2 app on it and you're good to go. You don't have a powerful enough phone and/or you don't care about "bells & whistles" ? Just get the rower with the PM5.

I know RP3 works with a cable, and admittingly, now that the EU forces everybody to standardize to USB-C, that might be a possibility. On the other hand, you don't want to force people to take their phone/tablet to row a few meters in a warmup for a training. And wired connections, especially to consumer products, are typically where the high wear and tear (abuse?) starts.

Yeah but clubs & pros will likely just get the PM5 version or permanently fix dedicates devices on each rower ... they will not ask athletes to come with their own device. High wear: I don't see the problem. They can make the cable fixed to the erg as sturdy as possible (and still replaceable), the other end usb-c. If the smartphone port wears out, it's not the erg's problem.
That said, if wireless works, it's fine: I'm not sure there's any need/advantage in not having it.

BTW, I agree on logbook side improvements: some would be nice indeed.

Contact C2. Even in Europe (NL), their service is on par with the US.

Done, of course. Only options are full replacement or mail it to local dealer for diagnostic (which could lead to "too bad, you have to replace it" anyway, plus shipping). To be clear, I don't blame them: shit happens, warranties are limited.

I wouldn't hold my breath for a new monitor on the horizon.

I'm not. I'm holding my breath on my current one not degrading further: if it stays like it is at the moment (i.e. I have to take the batteries out after every session) I'll go with that. Annoying, but no big deal. At least the other PM5 (on the skierg) is working OK.

BTW, that makes me think it would make sense to be able to have 2/3 ergs but only one PM5 for all (again, that would be a home setup, doesn't make sense in a gym). Very niche scenario, I know, but it doesn't look technically challenging either ... just make it possible to quickly install the monitor without screws on the arm and easily change configuration between row/bike/ski (or even better, detect it automatically).

[Sakly]

Just rambling, but wouldn't it be possible to get the rower with the PM5 or with just the "minimal" hardware to run stuff on your own device (smarthphone/tablet) ?

This would make the usage depending on the device, which can vary from very basic to high end performance hardware, you would have to deal with and test compatibility. The user could be forced to update his device only to use the rower.

I don't see the problem. There could be guidelines on minimum phone specs that would work.
You have a powerful enough phone ? Good, you can get the rower without the PM5 (maybe save some money too), install the c2 app on it and you're good to go. You don't have a powerful enough phone and/or you don't care about "bells & whistles" ? Just get the rower with the PM5.

Ah, you meant two different setups, I thought you meant to replace the PM5 completely with no choice.
Sure, they could apply a small hardware part to read the sensor and pass the data to a USB port transferring it to an external device. If a phone is a proper device to calculate all the stuff the PM5 is doing - I don't know, but I doubt that. A phone has to do thousands of things in the background, at least some of them with high priority. I could imagine these tasks can influence the recognition of sensor data and it's calculation.
Stuff, which doesn't need real-time capabilities is no problem, as it can be buffered, but if your force curve is displayed, when you are doing your next stroke...wouldn't be helpful.
I assume there are many technical restrictions we are not aware of.

[stevegaspars]

The Bluetooth certification website suggests that a new PM5 version 6 is in development (see here), suggesting a "version 6" has made it past BT qualification.

The PM5 v6 is already in production and released. Look at the firmware filenames. PM5 v4 appears to have never made it to market, hence only 5 sets of firmware.

[JaapvanE]

The Bluetooth certification website suggests that a new PM5 version 6 is in development (see here), suggesting a "version 6" has made it past BT qualification.

The PM5 v6 is already in production and released. Look at the firmware filenames. PM5 v4 appears to have never made it to market, hence only 5 sets of firmware.

Thanks, that solves that mystery.

[dabatey]

I almost get the feeling that some would be happy if the PM5 were a 'black box' hidden away, and you then plop in your phone/tablet and connect ergdata via bluetooth, then everything is magically ok as the main screen is now a device lol.

[Sakly]

I almost get the feeling that some would be happy if the PM5 were a 'black box' hidden away, and you then plop in your phone/tablet and connect ergdata via bluetooth, then everything is magically ok as the main screen is now a device lol.

And they can easily get that - flip PM5 back and place the phone on a 3rd party phone holder - there you go

[HornetMaX]

I almost get the feeling that some would be happy if the PM5 were a 'black box' hidden away, and you then plop in your phone/tablet and connect ergdata via bluetooth, then everything is magically ok as the main screen is now a device lol.

For me it's more a case of "wouldn't it be better to do less on the PM5 and more on a user's device " ? (and yes, it's a question, answer may be "no, it's not"). The power you have on today's user devices is insane compared to not long ago so maybe it's worth revisiting the decision.

But what JaapvanE said (about the very specific hw you need to process the high-freq sensor data with low latency) may end the whole discussion.
Or the fact (already pointed out by others) that c2 focus may be less about home individual users and more about boathouses and gyms. But yeah, in that case, it's normal to have home users "complaining".

[Sakly]

But what JaapvanE said (about the very specific hw you need to process the high-freq sensor data with low latency) may end the whole discussion.

I don't think hardware and their resources are the main problem. Surely it would be possible to buffer and transfer the sensor data over USB to any device. The interface is absolutely fast enough to do that (wireless obviously not, at least for real-time capabilities)
The main problem would be the compatibility of the external device, which is not under control and to ensure proper function with thousands of different devices.
Another factor is: to go for big fleets or competitions, were your need machines without external devices, this would cause the need to have a device like PM5 with the same capabilities (at least for sensor processing and main metrics) anyway. So development would increase without any benefit but probably loss in money due to lesser HW equipped machines. Or the money must be compensated by license costs of the external app running on the external device.

Difficult to discuss without knowing technical details anyway.

[JaapvanE]

But what JaapvanE said (about the very specific hw you need to process the high-freq sensor data with low latency) may end the whole discussion.

I don't think hardware and their resources are the main problem. Surely it would be possible to buffer and transfer the sensor data over USB to any device. The interface is absolutely fast enough to do that (wireless obviously not, at least for real-time capabilities)

In embedded software development we typically distinguish between "General application OS" (i.e. Android/Linux, iOS/BSD, Windows) and Real Time Operating Systems (RTOS). A general application OS is good at picking up a big task and completing it, then picking up the next big task. If it is doing its big task, a next task must wait in line before it is even considered. In normal life, this switching is so fast, as a user you will not notice it. An anology: a cashier in your supermarket. Typically you will get there, but response time is in no way guaranteed as it is highly dependent on the traffic in front of you.

In embedded systems we work with Real Time Operating Systems, or Near Real Time Operating Systems (i.e. Linux with a highly modified/PREEMPT kernel). These are not designed to handle big heavy tasks. In fact, as soon as a higher priority task comes in, it will drop everything it is doing and pick up that higher priority task. An anology: a medic in an emergency room. The response time for high priority tasks (latency in processing) is almost guaranteed, but lower priority taks might suffer some starvation. The latter is the reason why it isn't generally useable for consumer products yet.

Both have their place: for general applications a normal OS with sufficient CPU and memory suffices. However, for processing high frequency signals, this isn't acceptable as you need to process the data as it comes (as you need to tell apps like EXR a stroke has finished for example). And let's not start about finish times being only close to the real time.

I don't know how C2 made the current hardware, but as I read their schematics on the FCC website, they have parts of dedicated chips reserved for processing the tach-signal. Looking at a software based design, it is really tough to guarantee a decent response time overall. That is why ORM has a three-stage design combined with some OS-level tricks:

• we have an extreme high frequency part, which measures the timing with a specific flank in nanosecond precission. You need this precission as it is needed for getting detailed info about the angular velocity and acceleration (between successive measurements you don't get as much difference in times, so these small measurements matter). This part is extremely small, runs extremely close to kernel level, has a dedicated high performance CPU core all by itself and has a huge priority (in practice, only the kernel clock is more important).
• On a C2, this flank passes by every 5 to 10 miliseconds, which is reported to the second stage. This second stage thus needs to process this data as soon as possible and recalculate all dependent metrics. Please note, as you need stroke detection for drag calculation, all metrics currently shown by a PM5/ErgData are direct byproducts of these calculations. Typically this also runs at its own dedicated CPU core which is set to high performance at a near-kernel level priority (just below the stage 1).
• The third stage are the consumers. ORM has a webserver and client on board, which usually gets updated every 80 ms, but the client can be offloaded to other hardware (as a browser is a pretty CPU intensive thing to run, especially on older RPi's). ANT+ will broadcast a position report every 400ms, which isn't that time-critical. However, the PM5 BLE interface will instantly broadcast as soon a stroke ends. This is essential in the user experience as several clients sync the visualised stroke on screen.

As said, offloading the webclient can be done easily. Offloading the bluetooth part is tough.

Initially we experimented with an Arduino for stage 1 (as it is interrupt-driven, you need to do less tricks to get it measuring with enough accuracy). It can't handle the calculations. So we offloaded stage 2 and 3 on a Raspberry Pi, and put a USB cable in between. It wasn't succesful as USB is designed to process large data volumes in bulk, not small messages with extreme low latency. So, we ended up killing that avenue as it wasn't stable. Currently there are integrated industrial boards combining the two, but these aren't generally available to a wide audience.

The main problem would be the compatibility of the external device, which is not under control and to ensure proper function with thousands of different devices.

There is another part here indeed. In development of ORM we see a lot of off-brand machines. To get it working on a random machine, you need quite some data about the mechanics of the machine, like number of pulses per rotation, flywheel inertia, sprocket size, minimum and maximum flywheel speed, etc.. You need this engineering data to get stroke detection and drag calculation working. This typically is contained in the PM (we have been working for over 2,5 years to get the optimal data for a C2...). Although not extremely secret, it opens doors that IMHO should remained closed.

What I mean is that it opens the door to "weightdoping" like scenario's, where people are adjusting parameters (selecting a different device than they actually use) to suit there ego/needs. In cycling these have been already seen. This is why ORM simulates certain PM5 messages, but deliberatly lacks others (aside not being able to generate a verification code), as it could be used to cheat as all parameters can be adjusted by the user.

Another factor is: to go for big fleets or competitions, were your need machines without external devices, this would cause the need to have a device like PM5 with the same capabilities (at least for sensor processing and main metrics) anyway. So development would increase without any benefit but probably loss in money due to lesser HW equipped machines. Or the money must be compensated by license costs of the external app running on the external device.

This is where I think rowing has a huge advantage over cycling. In cycling, you have small devices (power meters, etc.) who spit out simple measurements. But there is no way to verify what the overall result of the effort is, as it lacks context. Indoor cycle races now require two independent power meters to be in constant agreement to be able to compete. Still people were able to cheat, as nothing you can see can be trusted, as it all runs on hardware that is not closed off to the user.

The PM5 is designed to be stand-alone, and it can be told to control the entire race for that specific machine. It controls every movement, and it can sign the result with a verification code. Aside physical tricks on the PM5, that is a huge step beyond the simple metrics these simple cycling sensors provide, as the results can be trusted. Network issues and all other things might fail on you, but as long as a PM5 is given the right race parameters and comes back with a signed result, it is almost foolproof.

[HornetMaX]

I think Sakly was more talking about having software that runs on different devices (e.g. different smartphones), more than supporting different rowing machines.

I agree that there's a need for signing stuff and avoid too easy cheating, but this is the case already today: the PM5 signs the crucial stuff, the external app just pushes the signed thingy to the logbook. No need to change that.

In the end I also agree with what you said earlier: we're already more o less in a setup where the PM5 does part of the work and lets another device/app do the rest (if needed). It's just that the cost of the PM5 seems off: ORM on ESP32 seems to provide more or less the same for a small fraction (unless I'm reading it wrong). So yeah, maybe people ends up expecting a bit more from it.