See also https://en.wikipedia.org/wiki/International_Control_Dam

Take a message we want to communicate and add some additional data that allows recovering the message even if part of it is corrupted. The hard part is choosing what additional data to include to recover from enough corruption with small overhead and in a reasonable runtime.

These are used everywhere from WiFi to hard drives to QR codes to RAM chips -- the ECC in ECC RAM being "error correcting code" and now partially mandatory with DDR5.

One of the authors is at my university and teaches from this book. It's a math heavy upper-undergrad elective course. A couple percent of our students take it, usually in their final year of a 4 year computer science program.

The couple students I know who've taken it did enjoy it. They were also people who liked proof based mathematics in general.

Maybe an issue here is WebSerial, as HCI comes over a serial port device. I believe the OS should block access to the serial device once the host driver takes it as a Bluetooth adapter though.

ESP32 devices not using the Bluetooth adapter firmware are unaffected and already running custom closed source (possibly encrypted) code from the supplier.

Espressif has been an almost unique level of open for this space. They've contributed to open source Rust toolchains for their chips. They've even publicly encouraged reverse engineering of their modem stack because it contains licensed code they can't release. I hate to see bad and damaging publicity be the reward for being just a little bit open.

Undocumented debugging commands like this are common. I've worked with at least two chips, a WiFi adapter and a GPS receiver, that had similar functions. Neither was documented, but found by reverse engineering the chip firmware or vendor drivers. It's not exactly an impactful issue on its own. Anything that allows unsigned firmware is equally vulnerable.

If I'm misunderstanding and this is usable from anything other than the host, that would be a very different story.

Bigger picture, RPi is doing their third ever chip fab. The errata (silicon bug) list for the prior RP2040 is shorter than some I've seen from companies five times their age.[1] This issue isn't a logic error and wasn't going to be found by digital simulation. This is analog weirdness. Their documentation, including of errata, is among the best I (moderately experienced hobbyist) have ever encountered for a microcontroller. RPi is doing an excellent job and this is a but a hiccup. Maybe it's concerning for industrial customers, but as a hobbyist I'm still excited for my Pico 2 to arrive.

[1] Favorite errata warstory: Radio chip will lock up and need to be power cycled if a received packet has a particular corrupt length field, one bit flip away from one we used. Official solution: don't allow packet corruption. Turns out radios don't work like that.

I've ordered one and am confident for anything I'd do it's not an issue. Usually any input I have is connected directly to the output of something else and that provides the path for the leakage current. If that isn't true, e.g. a button, then I'm using a pull-up and thus also not affected. Certain analog measurements could be affected, but again not if they have a low impedance (i.e. strong) source. The current is around 100 microamps so it's not stressing the source much.

It's unfortunate that this is happening in the chip that so massively improved the low power sleep states. Designs needing wake from sleep on pin change with an active high / inactive high-z signal are not going to be good. That requires a strong external pulldown and will be constantly burning those 100ish microamps. That doesn't sound like much, but it's a lot of power for being asleep.

Still I'm very excited for the improved CPU performance and even more RAM. Once mine arrives I'm going to see how much faster it can do some fixed point DSP than the RP2040.

[1] https://github.com/raspberrypi/pico-feedback/issues/401#issu...

* The Nyquist-Shannon theorem actually says the converse, but for anything you'll encounter outside the recesses of a math department, it's still the optimal solution.

The problem is the signal processing part of GPS is quite computationally difficult. I think it was around 10ish years ago it even became possible to do the full real-time decoding on a laptop. At startup, you need to find the GPS signals. This means searching for all 32 possible satellite code patterns across the range of possible Doppler shifts. During testing, this was what took most of the startup (cold start) time. You need roughly 4-6 of them to get a position, so this has to be done in parallel. Once you've found the satellite it takes another 30 seconds to get the satellite position. GPS signals are very slow at 50 bits/sec.

By comparison, actually solving for location is a simple linear algebra problem with 4 unknowns (lat, long, alt, time; but in a more convenient coordinate system). You only do this a few times per second. The hardware does the higher rate signal phase estimation. For example the navspark is a single core SPARC microcontroller running at 100MHz with 200 kB of RAM. That's enough to do 50 solutions per second, though they reduced that to 10 Hz to make space for a user program too.

A ton of work goes into caching strategies to narrow down that initial search space. Modern chips will let you load in exactly which satellites to expect overhead (e.g. based on position and orbit info from cell network). There is a whole other caching strategy based on a approximate "almanac" in the GPS signal for offline devices. With all of that known before the receiver turns on, you can get a solution in a couple seconds.

Proactively deorbiting at EoL is definitely the correct move, but requires enough runway to continue short term operations. I can absolutely picture this being used as political leverage.

25,000 1-in-100,000 collision probability events in 6 months is actually pretty high. Without actively controlling the satellites to avoid you get:

1 - (1 - 10^-5)^(50e3) = 0.39...

chance of collision per year.

SpaceX says Starlink satellites should deorbit in about 5 years if they don't keep actively boosting their orbits. That still means a 90% chance of a collision before deorbit if they stop maneuvering. Those debris would be in low orbits and also decay quickly. You could still to some real damage to any of your neighbors in that time though.

From a regulatory perspective, I sincerely hope the FCC and others are thinking about what contingency plans need to be in place if SpaceX became financially unstable. They've basically guaranteed themselves a government bailout at this point. The UK did that to OneWeb for purely economic reasons. If SpaceX goes under, they're taking LEO with them.

Lots of new GUI blocks in this release. I'm especially glad to see the new eye diagram.

Also the ability to load non-WAV audio files will be nice. OGG/Vorbis and FLAC are now supported. Plus a slew of minor conveniences such as a freq shift block and scaling options in the IShort to Complex block (useful for loading recorded samples from hardware).

If only it would compile easily on my Mac. (https://github.com/ktemkin/gnuradio-for-mac-without-macports has a prebuilt 3.8 version)

Radio: http://lfradio.space

GitHub: https://github.com/UBNanosatLab