(again, moving this to the developer mailing list where I think it belongs)
> On Aug 28, 2018, at 12:17 PM, Wojciech Więckowski <[email protected]> wrote: > > I just returned from vacation where I had possibility to supplement some > missing events in my FIT files. I mean – forcing the alarms, violating MODs, > breaking ceilings, etc. Nothing harmful of course... I just love that statement... "violating MODs, breaking ceilings" ... "Nothing harmful" I assume and hope that you did this by giving your dive computer incorrect information about the gases that you were diving with :-) Also, did you get a chance to simulate gas changes? > I dived during the day and trying to find some time to code and analyze FIT > files at night. The effect is quite obvious - a lot of new information > gathered and a lot of chaotic code written. I know exactly how that feels :-) > I wanted to hardly refactor the script before showing it in public. > Especially because current idea (collect the data and update Subsurface log > on the fly) is stupid and causes a lot of conditional code. Additionally this > is only temporary solution, created for my own needs, before support for > Garmin is ready in Subsurface. > > Today’s activity in this thread convinced me to share the code as is. Some > developers may found interesting conditions in function “message_processor” > as it contains all known for me, reverse engineered Garmin records and fields > I needed to use. Excellent. Thank you! > But after all - my script imports data from multiple fit files at once, > creates new Subsurface logs or updates existing, supports sites, computers, > cylinders creation, consolidates sites using defined radius around GPS > coordinates, can include apnea dives, filters out dives shorter than defined > time, lists FIT files summaries (to easy pick interesting ones), contains a > lot of already recognized events… > > Some extra data I had no chance to treat other way is imported to Subsurface > Extra Info tab. The most important one for me is gradient factor setting that > can be set per-dive in Garmin but only globally in Subsurface. It's globally set for the calculation that we do when you display the calculated ceiling. We do report the GF used by the dive computer in extra data if that information is available from the dive computer (and if we know how to parse it). > FIT is flexible and has consistent API. Unfortunately Garmin writes there a > lot of data that is not documented. For instance, the last problem I had to > resolve was time offset [s] stored in ‘device_settings’ message. It is > required to calculate local time as internally Garmin uses UTC time. It > turned out that it’s signed integer stored in uint32 field using “two's > complement” format. I had to do a lot of tests before I recognized it. That's the bread and butter of reverse engineering dive computer data. The Oceanic format where the bits for certain values are seemingly randomly distributed across multiple bytes appears to be one of the worst in this context... > Once (not for the current version) I tested the script also under Windows > using python 3.7 and it worked fine. Among others, for this purpose there are > a few changes in the code to substitute missing shell-level file wildcards > expansion when called from shells as crippled as CMD. > > If someone’s interested, please look at this repo: > > https://github.com/xplwowi/fit2subs > <https://github.com/xplwowi/fit2subs> > You will find there also postulated source FIT files with GPS and diving > activities inside. That is outstanding. Thank you! /D
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
