Stuff for GSM/CDMA has been around for years, OpenBTS is the primary example. This is the first I've heard of anything more modern/complicated being implemented. From my understanding, a lot of the hard eng work is in the RF frontend and making it small/low power enough to fit in a phone for example. OpenBTS got around this by using existing SRDs for their RF frontend.
Working in the government space sector, generally speaking, you're given a mission lifetime which is seen as a minimum. your payload/spacecraft/instrument needs to last at least this long. some things end up being limited by the physics of the system (See the RTG on the Voyager probes for a common example, or CEMs on plasma spectroscopy instruments for a more obscure example). However, in pretty much all cases where the physics doesn't put a hard cap on the thing you're building, nobody wants the thing building to be the first thing, or critical point of failure of the whole system.
jval43's quote puts it pretty well. It's not just that you're designing something to last, you're designing it not to fail. It also tends to help when you have a bunch of really smart folks from a number of disciplines working on the same problem.
With that said, you need to walk a fine line as far as the level of redundancy and fallbacks you put in place versus the overall SWaP (Space Weight and Power) of the system. I can go somewhat deeper into SWaP issues if you would like.
I can't seem to find a reason for shutting it down in the article. Does anyone have info on this? Was it for budget reasons or was their a failure on orbit?
As someone who specializes in the type of low level systems that are still built in C, C++ is considered high risk let alone rust. That is largely the reality of the industry. Some co-workers and I hope to introduce C++ as an experimental project next year. We also have some data processing code written in C++ that we would like to integrate as is. The reality on the ground is that C is often used over C++. ¯ \ _ ( ツ ) _ / ¯
How about the subset of simple classes, RAII, basic containers(vector, map, duque), single inheritance, overloads for type safety/less casting, stronger casting features, references. Things that c programmers can pick up quickly and use in both c-style and c++ style? That’s what we do and it works out well our embedded. There are a host of embedded STL libraries to let you do hard limits and checks on containers to prevent “hidden” dynamic memory allocation and the like. Of course you’ll have to depend more on the quality of your compiler’s reputation for the processor, c++ is much much more complicated compiler than c and more apt to have bugs. But we’ve yet to encounter anything that forced us to say “f this generated incorrect assembly because of a compiler bug”
Depending on your field, I can definitely understand the hesitation. It's fairly easy to imagine what kind of machine code will be generated from C, but much harder with C++/Rust.
Is there game for a Rust like native language over a close to assembly procedural language like C? It seems the only thing that makes predictions hard are things like fptrs and their structured v-table organization (which you can roll your own in C if you want, which almost any large project will).
I think fptrs and v-tables are fairly predictable once you know how they work. The main issue is that "good" C++ code makes heavy use of the STL, meaning that you need to know exactly how everything is implemented to understand what code will be generated. In embedded environments there can be strict timing requirements, memory restrictions, etc. That makes C++/Rust a little more scary. You might wanna ban stuff like std::vector because you never know when it will reallocate and double in size. Better to just use dumb arrays so everything is obvious.
You can implement a self expanding vector in C though, so I’m not really sure what you are gaining/losing by using C++, I guess it’s just a matter of standard library, but you can create build rules that restrict what you can depend on in low level code.
The point is that having all these complex libraries and abstractions moves you away from understanding what your code is actually doing, which is not ideal in some domains.
The Ingenuity is a really interesting project with some important lessons for spaceflight with unhardened CotS parts. However, I would argue that it and the Europa Clipper are two very different designs for two very different environments.
While mars is an elevated radiation environment when compared with earth, the Jovian radiation belts are on a whole other level, particles up to 1-2000 MeV are fairly common. To put that into context, a medical radiation beam therapy deals with 2-300 MeV on the absolute highest end. To get into the 1-2000 MeV range you generally are talking about energies found in the low end of particle accelerators. Ingenuity mostly had to worry about Total Lifetime Dose (TLD), one example of a TLD issue is dopant migration induced by high-energy heavy ion collisions which can change the on voltage of a transistor. At high energies you can have single events with enough energy to cause fatal latch-ups. For instance modern rad-hard FPGAs start encountering major issues around 60-70 MeV.
Furthermore, these parts are power MOSFETs which control power for whole subsystems so their reliability is critical to the operation of the spacecraft. In addition, the biggest issue here is not just that there were issues that were addressed and fixed, it's that Infineon didn't issue an errata to the datasheet or inform NASA of the issue. As a result there are now transistors littered throughout the spacecraft which don't meet the radiation needs. This is going to require reworking the boards, re-validation of the subsystem, and re-integration of the subsystem into the spacecraft. This all comes at a non-trivial impact to budget and timelines which is to say nothing about what this does to the launch window the project was trying to hit for gravity assist / proximity.
I ran into this in university and burned a late night writing a simple program. It was a really fun experience that I would recommend people try at some point!
T1D that was also diagnosed somewhat later in life (24), the convenience of having something like a tandem that can buy and large manage my levels, is really nice. I definitely still keep needles around for when I need to do a larger injection, anything over about 20 units in an hour and you're going to have leakage and at that point you need to replace the infusion site.
