Maybe the Hall effect thruster was stuck in the other engine location, or the materials they are testing for 'NASA' are TPS mounted external to the vehicle.That or they supper pimped it....
Here is something interesting, a sub-contractor for the flaperons and ruddervators mentions a 4th flight unit, now I assume its a 4th set of flaperons/ruddervators, or could it be a 4th X-37B ? .....nahhh http://www.lx3.net/development-manufacturing-x-37-space-plane-flaperons-ruddervators.html"Currently on DQ4 (4th Flight Unit)"
Software Glitch Pauses LightSail Test MissionJason Davis' blog on The Planetary Society web site, posted 2015/05/26 21:35 UTChttp://www.planetary.org/blogs/jason-davis/2015/20150526-software-glitch-pauses-ls-test.htmlAn informative read.One recovery method is waiting for a cosmic ray strike on electronics to cause a reboot.One of the commenters asked why the .csv beacon file overflow > system crash failure mode wasn't caught in the design or ground testing phases?Once a reboot occurs, they plan a manual sail deploy ASAP.Zubenelgenubi
Quote from: zubenelgenubi on 05/27/2015 03:40 pmSoftware Glitch Pauses LightSail Test MissionJason Davis' blog on The Planetary Society web site, posted 2015/05/26 21:35 UTChttp://www.planetary.org/blogs/jason-davis/2015/20150526-software-glitch-pauses-ls-test.htmlAn informative read.One recovery method is waiting for a cosmic ray strike on electronics to cause a reboot.One of the commenters asked why the .csv beacon file overflow > system crash failure mode wasn't caught in the design or ground testing phases?Once a reboot occurs, they plan a manual sail deploy ASAP.Zubenelgenubiwow. Very poor s/w testing process there. Scary that their only "hope" is a random cosmic ray to zap it into a restart.
Haven't heard of any sightings of this supposed "X-37B" so far. - Ed Kyle
Quote from: kevinof on 05/27/2015 04:25 pmQuote from: zubenelgenubi on 05/27/2015 03:40 pmSoftware Glitch Pauses LightSail Test MissionJason Davis' blog on The Planetary Society web site, posted 2015/05/26 21:35 UTChttp://www.planetary.org/blogs/jason-davis/2015/20150526-software-glitch-pauses-ls-test.htmlAn informative read.One recovery method is waiting for a cosmic ray strike on electronics to cause a reboot.One of the commenters asked why the .csv beacon file overflow > system crash failure mode wasn't caught in the design or ground testing phases?Once a reboot occurs, they plan a manual sail deploy ASAP.Zubenelgenubiwow. Very poor s/w testing process there. Scary that their only "hope" is a random cosmic ray to zap it into a restart.Agreed. Testing boundary conditions (such as the maximum size of a file) is pretty common in software engineering/testing and computer science. They do teach you about that stuff, at least with my CS degree it was very common, we had to have all sorts of checks in our code. I'm surprised/shocked that this wasn't part of their testing/checking. Sounds a bit like they trusted/relied a bit too much on the supplier of the original software.Darren
The other method to accomplish reboot is sending a reboot command from either the Cal Poly or Georgia Tech ground stations. Multiple attempts over the last few days have not (yet) worked. (It's in the article.)
wow. Very poor s/w testing process there. Scary that their only "hope" is a random cosmic ray to zap it into a restart.
Quote from: edkyle99 on 05/27/2015 04:09 pmHaven't heard of any sightings of this supposed "X-37B" so far. - Ed KyleApparently from prior comments read elsewhere it's not the easiest of vehicles to find.
Quote from: kevinof on 05/27/2015 04:25 pmwow. Very poor s/w testing process there. Scary that their only "hope" is a random cosmic ray to zap it into a restart. Most likely comes down to money. constrained time for SQA.Sounds like they didn't have the time and money to test the system for extended periods before flight. A clue is in the hope for a cosmic reset before the flight ends. The reason is most likely it is not a rad harden embedded system. They expect resets and built the system to deal with and handle them.Raise your hand for how many times you tested something, had it pass SQA, get released to the wild, and then found the SQA test didn't cover everything and had to issue a fast patch. I would raise my hand, but I don't have enough
I've worked with the same flight computer board and we encountered the exact same issue (before we were on orbit). The manufacturer of the board is awful with documenting issues and their revision control is extremely poor (at least as presented to the customer), so this does not surprise me - even though we encountered this issue about 18 months ago. We actually ended up dumping this board because of issues like this.This also shows the importance of having a hardware watchdog timer - automatically resetting the computer if it doesn't issue a command within a certain interval. I'm actually surprised that they did not include a hardware watchdog on the spacecraft - even in cubesats, it's an encouraged practice.