“They think we make the attack on each receiver and as soon as one receiver attacks, they try to swap in another receiver and get a signal from another satellite. But when the missile enters the range of our system, we cover all types of receivers,” they said. “It’s physically impossible to connect with another satellite, but they think that it’s possible. That’s why they started with four receivers and right now it’s 16. I guess in the future we’ll see 24, but it’s pretty useless.”
They’re just wasting so much resources and don’t even know what they’re doing. “Just keep putting more receivers, they can’t jam them all… can they?”
the fact that the missile tries to change direction too quickly and just breaks itself apart from the aerodynamic pressure is crazy… it’s literally hobby robotics 101 to put limits on acceleration etc
It’s just the life of each software dev: don’t need to account for this situation, because the target would never move by 10000kms within seconds.
Plus, the buyer would never bring a failed unit back to ask for a refund, so why bother and spend more on development. Unless it’s a liquid fuel rocket, you wouldn’t be able to change Trust and speed once fired.
but any software engineer knows sensors and inputs aren’t infallible … and neither is your code! you apply limits to account for anomalies, which should just be an expectation
the theoretical reason for doing that is that if you have to split jamming power over broader frequency range, then for every n^2 times increase in bandwidth, here number of channels, range decreases n times. however gnss signals are so weak, it probably doesn’t matter, and if you’re adding extra power per channel, then it doesn’t apply
now if missile detects that gnss is fucked with (signal too strong, wrong direction, physically impossible location), the correct thing to do would be to fallback to inertial navigation while accepting that accuracy decreases until gnss can be received again, if at all, and acted upon. theoretically speaking, it’s a matter of software update, better hardware also can help with that, so idk why would they release this. maybe there’s something that prevents this
They’re just wasting so much resources and don’t even know what they’re doing. “Just keep putting more receivers, they can’t jam them all… can they?”
that’s not even the most incompetent part imo
the fact that the missile tries to change direction too quickly and just breaks itself apart from the aerodynamic pressure is crazy… it’s literally hobby robotics 101 to put limits on acceleration etc
It’s just the life of each software dev: don’t need to account for this situation, because the target would never move by 10000kms within seconds. Plus, the buyer would never bring a failed unit back to ask for a refund, so why bother and spend more on development. Unless it’s a liquid fuel rocket, you wouldn’t be able to change Trust and speed once fired.
but any software engineer knows sensors and inputs aren’t infallible … and neither is your code! you apply limits to account for anomalies, which should just be an expectation
Any good software engineer who actually gives a fuck.
the theoretical reason for doing that is that if you have to split jamming power over broader frequency range, then for every n^2 times increase in bandwidth, here number of channels, range decreases n times. however gnss signals are so weak, it probably doesn’t matter, and if you’re adding extra power per channel, then it doesn’t apply
now if missile detects that gnss is fucked with (signal too strong, wrong direction, physically impossible location), the correct thing to do would be to fallback to inertial navigation while accepting that accuracy decreases until gnss can be received again, if at all, and acted upon. theoretically speaking, it’s a matter of software update, better hardware also can help with that, so idk why would they release this. maybe there’s something that prevents this