First - they never want to use someone else software framework again (an early SW architect decided that would accelerate things but we ended up re-writing almost all of it) and it was all C++ on the satellite. We ran linux with preempt_rt.
We wrote everything from low level drivers to the top level application and the corresponding ground software for commanding and planning as well. Going forward, we're writing everything top to bottom, just to simplify and have total ownership since we're basically there already.
For testing we hit it at multiple levels: unit test, hardware in the loop, a custom "flight software in test" we called "FIT" which executed a few different simulated mission scenarios, and we tried to hit as many fault cases as we could too. It was pretty stressful for the team tbh but they were super stoked to see how well it worked on orbit.
A big one for us in a super high resolution mission like this is the timing determinism (low latency/low jitter) of the guidance, navigation, and control (GNC) thread. Basically it needs execute on time, every cycle, for us to achieve the mission. Getting enough timing instrumentation was tough with the framework we had selected and we eventually got there, but making sure the "hot loop" didn't miss deadlines was more a function of working with that framework than any limitation of linux operating well enough in a RTOS fashion for us.
Moving fast to make launch, we had missed a harness checkout step that would’ve caught a missing comms connection into an FPGA, and it was masked because our redundant comms channel made everything look nominal.
On orbit, we fixed it by pushing an FPGA update and adding software-level switching between the channels to prove the update applied and isolate the hardware path — which worked. Broader lesson, it is possible to design a sw stack capable of making updates to traditionally burned-in components.
> it was masked because our redundant comms channel made everything look nominal.
Hah, this has bitten me often enough I check for it in test suites now - ok, you’ve proven the system works and the backup works, have you proven the primary works? Another in the long list of ways you don’t expect a system to bite you until it does…
I'm just saying that if they use a traditional IP VPN over the Internet, traffic is of course encrypted, but the two endpoints terminating the VPN must have a public IP.
Of course, this is not necessary if they simply use UHF radio signals encoding bits with pulse modulation, or whatever.
Indeed, that's indeed what I was curious about (Internet vs other channels), since at least part of their tech stack in orbit is relatively straightforward (e.g. linux with preempt_rt).
Why would you VPN here? If you did, why would you do so over the public internet? You can route IP packets over internal links, including via radio (that is the entire point of WiFi after all).
Although it occurs to me that "does your network stack employ either ethernet or IP (and what were the considerations)" might be an interesting question.
Let me dream about the one guy working remote for a satellite company and just jumping into a direct VPN with a satellite, won't you? :)
All kidding aside, there are some protocols, like FTP or RTSP, which don't play well with NAT because they include IP addresses in the payload itself. Some solutions exist (so called ALG) but they are often fragile. If the satellite was using some of these protocols to talk to something on a public cloud platform (say, send images via FTP to an EC2 VM), satellites could have a public address to avoid NAT issues, and that point you could also use it as a management address (although maybe only as a backup path).
It's a bit far fetched, but when it comes to satellites, you could say "sky is the limit" :)
Ignoring for a moment the fact that Grafana could be self-hosted or in SaaS, Grafana is heavily used to collect logs and metrics from standard servers.
Of course, maybe they built their own integrations to convert raw logs and metrics sent via plain pulse modulation to plain syslog and Prometheus metrics, but maybe it's just that they're using (probably private) IP addresses on board and they are simply streaming logs and metrics to the ground using standard TCP/UDP protocols.
Meshtastic has a reliability problem. We often cannot get beyond one hop - and our network isn't too loose nor too dense (60 stations).
Cross test with Meshcore doesn't show any issues. Chats over 5 hops have almost a 100% success rate.
Long time I avoided MC because of its closed source client - but a Opensource Flutter app for Apple/iPhone is slowly getting usable and stable. (https://github.com/zjs81/meshcore-open)
Honest question, as I've just recently started fiddling with Meshtastic: could it be that the mesh is not set up correctly for a dense environment? (e.g. using LongFast rather than MediumFast, or not having more nodes configured as client_mute?) I know the conditions may be wildly different, but just as an example, the guy in this video says he saw no big issues on a hamvention with 300+ nodes: https://www.youtube.com/watch?v=aBfHAPpjtk4
The nearest Meshtastic and Meshcore nodes to me are 20 km away over hilly granite terrain.
Anyway how would either network fare in the Iranian situation where the authorities are actively trying to shutdown communications? Sure the authorities could simply flood the network with traffic.
The decision that every station is always a (delayed) router was a bad one. Also the old firmware was super chatty eating a lot of valuable ISM TX time.
They must clean up their role mess and switch to a "all clients are totally quiet - until they are set to a different mode for a reason"-strategy.
Eh, Meshtastic was originally for sparse off grid comms less than big public networks. In that role (which is still what I mostly use Meshtastic for) every client repeating messages makes more sense.
All Semtech LoRa modems are wide-range modems. You can switch to basically every other frequency.
An idea would be to move to SX128x modems with work around 2.4GHz. You recycle Wifi-gear for directional stuff. This also enabled you to hide below Wifi traffic.
With tiny solar repeater that placed on a strategic hill you can cover lots of kilometers. Being sensitive down to -145dBm opens a lot of doors.
I was able to build energy harvester nodes that fit into 5cm x 5cm x 4cm boxes that roughly cost around 20€. Without energy harvesting capability with a normal TI BQ wide range charge controllers (that stuff costs $1.5-2.5@pcs and eats every power source up to 18V! With pseudo-MPPT!) you can bring the entire thing down to <<15€. That's mass producable throw-away stuff.
Currently available LoRa-gear is either USB-power optimized (looking at you Heltec) or just awfully overpriced as soon as a solar panel is attached to it.
You also make yourself a bright shining beacon to anybody looking for a resistance network because Lora operates on very specific frequencies. It would be easy to spot you with an RF scanner.
Obviously, put that relay node on a hill, on some structure where you don't live. Or maybe on the roof of your tall apartment building, among all the satellite dishes and their associated boxes. Pretend to be one of those.
If it's a self-contained, solar-powered node, it needs not be next to you, or to anyone. It should be safe and secure, to be of use during a natural disaster, or an outburst of violence.
Until you actually need to use it. You need to get the data you want to transmit over to it. Where you'll either have another transmitter at your location. A cable snaking back to your location. Or a directional antenna pointed at your location.
Unless you plan to manually go up the hill with a flash drive each time.
Any licensed wireless networking gear is going to operate in very specific frequencies. The government requires it! If we were going for "the best" gear for avoiding detection you would have frequency hopping with jumps far enough apart that a listener has a harder time pinpointing a transmitter. Making repeaters roving makes it even harder for your adversary.
The same government can trivially make these frequencies completely unusable by just blasting noise across all the ISM frequency bands. As far as I read, it is already happening in Russia, making LoRA anything but long-range...
I guess if you're protesting against the government, you don't have to comply with regulations and can use more power and basically the entire spectrum :)
If you have the government as adversary and no military force to back it up, you might want to reconsider doing that as it makes you very detectable from far away.
And instead of "just" getting teargassed and sent home, you get thrown to a concentration camp for organizing communications for the domestic terrorists there to overthrow the government, attack ICE, <insert whatever you want here, something you're pro- or against>.
Stacks? Testing? Firmware Updates? Programming languages?
Thank you!
reply