MigGat - I wrote a polar recording plugin. Init...
I wrote a polar recording plugin. Initially it was just for me, but me, but if you might find it intesresting, and someone can help me with publishing to npm, i'll gradly share!
It can display current polar, as well as any recorded polar. Polars can be recorded incrementally, or a totally new table. It also displays the current TWA/TWS/Speed point so you can check how good is your performance
68 Replies
Looks nice, I'd like to try it. Publishing to npm is really easy as I just learned myself: Create an account, set up 2FA (I tried without but they send you one-time-passwords by email, which many times arrived too late and were expired in my case, a real PITA), get all the info in package.json in good shape, include license info and README.md and type 'npm publish'. Authenticate and off it goes.
As soon as i finish with my other project, i will make this public 🙂
Meanwhile, fell free to check it out! https://github.com/miggat/signalk-polar-recorder
Nice work!
Thanks! All suggestions are welcome of course
There's a couple of things I thought of while thinking about creating one myself:
- Configurable time on-course for speed data to be valid (e.g. 10 seconds within 1 deg course)
- Engine detection (learning off)
- Current detection (learning off)
- Use Pitch/Roll for wave size detection, as polar could have multiple versions for different wave heights
- Store timestamp with values to allow for aging of data.
- Fresh / Salt water difference
Note taken!
I already had in mind this 2:
Engine detection (learning off)
Store timestamp with values to allow for aging of data.
Let's see what i can do with the others
I think this ft from HansT is very important:
- Configurable time on-course for speed data to be valid (e.g. 10 seconds within 1 deg course)
Unknown User•5mo ago
Message Not Public
Sign In & Join Server To View
Good morning, looks really promissing. Would like to test it once in npm. Engine on detection could be implemented by rpm > 0 on one of the engines. My personal tream would be a automatic mode that runs 24/7 in the background and records when not moored or anchored, It will learn as we go and permanently improve based upon our voyages. With the ability to export the current model I could feed a weather reouting software. Hope you will push it this direction one day.
Sorry guys, i've been very busy with my regular job and temporarily abandoned this project for a couple month. I'm back on it, and adding all your suggestions (including the background learning). I hope to be able to publish to npm in 1 or 2 weeks
I finally published a very beta (or alpha, LOL) version. I don't have time for more right now, but i'll write a readme ASAP.
Meanwhile, if you want to test, the "recording in background" seems to work perfectly fine, and updates the polar in real time (no need to have the webapp open though, of course).
Let me know if you find errors or features not yet implemented, as it will be quite easier for me to address them one by one based on what people ACTUALLY need.
Also please note that i haven't been able to sail for a while, so it's all been tested with SKSim
https://www.npmjs.com/package/polar-recorder
@Dirk SV MOIN The current 0.0.3 version does exactly what you asked for! Except for exporting , which will be there in v0.0.4 (hopefully today)
Added polar export in v0.0.4
Added import polar in v0.0.5
Added in v0.0.8
Great! Can‘t wait to get to the boat and try it!
Great! If someone can test it would be awesome, because i won't have my boat fixed before 6-8 weeks, so impossible to test without sksim on my side
This week i'll be working on these 2 feature set:
1) Polar management (delete, merge, purge all data)
2) Manual recording. Meant to take an existing polar and update with new recording. I.e: After changing some sails or anything that can improve boat performance.
I'm afraid i'm not skilled enough for the wave height considerations. I mean what kind of formula would you apply? Some correction factor to boat speed based on wave height?
There could be another dimensions of wave height and direction to polar. For wave height measurement you could use Bareboat Necessities heave (wave height) frequency and direction sensor with IMU. See
https://github.com/bareboat-necessities/bbn-wave-period-esp32
Interesting. I will try with the IMU already present in the MacArthur hat. But that will have to wait until my boat is on the sea again
This is how it looks in a jailbroken axiom
Guess i'm better coder than photographer 😅
Hey @MigGat super keen to help testing!
We have been assing sea state related polars in professional racing for years. I am not aware that anyone actually really nailed it. The challenges:
- How do you meassure the sea state in the first place. Not just wave height is a factor, wave frequency and angle to the course are just as important.
- To measure thease directly is near impossible. The best way would be an INS recording not only heading but more so 3D accelerations - trim, heel, yaw and heave - and to put these in relation to the relative performance.
- The usual challenge: You need an enormous amount of collected data to make this relevant.
In my eyes not worth trying.
What we do instead - once we have a first set of polars - is disregarding data points with more than 110% VMG and less than 80% VMG. That way - over time - you generate polars that work perfect on a "normal" day. When you have a perfect day you simply need to aim at slightly overachieving and on a bad day vice versa.
@Feadur If you can implement such a logic (make the upper/lower limit a variable) while we are constantly recording, the polars would "rolling" update to become stable "normal day" polars!!
@Feadur It appears you are using wind.angleTrueGround, wind.speedOverGround for sailing however - imho - we would need to look at environment.wind.angleTrueWater, environment.wind.speedTrue
BBN sensor (open source) measures realtime height (heave) and frequency and direction of waves (observed from moving boat). You might look at it and see algorithms being used. There specifically designed Kalman filters for it. https://github.com/bareboat-necessities/bbn-wave-period-esp32
I was planning on making this fields configurable, so you can count on it next versión 🙂
Adding a VMG filter is definitely something I can (and will) do, so count on that too!
Regarding the sea state, I'll take a look at that BBN project, but as @voodoomatz said, it's not as simple as wave height/period. I will add something on that side too though
That being said I would love if someone could test the plug-in in a real boat and give me some feedback, because I can only test in a simulator
@mgrouch Very interesting read. Let me comment on a few things
i) If you want to dynamically dampen your polars due to sea state experienced, there's no need to try to calculate wave height, frequency nor direction. You can only measure 3D accelerations of the vessel e.g. with an IMU or INS. So might as well just stick to the core data instead of taking detours.
ii) On a sailboat it is more complicated.
- Do you smoothly sail up and down the waves or do you plow through? Makes a lot of difference to the vertical accelerations.
- As you're smoothly sailing up and down the waves you create a lot of yaw. That messes with any wave direction induced yaw. Well, I guess you could have an algorithm that measures rudder angle and deducts steering from the yaw. Hmm, you would either need vpp to understand how much rudder creates how much yaw or even more data.
- You could try to ignore the above and solve it with more data averaging all the challenges out ... well, a different helms man with a different style messes with that data, too.
- Ok, let's just look at the sideways movement of the vessel. Aaah, leeway, do you know the wind speed, heel and sail trim induced leeway of your boat at anytime?
... I guess you know where I'm going .. it's not worth the effort. At least not in less than Americas Cup budgets and they foil anyways 🙂
@Feadur I'm planning to have it in real world testing first week of august. Hoping you can smash out an update before then?? 😉
Polars is a first and crude approximation. There are more data available and more input parameters which can make the model more accurate.
You are not only measuring 3D acceleration with IMU. You are measuring 3D angular velocities with gyro. And with magnetometer you are measuring 3D magnetic forces.
Steering and helmsman are not a factors for calculations. Resulting boat movements are.
Think what polar is. Boat speed based on 2 parameters. Wind speed and apparent wind angle.
If you want to improve estimations you have to add more measurable parameters to the mix. 3D acceleration
is instantaneous and changes too much within short time. Wave direction and wave heights are not that changing. So that would be parameters you want to add to improve polar model.
And no. Wave direction doesn’t depend on helmsman way of steering or boat yaws. Helmsman steering introduces additional noise to estimation algorithm but algorithm should be able to handle it. Wave direction is an objective physically measurable parameter as well as wave heights
@mgrouch Please don't misunderstand: I find this discussion really fruitful.
How would you plan to measure wave direction while you are sailing?
It’s a plane in which your horizontal acceleration oscillates.
It’s a strong enough signal to extract and estimate wave direction. You can see how it’s done in the code. 3 files https://github.com/bareboat-necessities/bbn-wave-period-esp32/blob/main/bbn_wave_freq_m5atomS3/bbn_wave_freq_m5atomS3.ino
https://github.com/bareboat-necessities/bbn-wave-period-esp32/blob/main/bbn_wave_freq_m5atomS3/AngleAveraging.h
https://github.com/bareboat-necessities/bbn-wave-period-esp32/blob/main/bbn_wave_freq_m5atomS3/WaveDirectionDetector.h
Well, I think we agree this would be a pretty complex feature for a much later stage of @Feadur 's development.
I still don't really understand the need to calculate wave height, direction and period from accelerations first instead of just reading the accelerations. I guess the pros/cons are for a later stage.
The key challenge remains: You will need an extensive amount of collected data before you can make any reliable conclusions about the effect of waves on your polars.
Good discussion though! 👍
Just published v0.0.9 with configurable paths for wind speed/angle
Gonna start working on VMG filtering. However, i'm not sure I understand that. I assume VMG is velocity made good. How is it possible to be >100%?
Maybe i got it all wrong, and what you mean is to ignore STW values >100% and <80% of the VMG which is computed based on SOG. That way we ignore the "abnormally" increased/Decreased values when going down/up a wave. Is that correct?
Regarding the discussion about wave consideration, i find it very interesting too. I will implement at least the calculations for wave period/direction/height, because that's useful regardless of the polars.
But for cruisers like me, we don't really care about that much precision. My motivation to write this plugin was to have realistic polar file in order to use it in weather routing software. Many times there are no published polar for our boats, and even if they are, they come from the manufacturer, and they can be completely off for our sailing conditions. For instance, i usually sail solo, so i don't push the boat as much as it could be pushed. So instead of going to the weather routing software and putting the polar factor to 80%, i'd rather have a polar file based on my actual sailing experience.
That being said, i understand that racers DO need as much precision as posible, and I can't resist a challenge, so i will do my best!
Just published 0.0.10, which STW to VMG ratio filtering, as well as average spped deviation filter (easier to use for most scenarios).
Will start with sea state asap!
@Feadur Just looking at 0.0.12. Thanks for all your work!!
a) I spoke to our performance analyst. For better data he uses filters based on standard deviation. Maybe something for the future.
b) To improve data quality. Can you add filters for TWA and TWD stability? Like you did for BSP stability.
🙏
I did mean VMG 🙂 but the VMG taken from the polars calculated so far.
The think goes as follows: Once we have a set of polars
- and we sail only 80% of our polar-VMG, then either the sea state is horrendous and slows us massively or for any reason we are reefed too much or might only sail under jib... In such cases we ignore any collected data as it would pull our polars down.
- and we sail more than 110% of polar-VMG, there is something unusual happening. This is often wind shear. Or unusual flat sea state, etc. So we are achieving BSP (or TWA) we would not usually be able to achieve.
This is also the way I personally address the sea state topic.
Since we don't have a pre defined set of polars to get polar-VMG I was think of a maybe floating average over what has been recorded or something similar
Oh, I see, that's precisely what's shown un the GUI:
this presents an issue because as you said, we don't have a predefined set of values to compare. The way the plugin is currently working, when a new reading arrives, after passing all filters, if it's "faster" than the previous speed recorded for a given polar point, the point gets updated. So if there is no recorded value for a given polar point, the new value is just "the value". I understand that the first reading of a given polar point could be abnormally low (that is not an issue, because a higher reading will update it) or abnormally high. That is indeed an issue, because it would never be overriden by a "correct" value.
For now i will keep it this way, except that i will apply the filter to this factor (and not the VMG to waypoint), and will introduce the possibility of editing the polar table manually, in case you suspect a given measurement is wrong.
In the future, i will add the possibility of adding non-recorded points from close points interpolation -X%. The value won't be accurate until a proper reading is received, but at least it won't be so high that it could never be overwritten
I know standard deviation is the most used formula for this kind of scenarios. I'm just not sure it will work unless we have a quite large data sample per second. So i will add it as optional too
As for the filters for TWA and TWS, i will add that right away
Several changes added in v0.0.13
[0.0.13] - 2025-07-08
Added
- New global option:
useStdDev (boolean, default true).
- When enabled, average-based filters (STW, TWA, TWS) now use standard deviation (z-score) logic.
- Allows outlier detection and better filtering of transient anomalies such as wave-induced speed variations.
- All average-based filters (e.g. avgSpeedThresholdUp, avgTwaThresholdUp) support z-score limits when useStdDev is active.
Changed
- Filters now dynamically switch behavior based on useStdDev:
- If true: filters accept values within ± threshold standard deviations from the mean.
- If false: fallback to ratio comparisons like current / avg.
Affected Filters
| Signal | Time Window | Enabled By | Upper Threshold | Notes |
|--------|-------------|--------------------------|------------------------------|------------------------------|
| STW | avgSpeedTimeWindow | useAvgSpeedThreshold | avgSpeedThresholdUp | Uses z-score or ratio |
| TWA | avgTwaTimeWindow | useAvgTwaThreshold | avgTwaThresholdUp | Uses z-score or ratio |
| TWS | avgTwsTimeWindow | useAvgTwsThreshold | avgTwsThresholdUp | Uses z-score or ratio |
Example
@Feadur Mate, this is amazing progress and pretty impressive! Couple of comments:
- As you were talking about waypoints. When I say VMG I mean velocity made good to wind. For velocity made good to waypoint / course we generally use VMC.
- Loving the StdDev implementation. It's great. We could start without to build up some data and then switch to StdDev for further improvements.
- Could you also please add TWD stability?
How can you use accelerations? They are rapidly changing signals. How would you use them for that improved polar?
@voodoomatz Thanks for your comments 🙂
About VMG, i guess is just conventions in countries or sailing communities. Here we always refer to VMG as velocity made good to waypoint. But again, cruisers care about about performance only to a certain point haha
Regarding TWD. If you mean "True Wind Direction", how does that apply to a polar file? I've never seen it (but again, i only use polars for weather routing )
Yes, I mean True Wind Direction. Looking at the StdDev of TWD gives you an understanding of wind stability.
We would prefer to record data when TWD is rather stable. As we can then assume the skipper will have set a proper trim of sails, found his angle and is zooming along.
When TWD is very shifty, he/she might not constantly trim sails / adjust course so the performance will sub-standard.
For me when doing performance analysis, I filter TWD first, then VMG-to-wind (you could use STW but I prefer VMG) then TWA. TWD gives you wind stability. VMG has some indication of wind shear and STW some indication of sea state. TWA gives you an indication of helming.
My logic is: If the wind direction is stable, if there is not too much shear and not too bad a sea state, if we sail a steady angle then let's record the data.
If I understood correctly the suggestion is to use an IMU to measure 3d accelerations to then run it through several filters to then calculate wave height, wave frequency, and wave direction to then take that to somehow refactor polar targets.
I wonder why do all the math in the first place? Just dampen based on 3d accelerations. Rapidly changing signals can always be filtered, if that's a theoretical concern.
Anyhow, as I said, happy to park the discussion and to focus on getting the basic polar recorder working well first.
@voodoomatz Added TWD stability in 0.0.16, as well as repaired stdDev calculation in 0.0.17
IMPORTANT: COG and TWD stability do NOT use the standard deviation formula. Instead, they are based on a configurable amount of degrees variation in a time window (configurable too). I thought about that for some minutes, and decided is just much easier to setup for most users, and i don't think std dev is really useful here
@Feadur Getting very excited about your plugin now. Our preps for first week August are on track and I plan to keep the polar-recorder running the entire week. One more feature idea...
How about a configurable filter: If propulsion RPM > X, do not record.
Relevant SignalK sentences would be propulsion.port.revolutions, propulsion.starboard.revolutions, or propulsion.0.revolutions and propulsion.1.revolutions, etc.
What d'you think?
I didn't make this one configurable, because i though this should be a default setting:
let engineOn = instances.some(name => {
const stateVal = app.getSelfPath(
propulsion.${name}.state)?.value;
const rev = app.getSelfPath(propulsion.${name}.revolutions)?.value;
return stateVal !== 'stopped' || (typeof rev === 'number' && rev > 0);
});
It won't record anything if either engine.state is not stopped, or revCount >0Actually, if you turn on the engine, you will get an overlay:
Legend! For us on a 90-footer that works. As we are running generators.
I was just thinking a smaller boat might have the engine running in neutral while sailing to recharge batteries. So, I was thinking to have a configurable minimum rev to identify when they are motoring or motor-sailing.
(just FYI, stumbled over this.
Might be interesting for inspiration: https://github.com/lanceberc/polarize. E.g. Savitsky-Golay filtering might be something to think about longterm?!)
Maybe simply the option to use https://www.npmjs.com/package/@meri-imperiumi/signalk-autostate if installed, could be the easiest and quite smooth way?!
Seems interesting indeed, i will take a deeper look once i have time again
Yeah, that's mainly what I personally use, but you're right, i will add a check on wether to filter based on revolution count or on signalk-autostate's state
@Feadur Really enjoying this!! I will have time to test extensively first week of August.
A few days later the yacht will go on 2500NM trip and I have remote access. So ample opportunity to refine 👍
@Feadur It appears I the plugin does not accept a fully qualified path for "File name for automatic recording polar". Use case: I want to store these files on a mounted USB pen drive to reduce writing on the sd card. Hence, I enter /mnt/usb-storage/Polar-Recorder/auto-recording-polar.json.
In the Debug log I can see that the plugin cannot write to this path despite permission are correct.
@Feadur Auto recording works. However, I don't see the "record polars" button anylonger that we used to have in a previous version. How do I manually record? I think it would be a nice feature to have the option in the WebApp to create a new polar file (not just import / export).
Maybe this is all there??? I can see a "hamburger" menu in the top right corner. It does not work for me neither in Safari nor Chrome.
I found the "create new" and the record controls commented out in the HTML header....? Is this not working yet?
I will check all of this issues this weekend
Published v0.0.18 with these changes/fixes:
Changelog
[0.0.18] - 2025-07-09
Fixed
- Support for absolute path for auto-recording file
Changed
- Improved admin UI
- COG and TWD stability are now optional
- Manual recording has been completely rewritten
- Now you can chose to detect if motoring either with signalk-autostate or by max rev.
@voodoomatz Tanks for testing! And let me know if you find another error/missing feature
@Feadur First test on the water tomorrow. I noticed one issue:
We have 5 BSP sources. That has to do with plotters repeating the sensor data but also calibrated and uncalibrated date.
Can you please add a source selector which sensor to read from. Best to do it for both angle and speed. THANK YOU!!
@Feadur Also just thinking out loud, wouldn't it make more sense to have a filter on HDG instead of COG? HDG is more reactive. COG can "jump" occasionally particularly when there is multiple GPS sources.
Oh that said. A source selection is actually required for ALL the filters.
Yes... about the source selection is something i had in mind too, one for each required path
I will add an optional HDG filter too, it's about 10min work. Hopefully tomorrow morning both changes will be ready
@voodoomatz Or... today, in v0.0.19
Changelog
[0.0.19] - 2025-08-03
Changed
- Added HDG stability filter
- Now each path can be setup with each own source
- Improvements on filter efficiency
I also added a GPT generated readme which i must say, is suprisingly complete and accurate :S
Just out on the water .. this is akward: With the recorded datastream it was working fine.
I do have data though.
That's really weird, and really hard to debug. The only thing I can think of os something weird in the delta timestamps. Could that be an option?
Also, what interval do you have set up?
Interval is set to 1000ms.
I now have changed the data connection from n2k (pican-m HAT on Raspi) to N2k-over-Ethernet (YachtDevices EN-02). Still the same issue.
Attached what I see in the log. Nothing suspiciouse to me though
According to your logs, data should be recorded to '/mnt/usb-storage/Polar-Recorder/auto-recording-polar.json'
Is it happening? Or the file remains empty?
If there was any error, it would appear between:
Applying filters <<<
and
Valid data true <<<
@Feadur FALSE ALARM. I was confused that polar record was not showing any numbers - no wind in particular. However, we were sitting on the dock (BSP=0) when I looked at it. Now on the water it all looks fine.
So, first day proper testing today.
Nice! Let me know
- So one thing that threw me off is that TWA & TWS only show when there is boat speed. So, when we were still on the dock, I was assuming polar record wouldn't work.
- Another thing - it was a hectic day on the boat - when I load the webapp, it seems that it takes sometime before the numbers and the black dot show. Maybe until the first 5 second interval for the averages??
- I had a my user set to hold credentials to 1h. So after on hour, it had logged out in the background and then the webapp wasn't working properly any longer (and I just closed the window)
- I think (not sure) there might be an issue when the polar recorder is opened on multiple tabs. (My mistake)
- When I click on record, I noticed the green dot in the tab icon. It is neat but very hard to notic. Also, I don't get a "stop recording" button.
- The "updated at" time .. not sure what exactly it means .. whenever I select a polar file, it shows the time the file was loaded (not last saved, what is what I expected)
- When automatic recording is enabled, recording is always working, but since boatSpeed is 0, it should never update the file. Not a big deal to add check there though, and stop recording when boat is stopped.
- Yes, definetly, until the minimium points to pass the filters (recordingInterval * 5) are received, nothing happens.
- I found myself in a similar situation, but i'm not sure why this happens. What browser are you using? I need to dig deeper into that issue.
- There shouldn't be any problem when the webapp opened multiple times. It currently onmly listens to a websocket connecction. However, i noticed that if you click the "Record polar" button in one instance, the other one is not updated, so I have to fix that too. Similar issues can happen if you hit on record on one tab with a polar selected, and then repeat on the other tab with another polar selected. The later file is the one that will be updated.
- Currently, the only visual clue that the recording is in progress is the overlay on top, and the presence of the "Stop & Save" button. However, i just tested and it seems the overlay doesn't appear unless you refresh the page... so definetly something worng with the websocket connection. Will solve that too.
- The "updated at" is meant to display the last time THE CHART has been updated. Is quite lame and a legacy data that i just forgot to remove.
- Additionally, i noticed that the polar selector dropdown should store the last selection, so everytime you refresh the page you get the last one you were working on.
Gonna a be a busy weekend it seems, but worthy if this ends up being a good polar recording plugin!
Mate, 100% we highly appreciate your efforts!!
Also, I thoroughly belief this can turn into a very powerful plugin. We have done multiple 10k NM and the potential to optimise routing and fuel bunkering, etc with reliable cruising polars is BIG!
Actual true wind angle was around -79°
I started with the front end (web app) at the very beginning. Since then, i've rwritten the backend several times based on your suggestions, so it makes sense to me that there are several errors on the webapp, but luckily those are the easier ones to solve.
This happens because initially I thought the average use case would be to trigger polar recording manually, but you guys made me think that background recording makes much more sense for most users, so that changed everything LOL
I'm gonna start working on all the bug list right now, and then let's see how we improve the web app. For example, i plan on add certain features like "polar merging", several export formats, etc.
But first let's make sure it records accurate polars
Action plan is:
- Stop recording when boat is 0 (or configurable speed)
- Store last selected polar file in webapp
- On webapp, display recording overlay EVEN if there are no valid readings, but showing the reasons why there are not valid readings, so you don't have to go to debug logs
- Make sure ws reconnection works properly, which will fix several issues, like having webapp on multiple tabs/browsers/devices and having all them sinchronized
- Make usre the "updated at" clock display the last time when a point was recorded/updated
- Finally, review the top/right box with performance info. Aside from fixing incorrect data, I accespt suggestions!
@voodoomatz
Several changes in 1.0.1:
Changelog
[1.0.1] - 2025-08-09
Fixed
- WebApp now only updates the timestamp if a new valid point has been recorded to the polar
- Improved frequency of websocket reconnection
- Multiple instances of webappp can be opened in same or different devices
Changed
- Added a configurable way to detect if boat is stopped
- WebApp now stores las selected polar file
- WebApp now show reasons why current point is not valid
- Improved manual vs auto recording
---------
I still need to work on the "performance data display", as well as the fully redeseign i have planned
Already done with the rework for automatic recording. Hope you guys like it! Gonna work now on the manual recording
Published 1.1.0
There's little point to show the changelog, because i basically rewrote everything in the webapp side
@voodoomatz As always, i will deeply appreciate if you can test. You'll definitely find some errors here and there!
@Feadur The boat will remain on the dock for another ten days and then go on a 9 - 10 day voyage which I will monitor remotely. Hence, ample testing time!!
Great! Just make sure to update to 1.1.1, cause 1.1.0 had a really annoying bug
@MigGat Apologies, we've been pretty flat out with the refit and some related technical issues.
- I LOVE the new user interface. Very beautiful!
- I think we're still missing a "Delete polar file" button but lower prio as I can always SSH in.
- I noticed two issues - v1.1.1
1) The black dot seems to have disappeared on my polar chart despite having STW
Related to that, I'm not sure the plugin is properly recording?!
2) The "hald polar" button is not working for me.
Please keep up the great work!!
...see above.
Hey there @voodoomatz . Don't worry, we all have stuff to do, and i'm gratefull that you test this when you can .
Now about the bugs. I cannot reproduce 1).
If you had missing data whatsoever, you'd see that in the errors section:
Do you see anything on the server logs?
Regarding error 2) I think i'm pretty sure what's going on. Most likely, if you enable "Always recording in background", the button will work. But in any case, do you see any use for that? Does anybody wants to see the half polar? The truth is that the full polar is mirrored data, but i always though is much more easy to look at, and read visually.
And about the delete polar. Sure, i will add that as soon as i can, probably this weekend