I don't have an immediate answer for you.. but I can let you know about "gopro-layout.py" - The job of this program is to help you experiment with layouts. You just give the program the gopro file, and your layout file. Then each time the layout file changes, it will just render one frame. You can open this in a file viewer. Most of them will reload the image file when it changes, and so you can get "live" changes...

Thanks, thats very usefull!! I am use it and try to create auto/moto Dashboard..

As I thought, acceleration wasnt an issue (didnt test brake "negative" bar 0 ... -1 though yet), and the layering is done simply by order of widget in xml, no issues there.

But unfortunatelly, I dont know, how to make prettier Speedometer (like that one from Dashware).

• I cant find any option to hide/make transparent parts of asi widget (to get rid of needle, background, ranges etc.)
• I cant find any option to make numbers on cairo-gauge-round-annotated wider and more spaced from ticks
• I cant find any option to change size/diameter of cairo-gauge-marker (to place it carefully to the outter edge of round gauges, to not interfere with informations.

P.S.: Some widget parameters have option to change count (like ticks), but it cannot be set to 0 (like disable them - that leads to dividing by zero). So, you must use vne parameter for asi widget etc. If would 0 (or false, etc.) disabled that part of widget, that would leads to more customisation options.

Similiarly, in zone-bar, when unit is G, there is no point to restrict values to Int. Much more usual values would be there 0.1-0.5 for better graphical scale of zone. Workaround would be use another units, but still, when G's are available, it would make a sense to have option to use float min/max values

I use asi as template to create msi, and I think I am close enough with speedometer.

Only major thing missing is correctly bars for graphic representation acceleration and deceleration.

Hiya - @JimmyS83 - thanks for all your emails! I think it might be best to add them here in preference to email though, unless the content is private (like gpx/mp4 files for instance) - as its just much easier to manage the communications here.

I found GoPro x/y. accl not much realiable. And knowing, that Dashware renders same gpx (its not even needed to use GoPro video, but just relativelly small, bare gpx file) with nice Throttle / Brake bars, I start thinking, whats different here.

Difference between using gopro-dashboard and Dashware, regarding Throttle/Brake could be seen here:
https://streamable.com/89x1sd - https://streamable.com/2p53bj

After some digging I found, that although using ACCL would be possible for Dashware also (I assume, as its developed by Gopro), even when using just bare gpx as input, not Gopro video, it calculates and interpolates Acceleration basically from GPS lat/lon + time, and it works very nicely:

It calculates own helping measures from simple gpx

into values, which is used by gauges like:

So I wondering, interested just about Throttle / Brake gauge, where it comes. It turns out, that gauge use "GPS AccelGs" variable. The chain, how its gathered is:

GPS-Based Acceleration Calculator -> RawGPS --> Linear Interpolator -> InterpGPS --> Averaging Calculator-> GPS AccelGs

where

1] GPS-Based Acceleration Calculator: Determine acc. and lateral G-Forces based on GPS position movement over time.

2] Linear Interpolator, used to fill in empty values with interpolated values (interpolated between the last non-empty value and next non-empty values)

3] Averaging Calculator, used to smooth data sets by averaging using previous and/or future values.

So I am thinking how to do the same within gopro-dashboard, which has own meters available. It already has cspeed as fallback where speed is not available, so it could have also "caccel", also calculated from GPS and time I thought.

I could find some formulas to do 1]. But I am guess, thats really dont needed, because gopro-overlay already counts speed, right? So, if we are interested just acc/dec, then we can use simple formula

a = Sd / Td

where Sd is speed difference between two measure points, and Td is delta time between them. (https://www.omnicalculator.com/physics/acceleration)

This should calculate raw data, which would be optimally went through 2] 3] to better graphical interpretation (I found 2] very usefull, for brief quick small GPS NO LOCKS + using charts, 3] is already implemented in some way I guess).

I tried to make some very rough POC (I am not familiar with gopro-dasboard much, regarding gathering and interpolating data), using just

 if a.speed and b.speed and time:
            accel = (b.speed - a.speed) / time
        else:
            accel = units.Quantity(0, units.mps)

within calculate_speeds() @timeseries_process.py (not sure, where fallback from speed to cspeed happens, and also I am not sure if points are from gpx or GoPro data, but just for test..).

Seems that (calculated) acceleration copies speed much better than accl.x/y (and it doesnt needs ACCL data as bonus), but timing seems to be a little off, as accel would be ahead of time.

https://streamable.com/3qbcxu

Any help appreciated :)

Thanks for this. Video looks great. - if you are ok.. then please do make a PR, but I will probably just take the commits from it rather than merge it as a PR, or maybe take the concepts and make something that works the same way. The PR is useful as it just makes a nice way to see a diff. Thank you!