> On Sep 4, 2018, at 6:11 PM, Linus Torvalds <[email protected]> > wrote: > > On Tue, Sep 4, 2018 at 4:38 PM Linus Torvalds > <[email protected]> wrote: >> >>> - in the FIT file, the Descent Mk1 is identified as product 2859; I think >>> this would >>> make sense to use as model number (instead of 0) >> >> I'll take a look. > > I took all your commits. Minor changes, like not checking that > device_index, because it actually changes *after* you've already seen > the values.
As you have seen, there are several devices inside your Garmin. device index 0 is the whole device, it has no device type device index 1 is the <I have no idea - device type 4> in my case it happens to have the information as index 0, which is why my code happened to work device index 2 is the <I still have no idea, device type 3>, no serial, no fw version device index 3 is of device type 8 and has again no serial, but fw version 30.45 etc Clearly we need to use the device_info message that is for the correct device_index. So no, I don't think we can ignore this. > The garmin field numbering is confusing. For example, device_index is > indeed field #0, but it's not the first field in the record stream. > It's one of the last fields because it's a small one-byte field. > > So when the FIT file stream is parsed, you will see things in this order > > first DEVICE_INFO message: > - firmware field > - device index: 0 > > second DEVICE_INFO message > - firmware field > - device index: 1 > > so when you checked "is device index 0", that check triggered for both > of those firmware fields, because the device index updated to 1 only > _after_ you'd seen the second firmware field. > > I could have done it the "proper" way with actually batching it up > using the record_data thing, but it seemed unnecessary, and I just did > that "only overwrite firmware when the old number was zero". > > Which isn't necessarily the technically proper way to do it, but it > gets the right result, and we get the firmware field details from the > first/main DEVICE_INFO message. But that makes the assumption that the first DEVICE_INFO message that you get is the one for device index 0. Now that I understand better how this works, I'm not sure I like that assumption all that much, either. We really SHOULD do this in the record_data function. > Of course, the serial number and the product data we could have just > gotten from the FILE message, which only happens once. But that one > doesn't contain the firmware information, and yeah, the firmware field > has different values for the different device_index values. I don't > know why, but at least now it takes that first one. I'll play with this some more, but I may send you a follow up commit to make sure we really grab the info from device index 0. Thanks for merging - I will update the submodule now because at least with my FIT files the current code happens to work :-) /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
