Could I ask you to clarify why avoiding safemode is so important? In a non satellite system safemode means everything is driven to a safe state which is fine during testing in the lab.
Also do you not run these tests in an even more simulated environment where there is only the flight computer and no real hardware at all?
Having discussed this same question with the more experienced members of my team, the only conclusion I can draw is that the customer (US Government) is incredibly risk averse. Any unexpected entry into safemode would require a report, multiple meetings with the customer, and them being pretty angry. Their line of reasoning seems to be "Safemode->Something is wrong->Why is something wrong? We're not paying you to be wrong". I'm personally of the opinion that safemode isn't that bad. It's fully recoverable and shows the system is working properly.
We normally have a Functional Test Assembly (real computer and some other hardware for testing) to run our tests against, but we only have one setup and it is consistently unreliable. This particular CLT was unable to get a clean run in the lab but it was decided that the issues were related to the lab setup rather than the actual test, so we moved forward to run on the satellite (against our team's protests).
This to me is the real crux of the issue: if we can't even trust our own testing environment, what's the point of having it at all? If the customer is so risk averse, why would we take this chance? Needless to say, I don't think we'll be running anything on the satellite without full FTA vetting anytime in the near future.
> Any unexpected entry into safemode would require a report, multiple meetings with the customer, and them being pretty angry. Their line of reasoning seems to be "Safemode->Something is wrong->Why is something wrong? We're not paying you to be wrong". I'm personally of the opinion that safemode isn't that bad. It's fully recoverable and shows the system is working properly.
To the last part first: Good that safe mode kicked in and did the right thing, but now what? What caused it to enter safe mode in the first place?
That's why they care when it happens. If they don't know why it's entering safe mode, they can't correct the actual problems in the system.
"Safemode is when all non critical functions are automatically shut down and the satellite becomes entirely focused on generating power by pointing its solar panels towards the Sun and trying to reestablish any communication that was lost."
The non-critical functions are all the things the customer actually bought the satellite for. Cool that it's still alive, but now the Space Internet / death lasers / etc. are offline.
There are faults IDs that trip if certain telemetry goes outside of a normal range. If a safemode were to occur, we would investigate which faults tripped and at what time, and use those to construct a "story" of what happened on the satellite before it entered safemode. We're also constantly recording every telemetry that comes down, so we could reference any telemetry we wanted as far back as months in the past.
To your point, yes you're correct. The cause of the safemode is much more interesting than the fact we entered it.
> We normally have a Functional Test Assembly (real computer and some other hardware for testing) to run our tests against, but we only have one setup and it is consistently unreliable
Its interesting to see that someone with a 2B budget have the same problem as someome with 5 million budget... we have an engineering model for our cubesats but its flaky
Battery life is based on playing a 720p video file so most of the expended power will be in the video decoder and screen not the actual CPU. It's also dependent on the battery size in the laptop being tested so pretty much impossible to compare on any like for like basis.
CPU to be sure. However, low power video decoders are really nothing new for Intel or AMD.
Also, the codec being decoded matters a lot. H.264 is trivial to decode at this point while something like AV1 will require a bit more power to decode.
Spot on. Why not use any more or less standard cpu benchmark? The publication is either being strangely incompetent at this, or deliberately misleading.
The correlation may be just above what the author thinks is significant but eyeballing the data I would say the effect size is simply too small for there to be any meaningful conclusion taken from it.
Pulse width modulation works just as well if the pulse width is short compared to the overall cooking time. And not having an inverter makes it more efficient. Unfortunately lots of cheap microwaves have a pulse width which is more than 10 seconds, presumably to help lifetime reliability, but means that for cooking times less than a couple of minutes it doesn't work well.
I once used a very expensive wolf brand microwave that would always run the magnetron for at least 10 seconds regardless of the power level setting. So if you set it to do 10% power for 10 seconds it would actually do 100% power for 10 seconds. I'm kind of shocked that their QA didn't catch this, if nothing else it should refuse to run at reduced power settings for times under ~100 seconds.
Great toy but it's a bit misleading not to touch on the query planner. All real SQL implementations will plan how to most efficiently run a query so the order of operations can be wildly different to expected based on the data and indexes available. This kind of tutorial makes it look like joins are very inefficient whereas a real database may make them highly efficient for a given query.
I think they have linked to the wrong paper. This paper https://cseweb.ucsd.edu/~schulman/docs/oakland24-phyobfuscat... more closely matches the article and it explains that the obfuscation is possible due to the TI CC2640 having a variable frequency synthesiser which has 16 bits of resolution. It's a clever technique but I'm not sure it is easily implemented on other chipsets. And this is only valid against one fingerprinting methodology: carrier frequency offset (CFO), there are other fingerprinting techniques which are more difficult to defend against.
There are many flaws in the paper's approach. There is much literature on this already, it has been investigated for decades. Much of the fingerprinting used comes from non-linearities in the RF power amplifiers, not the frequency.
Most Bluetooth being GFSK means the TX chain is completely non-linear to begin with, so the frequency error is an easier target for fingerprinting.
That said, most also have ramp-up and ramp-down slopes on the transmission start and end to control and shape the spectral emissions.
So there might also be something to that.
Still a harder thing to fingerprint than frequency errors relating to transmit center frequency and baudrate.
The US DOT publishes "Mishandled Baggage" statistics. These lump together lost and damaged, but for example states that Delta was around a 1 out of 256 chance to get "mishandled"... so, I'm not sure if the stats on this page are really all that far off - they seem all within the range of believable to me.
It says it is normalized against actual published lost baggage statistics.
You can calculate a ratio of social media complaints to lost bags for airlines you have data on and then infer a loss rate for airlines that don't release data.
Someone can just create a Twitter account, tweet that $airline lost their luggage, and skew the statistics.. considering there's some magic maths in the background...
Let's be honest, how likely is that going to happen?
"There's 102 people who die in a car accident everyday. Someone could have just been struck by lightning while driving and skewed the statistics so that number isn't entirely accurate"
It sounds like the sampling clock frequency is not what is expected (but that's quite easy to check based on the transmitted signal so I'm quite confused)
UARTs are nice if you are constrained on pins but SPI is always a safer bet where you don't have the necessary high accuracy clocks.
I had something like that 30 years ago on a Motorolla 68332 processor.
It could generate the high speed CPU clock using the 32khz clock as a reference. What I found was the layout guy ran a digital trace through the pins of the 32khz xtal. There was enough coupling that digital transitions on that line would cause the high speed clock to swing wildly. Which showed up as garbage on the UARTs. Joyous thing is most of the time that line was idle.
I cut and rerouted the trace and the problem went away.
My guess is that the receiver clock glitches in some way when the MSI auto calibration runs, but it never showed up on the transmitter (and the device on the other side of the connection has never had a reception issue).
I ended up disabling the auto cal feature during a UART reception and then turning it back on when the reception is done.
SPI is definitely better as far as clocking, but MCU support as a SPI receiver is sometimes a lot less convenient to deal with.
A lot of UARTs have a synchronous mode which adds a dedicated clock signal - I've used that before out to a couple MHz.
In this application though, I'm only running 1 MHz so I really didn't think I should need a separate clock (and, it turns out, still don't).
According to the documentation there is no calibration as such, the MSI clock simply runs in a phase locked loop (PLL) configuration with LSE (32.768 kHz). For example in 1MHz mode the MSI is setup to run at approximately 1Mhz, this clock then goes into a downscaler which downscales by a factor of 31 to approximately 32kHz and this is compared to the LSE clock to generate feedback for the MSI clock. When locked the MSI runs at 1015.8 kHz (32.768 * 31) so out by 1.58%.
It's also possible that the design hasn't been thoroughly tested and the PLL doesn't lock in certain conditions which could leave you with an unstable clock.
If you really need the accuracy then regularly time the LSE clock using a timer clocked from MSI and apply the best trim values as described in this app note file:///home/tom/Downloads/an4736-how-to-calibrate-stm32l4-series-microcontrollers-internal-rc-oscillator-stmicroelectronics-1.pdf
It's been forever since I used UARTs but I remember them being fairly resilient creatures. They center on the start bit and so as long as the clocks are close enough so you can sample the rest of the bits you should be good. Often the problem is configuration and not clock accuracy, e.g. how many stop bits or parity.
Also do you not run these tests in an even more simulated environment where there is only the flight computer and no real hardware at all?
reply