Featherweight tracker Auto updates: WARNING!!!!

[warnerr]

Warning- the featherweight tracker systems autoupdate! There is no “THIS IS NOT A GOOD TIME” option! Despite updating all my featherweight trackers TWO DAYS BEFORE LAUNCH i was forced to accept an update while Rocket was assembled. I did have good data reception so didnt think it would be a big deal... sat there cussing the UNWANTED UPDATE but glad it was installing ok. Or so i thought! The short version is it did not work. (as it turns out a reboot is required, and i believe a rescan of devices to get it working correctly). IF I HAD NOT HAD MY TRUSTY EGGTIMER GPS ON BOARD AS A BACKUP THIS ROCKET WOULD HAVE BEEN LOST! We all know things go wrong and thats why we have backups but this FORCED UPDATE (no option to say not now) is poorly thought out.

 

[KenRico]

I just read the other thread , the manufacturer is not concerned .

He said I think it will be ok when the app makes it to the app store & you shouldn't have had an issue , because if their is enough connectivity to say an update is due it should complete.

No advisory needed, although Mark lost his (and probably a rocket, chute, altimeters, motor hardware and retainer) & your rocket would have been lost too if you did not have redundant tracking -- but as he said you or the others who had to delete the app and start fresh shouldn't have had to reboot .

Kenny

 

[warnerr]

The update DID COMPLETE SUCCESSFULLY. When recovered i very carefully remove the featherweight tracker out of the nosecone to check its status. I was ON. No updating data. At that point i cycled power. i hit scan devices on FIP and it resaved all settings- possibly some new items. IT WAS PERFECT AFTER THAT.

 

[Adrian A]

Ken and warnerr,

Any time a customer has a frustrating or disappointing experience with a Featherweight product, I'm concerned, and so is Kevin. We are doing our best to make the experience smooth and easy, while continuing to add the features and capabilities I have been promising for a long time. That means that there will continue to be over-the-air (OTA) updates to the app and to the tracker and GPS firmware for the foreseeable future. I agree that if you update your system to the latest software 2 days before a launch, that build should be o.k. to continue to use. I thought that was the case with our recent updates, so I'd like to understand more about the specifics of what happened to you. When I get my updates from Kevin, I install them via the TestFlight app, and I'm in control of when that happens on my phone. A side effect of releasing the updates through TestFlight is that each build has a 90 day expiration. We generally push out builds every few weeks, so there is plenty of overlap where the latest build will always be good for at least few weeks before another update becomes necessary. There was an exception to this when we had a long time between builds a couple of months ago (hopefully the only time this happens), so I wonder if that is what you ran into or if it was a more recent problem we need to understand.

When we put out a new release, our goal is that you shouldn't need to restart or re-install the app, or power cycle any of your units. It's possible there will be an update where that is necessary, however. For example, over this past weekend I made an improvement to the way the GPS time is used to synchronize the LoRa transmissions, and this involves changing the commands that the tracker sends to the GPS during power-up. Your feedback reminds me that it's important at the end of the OTA update to get the GPS re-started with the new configuration without power cycling it, if at all possible. If I can't find a good way to do that, I'll see if I can put in a warning that pops up during an update a power cycle will be necessary.

Kenny, I'd like to know more about the lost rocket incident with Mark you briefly mentioned.

 

[OverTheTop]

Managing updates is something I have emphasised with the university team I am mentoring, so I'll let you in on it too . As part of my launch preparation I update all firmware and programs (Altus Metrum) and also run all the OS updates (windows) on the relevant equipment two weeks prior to launch. I don't allow updates after that, until after launch. Actively manage the updates or they manage you, which is not a good situation.

I have been in the middle of a field with windows saying "Updating", PC running on battery and rocket on the pad for 40 minutes. Not happy. It was one of the major windows updates that presented itself very inconveniently in this case.

 

[warnerr]

Thanks Adrian. Overall I really like the featherweight gps. This was specifically an unwanted firmware update- not Fip. The change you described about Lora modifications sounds like the issue as it was powered up and mounted in the nosecone. An option to pause all firmware updates is needed- and is especially an issue on flydays: typically Fri,Sat,Sun. I understand the developer timeout issue until you submit to the store. Most of the time a check before launch should take care of this. Hopefully you will be submitting soon as you guys have done a great job getting this great locater out.

 

[Chris_H]

I have been looking at this tracking system, it looks cool.

Auto-update is a total deal breaker, though.

 

[SDramstad]

And if you can put out the updates on a Monday or Tuesday would be a great idea so when we test things a day before flying (most all of my flying is on the weekend) we will be ready for the weekend. Put one out on a Friday or Saturday will cause lots of problems.

 

[kjs]

My apologies for a delay in response - and if any of the updates caused any issues. I'll try to describe the situation where I think we had 'forced' updates and - after seeing their effect - will try to avoid them in the future.

In mid February, we were approaching the 90 day window for the test flight app. The new iFIP build had new firmware in it, and the old iFIP build was about to start showing as 'expired' (not work at all). That release happened too close to the end of the 90 day window to effectively pre-install so I will try to do at least 30 day updates in the future so any build should have ample time to be installed and tested.

At the late February TRAPHX launch, we were testing the 'found rocket' capability. In the course of that, we found an issue that if the tracker was not in two way communications with the GS, a user might think they were fine (they are getting locations from the tracker) but five minutes after launch, the tracker would go into 'lost' mode (stop transmitting on the normal channel and only transmit on the lost channel). This was fixed in firmware and I considered it critical enough that I didn't want someone trying a really high altitude flight and losing comm while it was still in the air... That time, I did update FIP with the new build and firmware and removed the other available builds. This would have caused the unintended effect of forcing an update at the field... but leaving the old build available could have resulted in a lost rocket... no perfect option on that one.

As Adrian mentioned above, we have another update coming up soon. It does fix a case of loss of COMM that affected me for part of my last two flights (both COMM restored before landing) so it would be a highly encouraged update but I will try to avoid a forced update if at all possible.

Thanks! And thank you for the feedback and discussions!

Kevin