PM4 with Apple Watch Series 9?

[Hopper]

Hi guys,

I have a short question:
I own a rower with the old PM4 for 10 years.
Now I will buy an Apple Watch Series 9 and I also want to use it for tracking my trainings.

Is there any possibility to connect the watch with the PM4?
As I remember there was a kind of Ant+ kit available?

I am new to this topic so please dont kill me.

Best regards
Hopper

[Citroen]

Not without buying an exceedingly expensive cable.

Buying a new PM5 from Concept2 and selling your old PM4 on eBay or Craigslist is a better option.

[Hopper]

Ah, ok, if this is the only useful thing, maybe I will wait for a PM6 or something like that.

The PM5 is there for years now and I dont want to update for over 200 Euros and then a PM6 comes out afterwards.

Thank you very much

[JaapvanE]

The PM5 is there for years now and I dont want to update for over 200 Euros and then a PM6 comes out afterwards.

Please note that Concept2 isn't like Apple and that the PM5 has been silently updated several times now. So a PM6 might be announced tomorrow (despite the RowErg being launched as a "new" product two years ago) or it might be a decade away. Nobody here has insight in that timeline and strategy, but currently most effort seems to go to the ErgData app, not the PM5.

[Carl Watts]

I guess the monitor is still good for the gym environment but for the serious user the PM should now be replaced with your phone or a tablet.

The TACH pickup on the side of the flywheel should now be replaced with Bluetooth in it and your phone becomes the PM6.

[JaapvanE]

I guess the monitor is still good for the gym environment but for the serious user the PM should now be replaced with your phone or a tablet.

The TACH pickup on the side of the flywheel should now be replaced with Bluetooth in it and your phone becomes the PM6.

In essence, that is what the PM5 is already. In terms of data aquisition and processing you need a bit smarter device than a BLE transmitter: the protocol is way too sloppy and sluggish to handle raw data. In essence, the current protocol is the ideal abstraction point, and the PM5's dataset is much richer than anything on the market today.

More modern approaches (like the WaterRower SmartRow, see
https://www.waterrower.com/us/products/smartrow) do the same as the PM5, only in a more compact package without a screen and buttons, and indeed an app to control it. Some set up OpenRowingMonitor the same way: hide a Raspberry 2W in the chassis and let a browser or app on top do it all. It is a neat construction, but highly depends on the users access to a tablet/smartphone and their comfort with technology.

Indeed great for home users, less ideal for gym owners.

[Carl Watts]

You can just use Bluetooth to transmit the raw analogue pickup signal, its not rocket science that signal is way less complex than the music you are already sending all over the place, its not even 2 channels and its low frequency and looks a bit like a HR ECG signal.

Amplify it, run it through a micro and just transmit it Bluetooth. Actually buy the time it goes into the micro its just digital anyway, basically a pulse stream. Depending on the micro used it could just relay this or do the math and send the data to your phone exactly the way ErgData is running right now.

Your phone or tablet has plenty of grunt to run the math and it becomes the "Hub" and solves all the connectivity issues.

The C2 pickup may need ANT+ because that's just not being integrated into phones still.

[JaapvanE]

You can just use Bluetooth to transmit the raw analogue pickup signal, its not rocket science that signal is way less complex than the music you are already sending all over the place, its not even 2 channels and its low frequency and looks a bit like a HR ECG signal.

I know the signal well, I've written the Open Source Software that analyses it and transfoms it into a decent set of metrics. And I've contributed to its bluetooth stack.

No it doesn't. Music works because you can buffer the raw compressed data on the headset, which is impossible to do for a signal that is generated in-situ. And you can drop data without issue in a phonecall. In a datastream of stroke pulses, you don't have that luxury.

Amplify it, run it through a micro and just transmit it Bluetooth. Actually buy the time it goes into the micro its just digital anyway, basically a pulse stream. Depending on the micro used it could just relay this or do the math and send the data to your phone exactly the way ErgData is running right now.

No. This is how OpenRowingMonitor already works, and what its most challenging issue is. We trigger on the upgoing flank crossing 12V. A RowErg at slow speed already produces a pulse every 5 ms, which its timing needs to be accurate to 5 us to be usable.

Some initial designs we had preprocessed the signal into a datastream on an ESP, and delivered it to a Raspberry Pi. We found out the hard way that transmitting such a fast stream of data is asking for trouble even on a dedicated physical serial channel. On the Pi, we can't even write the raw data in-situ as it gets mixed up. We need to wait until the session is completed and write it all at once to guarantee the right order.

Your phone or tablet has plenty of grunt to run the math and it becomes the "Hub" and solves all the connectivity issues.

Aside the obvious artchitectual issue of an extremely bad seperation of concerns and violating every principle of embedded software design (for example layed down in ISA-88), this will not work. There is a reason why the whole fitness industry has designed Bluetooth FTMS in the way it did: it is the only sane approach. The equipment processes its own data and provides meaningful more abstract data to consumers. Your bike power meters also report preprocessed data, not the raw data, as that should be done device-side, not consumer side.

To illustrate the short-term architectual issues, think of all connecting apps in the ecosystem. Should they also do the math themselves or connect to another app on the phone (which Android and Apple do not allow directly) to recieve the data? And as these connecting apps are much more graphics intensive, they will claim a considerable part of the CPU and GPU. And people will call the support desk if something is unclear or misbehaves.

A good thought experiment is also to upgrade the RowErg to the RowErg Mark 2, with a totally different sensor package. The PM5's successor could nicely hide it from data consumers. When an app does the heavy lifting, the app gets a totally new branch and becomes bloated at a point where it gets in the way (i.e. high frequency data processing). Hence the general embedded architecture approach of abstracting away from high frequency raw data to meaningful low frequency data as soon and as close to the specific hardware as possible.

And a general purpose device can't do the math, despite its impressive CPU figures. CPU figures present throughput but don't reflect latency, which in a general purpose OS isn't guaranteed. And latency is your biggest issue in processing datastreams. A general purpose machine has too many tasks that are considered critical going on to be responsive enough to work well. Processing every SMS or WhatsApp message that comes in will have a higher priority than the signal processing. Hence the use of dedicated equipment for data processing in all applications.

OpenRowingMonitor works well on a RowErg on a quad core Raspberry Pi because of several tricks, you can't do on a phone (despite using the same underlying Linux OS):

1. We do the basic signal processing inside the kernel directly on the hardware interrupts, allowing us to get that 1 us accuracy;
2. We deactivate the kernel's energy management as it introduces CPU throttling and put the CPU's in high performance mode full-time. On Android this would drain a phone battery in less than an hour and overheat the phone, and thus isn't allowed on stock Android kernels;
3. We use a pre-emptive kernel, allowing our process to manage latency (general purpose kernels like Android can not do this);
4. We assign a dedicated CPU to dataprocessing, so we don't have anyone on our CPU, not even the kernel. On Android these commands are restricted and not available to user-level applications;
5. We use the highest priorities that allow the kernel to function, basically excluding all other applications running, including OS housekeeping. Android doesn't even allow for setting these priorities, and has many high priority tasks running.

This stuff is needed to do the raw dataprocessing on a pretty well-cooled and high performance CPU. A phone won't allow you to do that. It is not made to do that, as it is a general purpose device running on batteries. Whereas the PM5 is self-powered and a 100% under control of C2 and dedicated to the task.

The C2 pickup may need ANT+ because that's just not being integrated into phones still.

ANT+ only allows a message every 400ms, and is broadcasts to seriously energy constrained devices. You can't have a watch process this data as it lacks the CPU power. So you must preprocess data anyway.

[Citroen]

Ah, ok, if this is the only useful thing, maybe I will wait for a PM6 or something like that.

You'll wait a long time for that, it isn't announced so could be ten years or more. Just buy a PM5 and sell the old PM4 you will get what you need.


Note to Carl: I nearly deleted your postings which are a bit far off topic, but you're not Slidewinder.

[Carl Watts]

Yeah I don't see the PM5 being replaced anytime soon.

The future is simply your Android tablet replacing it anyway, its already happened on higher end exercise gear like the WattBike Atom.

[JaapvanE]

Yeah I don't see the PM5 being replaced anytime soon.

The future is simply your Android tablet replacing it anyway, its already happened on higher end exercise gear like the WattBike Atom.

But the WattBike Atom is an BLE FTMS machine. It provides a very basic position report (distance, time, speed, power, HR, cadence, etc.) around every second without much detail. It certainly does not provide raw data. In essence a very basic PM without a screen.

To clarify, a PM5 calculates these basic metrics, but also a lot more. When comparing the data provided by a PM5 to a BLE FTMS device (or ANT+), the native PM5 BLE interface provides a much richer dataset.

I think the screen is hard to ditch. For gym owners it is a must as most users hop on and don't care about data. And in home settings, my experience with headless devices is quite negative: the device can't tell its ip-adress or other connectivity status. Without a screen to provide feedback, setup quickly becomes challenging.

I agree the PM5 might last decades. It is a robust monitor (a must for gym owners) and it provides a huge set of connectivity options to apps and other data consumers where the real innovation takes place. Only obvious improvements I see is adding a touch screen (which is a huge cost driver, so probably not) and adding WiFi (which would only be of use to home users, so probably too small of a market). Adding new sensors might be happening, but then the machine has to be new as well to make use of it, so the benefit is quite limited. Minor tweaks might improve the USB port to support newer USB sticks, but that might also happen in a typical silent C2 incremental HW update.

[bambu]

You could get this device that takes the ANT+ fitness equipment signal and converts it into Bluetooth FTMS. https://npe.fit/products/wyur
I have one and use it with my spin bike. Haven't tried it on the concept2 yet but will experiment with it once winter training starts.

[Aquaman]

You could get this device that takes the ANT+ fitness equipment signal and converts it into Bluetooth FTMS. https://npe.fit/products/wyur
I have one and use it with my spin bike. Haven't tried it on the concept2 yet but will experiment with it once winter training starts.

Which spin bike did you use for the WYUR and what did it give? Was the setup easy? Did you need a special app to get the data?
Thanks!