Corrupted SET file - Oregon 750 - loadProperties?

I've got a user who seems to be having problems with the settings file getting corrupted.
The steps they're doing are:

download Simple datafield
field works OK with default settings
update & sync settings via express
settings retrieved all null

After using the user's SET file on my 735XT & Edge 820, it does indeed retrieve null values.

Does anybody know how to debug this, or the SET file ( i compared the hex but couldn't see anything obvious, i assume this is some kind of serialized c object?)

I currently don't use loadProperties, but I was thinking if this is an old 1.2 SDK device it may require it (although, that wouldn't explain why their SET wouldn't work on mine), but then again i'm clutching at straws now!

Any tips would be appreciated!

jim_m_58 over 8 years ago

The current FW for the Oregon has 2.x CIQ. I guess the first thing I'd check is what FW the user has, as well as making sure they are using the latest Garmin Express. I know the latest FW works fine with doing settings with Garmin connect mobile.

Maybe post your properties and settings xml file. Is it ALL keys that are null, or just some of them?

djhawley over 8 years ago

The current FW for the Oregon has 2.x CIQ. I guess the first thing I'd check is what FW the user has, as well as making sure they are using the latest Garmin Express. I know the latest FW works fine with doing settings with Garmin connect mobile.

Maybe post your properties and settings xml file. Is it ALL keys that are null, or just some of them?

thanks for that!

We've managed to debug it a bit further and they're using 3.10, which is the latest version which is good, and 2.90 added support for Connect-IQ version 2.2.3.

Oddly it works ok with garmin express. But 'corrupts' when settings are edited with connect mobile on their android device.
So I've left it with them to raise it as a bug with garmin and hopefully they'll get a resolution

CloggyAbroad over 8 years ago

I have just encountered a similar issue on a 935. I am well aware of item #10 in the New Developers FAQ sticky and made sure that I followed the instructions provided there for numbers, but it turned out my issue was caused by a float (a calibration factor in this case) I am storing in properties. Worked fine when I updated through GC, but after changing the value on GCM (Android) the app crashed on start up. I could then 'fix' the properties file by opening and saving them using GC on my PC and it would run ok again.

What solved it was to use rCalibrationFactor = app.getProperty("CalibrationFactor").toFloat(); After that all was fine. Could this sort out your issue as well?

travis.vitek over 8 years ago

The FAQ doesn't list all of the possible scenarios. I know there were issues with both Number and Float coming back as Strings, which caused all sorts of headaches.

travis.vitek over 8 years ago

The FAQ isn't complete. I know for a fact that both Lang.Number and Lang.Float are affected. You should code your application to ensure the data is in the correct type when you get it back from the object store.