Not all FPGAs are that expensive... I work a lot with AMD stuff (they bough Xilinx in 2022), and you can get a decent SOM for $300 or less. Not "dirt cheap", but not expensive. They have FPGA chips well under $100, including ARM CPU cores, or a soft RISC processor.

It's a freaking 16-bit Intellivision running at 895kHz (not even mHz, let alone gHz!) ... any latency from the wireless devices will be _dwarfed_ by latency in the processor (or emulated processor). I'm sure the processor in the re-issue we're talking about here is much much faster, but it's probably spending 99% of its time in sleep cycles to dumb itself down to the original console's timing... meaning it can handle the wireless controllers just fine.

Now for modern-day gaming, yeah, I won't argue. But for this context, lol...

It was an interesting experience, just out of curiosity. A few highlights:

- it seemed to max out at about 20mph on my ride, but that seems to be so that it could time the lights well and not have to stop/slow down

- a car backed out of a parking lot and directly in front of us. The Waymo stopped, honked, and when the car kept backing up it quickly reversed. A human driver would have been hit (seriously)

- but, I also seem to think that the driver backing up did so because they knew they could "bully" the Waymo and it would get out of their way.

It was easy to get one from the hotel to a cafe outside the city center, they were everywhere. We counted over 30 going by a restaurant while we had a quick meal. But getting one to come pick us up outside the city center would have taken 25 minutes, so we Ubered back instead.

"Interesting" is the only description of the experience. I can see the appeal of not dealing with people in the process, but I'm an introvert.

I deeply apologize that Nancy Mace has anything to do with us. We're working on fixing that at mid-terms...

space-based would be closer to 24/7 sunlight (depending on orbit), would suffer less from atmospheric absorption (presumably, the light would always be coming directly "down" on the target receiver - not obliquely through the atmosphere), etc.

At least in the article it says you can disable it (which I'd do in a nanosecond), but if not I'd return my product as defective and force the issue.

But - I won't buy a smart TV in the first place. I have streaming devices that do what I want it to do, and they're way better than built-in crap in TV's. However, I'm not sure how long the option of "dumb" TV's will last... especially if they see more opportunity in advertising than just sales.

We are the product, not the consumer. :(

yep - as a "public shaming" deterrent from viewing that content... i.e. censorship.

Sites that sell/promote alcohol just have a "are you over 21?" checkbox... why is that sufficient for alcohol and not porn? It's an attempt at censorship, cloaked in "think of the children".

But this is hardly ground-breaking work... I've been doing this commercially with the RPi for over 7 years. Anecdotally, based on almost a thousand systems, the MTBF I've seen is over 73 YEARS for the RPi, and even then most of the failures were due to external factors like shorts and lightning strikes, etc. It's a solid system, and rock solid. Having a full Linux stack to work with is nice too - there's nothing we haven't been able to do.

Funny... embedded systems is my area too, and I'm the OP on this thread. Hammer vs. screwdriver... know when to use which, but have both in your tool belt.

And if you knew anything about Python, you'd know that for use cases where speed is the primary factor, you can stub out to C and back. That's exactly how some of the more powerful libraries run - I've done a lot of code for the Python Imaging Library for example where that's done, including true multi-threading support.

So - bash all you want, it just shows you don't know when to use a hammer versus a screwdriver.

Interesting... care to share your data to support that opinion?

Actually I am using SD. However, the software stack ensures that anything that's being read/written often is done on a Ramdisk instead, and only written to disk when necessary. We haven't had a single SD card failure yet... in ~4 years of systems being out there (oldest ones still running fine).

Well, either that's poorly written software, or a poorly configured environment for what you're trying to do. Python is solid... but any language can look "bad" if you're using it wrong.

Pi's are a lot more reliable than you may think...

I have about 600 currently running in the field (for the last ~3 years), and the failure/lockup rate is about 1 system every 3-4 months. That's an MTBF (calculated, of course) of about 200 years. Of course that won't hold up over time, but it's impressive.

Basically all of the failures I've had are attributable to external events - either electrical storms/surges, or people physically shorting out GPIO pins when installing things or doing other service work.

I've designed hardware-based watchdog systems into my future control board that these plug into, but based on the data they're not really needed. But, the extra security is always a good thing.