JaapvanE wrote: ↑August 14th, 2024, 11:44 am
Sakly wrote: ↑August 14th, 2024, 10:43 am
HornetMaX wrote: ↑August 14th, 2024, 9:22 am
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 devices) omes (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.
Sakly wrote: ↑August 14th, 2024, 10:43 am
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.
Sakly wrote: ↑August 14th, 2024, 10:43 am
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.