Pls support Raspberry Pi OS 13 (trixie)

[glup4711]

Simply because it's the current release of Raspberry Pi OS...

The current install script fails because there is no package named pigpio.

:-glup

[JaapvanEkris]

This is the reason we don't support Trixie.

pigpio is an essential part of OpenRowingMonitor and we haven't found a suitable replacement for it yet. pigpio is the only one reporting in nanosecond (us) accuracy, which is needed by us.

[Abasz]

Just out of curiosity which kayak ergo do you have? I have a port of this project to esp32 ESP Rowing Monitor (https://github.com/Abasz/ESPRowingMonitor) which has calibration for Kaya First and Old Danube (will ve released shortly).

[glup4711]

I have a KayakPro SpeedStroke GYM - Kayak and yes, I had recognized your project before and will also give it a try possibly next weekend. I like that it is based on a μC without a full blown OS like Linux. And I like ISR instead of polling. Just because of less processing. The reason to try first ORM was just because I had the Pico 2 W yesterday first in my hand.

[JaapvanEkris]

I'm sorry but english is not my mother language and that the idea came up that I complain.

No offense taken. Trixie is a challenging OS as also the GUI is moving to Wayland, and we want to be as flexible as possible in our webkiosk setup.

Looking at pigpio: we share this issue with a lot of 3D printer apps who also need this level of accuracy. We just need to give time to the people developing it. If they fail to produce a new version, we might switch back to the old library. The algorithm can probably take it, but I'm not willing to give up this level of accuracy without a fight.

And no, I do not run on a Rpi 5. First I read that it is not supported in the instructions but I never planed to do so since for me it is shooting with an intercontinental missile on a bird. I use a Raspberry Pi Pico 2 W. In my understanding still a very big gun for a small bird

There is a lot of CPU-intensive math going on behind the scenes (even after our thorough algorithmic optimisations last year). And you get a pulse every 5 miliseconds, so it needs quite some CPU power to keep ahead of the data. An ESP32 is easier as it has interrupts, but it is limited in terms of CPU. I noticed that measurement accuracy and CPU load are closely related. This might be less of an issue on an ESP32 with interrupts, but making sure that data is processed in time is extremely tough. @Abasz had to offload the GUI for that reason and did an incredible job on minimizing CPU load without hurting the metrics too much. So it might feel like overkill, but there isn't that much slack.

[Abasz]

had to offload the GUI for that reason and did an incredible job on minimizing CPU load without hurting the metrics too much. So it might feel like overkill, but there isn't that much slack.

Actually I was going to say the same thing, namely that I have benchmarks on ESP32 and with a flank length of 12-15 it takes 4-5 milliseconds!! for the algorithm to do the calculation on every new data point!!. That is an eternity in CPU time... The trade off for ESP32 is the separation of GUI and the drop of many other convenience features (like Strava upload, workout file generation, workout/interval guidance, wifi metric broadcast, only per stroke data broadcast etc.). So for resource issues ESP32 is really purely a sensor that shouts information into the air, while ORM is a full blown standalone Performance Monitor that will work on its own. That is the decision you have to make: (i) Simple use, robust GUI (ORM), (ii) small size factor, cheap, fully battery operatable.

Just as a sneak-peak of what can be done with ESP32 (actually what it is for) and I am developing with a kayak ergometer manufacturer OldDanube:

Any way, polling on Rpi with pigpio is very light weight actually (its unnoticeable) and the latency that is introduced cannot be really distinguish from random error to my personal experience (I have run MCU and Rpi side by side in the past for testing for both on-off and pigpio: laberning#85).

What I am trying to say is that when you chose between Rpi and ESP32 the main decisive element should be how you are going to use it rather whether the hardware is overkill or not. If you will use it at home where you will have WiFi and proper power supply ot the Rpi, chose ORM. The whole thing is simpler to setup and everything is in one place (you can port forward the ORM port and open the Gui from your phone or computer, hell I was able to launch it even on my smart tv :)). Its more flexible in terms of many aspects.

If you go to a kayak boat house to train (like mem, originally) where there is no WiFi for the GUI and battery is 100% more convenient, chose ESP as the original hustle with setting it up will will return on daily use.

Also if you mass produce, ORM is not the way to go as it is too expensive. The board on the picture cost around 5EUR when as a private individual buys 1 piece. So for mass production that is the way to go. But when you will implement one device the additional 15-20 EUR will not be relevant.

[JaapvanEkris]

Just as a sneak-peak of what can be done with ESP32 (actually what it is for) and I am developing with a kayak ergometer manufacturer OldDanube: ![20251005_105412].

Ooooh, that looks so sweet! It is way more battery than pcb. Nice work my friend.

[Abasz]

It is way more battery than pcb.

:) :)

Yeah, we were debating if 4.5v (i.e. 3 battery) should be used, as in that case the efficiency would be better and the whole thing would be smaller, but due to the dropout voltage of the LDO we would not be able to empty the batteries (as around 1.1v device would not start). So efficiency here is crap and the EUR/watt is also bad as we burn a lot of capacity away on the LDO when stepping down the 6v to 3.3.

[JaapvanEkris]

But realize what you are saying here. In the early days of ORM I used a 20 Ah USB-C powerbank to power it. And that wasn't set to high performance mode yet. Technically it is a cordless solution, but it was huge.