Replies: 2 comments 23 replies
-
|
Using this version might deliver better results and has more functionality: https://github.com/JaapvanEkris/openrowingmonitor which actually has been tested on a kayak erg already (see #150). Current version here is a bit stale (as in 2 years old), where our branch has matured and improved a lot. When looking at using it commercially, I personally have no objection as long as major improvements (like improving the GUI) will flow back to the main project. We have some room for improvement in the GUI, especially when setting training targets, etc.., which would be a huge improvement for the core product. I can imagine some stuff will become proprietary for you guys, but that is certainly open for debate. I know @Abasz (one of my co-developers of my branch) is actually using it on a kayak as well, so he might be interested in cooperation as well. |
Beta Was this translation helpful? Give feedback.
-
|
Yes. That is what I am expect to have for my ergometer. touchscreen monitor with raspberry pi and reed sensor connection. I think I can make touchscreen cover with raspberry pi. It is much more economical for us. |
Beta Was this translation helpful? Give feedback.
-
Just a side note: ESP32 S3 officially supports up to 9 connections, though the library I use defaults to maxing at 3. Currently ESPRM allows 2 concurrent connection (which can be upped to 3 and the performance would still be good), and it does not care about connection order. I use it with connecting to my phone and may garmin watch simultaneously. So technically Jaap's idea of two devices can be implemented. The Rpi's BLE stack should support this as well (we already do concurrent connection when broadcasting metrics via BLE and receiving HR data from a strap), though I am not sure how this can be leveraged with the nodejs stack ORM uses. |
Beta Was this translation helpful? Give feedback.
-
|
By the way, is it better to install multiple magnets on flywheel or just two? |
Beta Was this translation helpful? Give feedback.
-
That depends how accurate you can place them in terms of equal distance. Concept2 uses 6. KayakFirst Blue version (after 2020) uses 6 too. KayakFirst orange (2019) uses 1 (this I have upgraded to 3 because 1 was just not enough for the engine of ORM). On kayak ergs, the strokes are shorter than on rowing machines as well as there is significantly less difference between the recovery and the drive length (in terms of time). Actually based on my experience they are almost equal when sprinting. This means that the application has less datapoints to work with in determining the recovery period and the drag factor. So having at least 3 magnets if they are place really well (i.e. in very equal distance) and the delta time between the impulses are really equal, yields good result. That said, if the placement is accurate the more you have the better force curves can be created (in general), at the cost of more computation time. Rule of thumb based on my experience is that there is no point going over 6 and the best to have at least 3. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. Since I make the flywheels I have enough space to place multiple magnets in exact distance. I will go with 6 magnets. |
Beta Was this translation helpful? Give feedback.
-
Does this have a sliding bench? That is something unchartered from a rower profile perspective, though I would not expect issues there. |
Beta Was this translation helpful? Give feedback.
-
ESPRM does not support touchscreen or other monitors directly. It exposes metrics via BLE (and via Wifi through WebSocket for now, but I expect to remove that feature by the end of this year as BLE is superior and more performant on ESP32). The only way is to have a tablet or other device preloaded with the setup to connect to the BLE service (which would require an app or the WebGUI) That said it is possible to add touch screen driven by the ESP32 and present the metrics on that, but I cannot help with this (as the code would be touchscreen specific, probably using some Arduino library, not to mention the performance impacts of driving a TFT screen from the device running the rowing engine). I am also not sure if the ESP32 would have sufficient memory to handle a GUI (it has only like 3mb free). Probably such thing would only work if the display is driven by a separate MCU that connects to the ESP32 via serial (SPI or UART). In terms of screen the Rpi is probably an easier choice, though the Rpi costs about 10x the price of an ESP32 :) not to mention the battery considerations (even the smallest Rpi is a power hungry beast compared to an ESP32 and then the power consumption of the LCD/TFT panel is not considered) assuming running the ergo from battery is an the table. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your reply. Since it is an indoor ergometer, I think I can use regular 220V or 110V. I will first try with Rpi module and get back to your with results. Again, Thanks of every advise! |
Beta Was this translation helpful? Give feedback.
-
Why not keep the WebSocket or better, move to a webservice? In all honesty, that is the approach I are aiming for on ORM: just provide a simple JSON object for the data for the GUI to poll, and provide a command interface for handling commands (when you look at https://github.com/JaapvanEkris/openrowingmonitor/tree/V1Beta_Architecture_Revision you'll see that structure already appearing.
Well, the Pi Zero 2W is around 20 euro's, which is doable. A consideration is to do the same thing Concept2 is doing: use the flywheel detection mechanism to power and charge the monitor. They have a small full-bridged rectifier in the circuit, providing 18V. |
Beta Was this translation helpful? Give feedback.
-
To have websocket the ESP32 and the client needs to have Wifi and they need to be connected to the same Wifi. So for instance when I go to the boat house where we have the ergs, I need to share Wifi from my phone, not to mention that SSID and Password management is a pain. BLE is much more convenient. Also the whole SSL certification is literally unfeasible as ESP32 does not have the memory for that. Which means that connection to the ESP32 webserver is unsecure (which again makes SSID and Password management a pain). BLE is plug and play. Also serving the WebGUI over http (which is considered as unsecured context for web browsers) limits a lot of features (like browser BLE API or persistent browser storage API for a log book). The WebGUI now is run as a Progressive Web App (under service worker) which allows offline usage. It is served via GitHub Pages (https://abasz.github.io/ESPRowingMonitor-WebGUI/). It has proper SSL certificates and all browser features are available, including browser database for persisting the recorded session in a log book. In addition the PWA is installable so it can work offline and accessed like a native android app which is much more user friendly.
I was following these changes. I remember we had extensive discussion around these. The only thing we were not able to conclude is the way the data is shared/streamed
Actually, I would be happy to contribute to the peripheral part (BLE, ANT+) once the metric context is fully implemented. If that is available a data stream can be setup from the rowing engine that broadcasts on every impulse or data change or metric context change or etc. (TBD) and the peripherals can act accordingly. |
Beta Was this translation helpful? Give feedback.
-
That is a good point. Hadn't considered that one yet.
I've played around with both options. The push option is way more reliable: some consumers (i.e. the PM5, tcx and RowingData) are actually triggered by very specific conditions (i.e. start of a drive, start of a recovery or the start/finish of an interval). When pushing it to all consumers at once, everybody acts if he sees fit based on that. You certainly need some local caching, as some clients need the last info to broadcast when their schedule is triggered (i.e. ANT+ and BLE), but it works well for the recorders. It will cost some storage in the app for the entire structure, but in the grand scheme of things it is a tiny increase as we already store all data for all previous strokes in the RowingData and TCX recorders. A pure pull-approach is tough. As the metrics updates are actually quite unpredictable, it becomes a guessing game for the consumers when you use a pull approach but look for a specific state. This makes not missing a critical message extremely difficult, or you need insane polling frequencies from the consumers. I couldn't get it to work well for context-dependent recorders. I've played around with a hybrid model, where the data was requested based on the broadcast context info for some, and requested on time for others. An optimisation as it is requesting data purely time-based for some peripherals and recorders, which would work on the BLE FTMS and ANT+ side, saving a bit of transport. I am experimenting with an alternative tcx recorder (which is time based, as intervals.icu likes that more), so it would request the data update on the next "second tick". I noticed it is just cumbersome as you end up having timers set in some places (pure pull) and some react to a specific state message being broadcast. Injecting the data store works only so far, but it gets messy as I had time-based recorders read dirty data (i.e. a half updated record) and thus power, pace and force curve didn't allign anymore. Might be a freak incident, but in the end I decided it was a lot of overhead to fix dirty reads for a little gain in data storage. So my approach is to move to the pure broadcast-based approach but move aways from Lars' approach of codifying the event in the message type as the events might overlap (so move to the context based binary thing in the branch). Sessionmanager and context-object work well with the recorders for hundreds of sessions now. So it is getting dependent on pushing the "intelligence" of the context object from server.js into the deep details of the pheripherals, making them independent consumers with their own responsibilities.
Your help is very welcome. Basically, every consumer (peripheral of recorder) will get a full metrics update on every currentDT, which has shown to be extremely robust for the recorders. It is crude, but I haven't seen any issues at all in the recorders. |
Beta Was this translation helpful? Give feedback.
-
We are a new company in Korea developing kayak and SUP ergometer. I found out that your monitor app is perfect for us. Please let us know what to do if we want to use your app for our products.
Thanks.
Sanghun Kim
Beta Was this translation helpful? Give feedback.
All reactions