litchralee

Agreed. When I was fresh out of university, my first job had me debugging embedded firmware for a device which had both a PowerPC processor as well as an ARM coprocessor. I remember many evenings staring at disassembled instructions in objdump, as well as getting good at endian conversions. This PPC processor was in big-endian and the ARM was little-endian, which is typical for those processor families. We did briefly consider synthesizing one of them to match the other's endianness, but this was deemed to be even more confusing haha

It never ceases to amaze me how prolific PowerPC/PowerISA was (still is?) in the embedded space

There was a ton of hairbrained theories floating around, but nobody had any definitive explanation.

Well I was new to the company and fresh out of college, so I was tasked with figuring this one out.

This checks out lol

Knowing very little about USB audio processing, but having cut my teeth in college on 8-bit 8051 processors, I knew what kind of functions tended to be slow.

I often wonder if this deep level understanding of embedded software/firmware design is still the norm in university instruction. My suspicion has been that focus moved to making use of ever-increasing SoC performance and capabilities, in the pursuit of making it Just Work(tm) but also proving Wirth's Law in the process via badly optimized code.

This was an excellent read, btw.

If you have a particular job focus for after you've graduated with your CS degree, would an internship with a related company be an option? Experience with web will be of limited use for an embedded job, and embedded experience is of limited use at a quantitative analysis company.

That's not to say the experience is entirely pointless, since many skills across the various disciplines of CS are transferable.

When it comes to what insurance does or doesn't cover, the best answer will come from the text of the policy itself. This is, unfortunately, very dry reading and most people -- although instructed to keep a copy handy -- don't have the full text nearby. That said, because of the regulated nature of insurance in the USA, standardized forms of policies exist, and homeowner policies are no exception.

The common homeowner policies are numbered HO-1 to HO-8. HO-1 only pays out only for the ten listened "perils", and is thus the most barren policy available. Not all HO-1 policies are verbatim identical, but the gist usually matches.

We can look at this sample text from a random HO-1 (issued by American Family Insurance). Page 5 shows that "fire or lightning" is covered, so that's a good start.

On page 6, we find the exceptions to the coverage, so if any of these apply, the policy will not pay out. Nothing in Part A would seem to apply to a DIY LED project, unless you tell me your LEDs are radioactive. Part B also doesn't apply, unless you're somehow perpetuating a fraud using LEDs.

Part C reads like it could apply, because it mentions "construction", "design, workmanship or specification", and "maintenance", but this section only applies to the dwelling and so refers to those things which are permanently affixed to the house. That would include things like ceiling fans and light fixtures, but wouldn't include stuff that is attached to the walls using thumbtacks or 3M Command strips. It even says that:

However, we do cover any resulting loss to property described in Coverage A - Dwelling and Dwelling Extension not excluded or excepted in this policy.

This clause basically means the exceptions on Page 6 should be interpreted narrowly, not broadly.

The point is, in the entire policy, there isn't a clause that requires listed equipment, and remember that this is the most bare bones policy commonly available. If such a requirement did exist, then building your own PC wouldn't be possible, since the standards bodies do not test individual computer parts -- except the PSU, because that plugs into the mains.

If a fire that damages the house does occur, the most probable causes would be due to: 1) an unlisted power supply or power brick feeding the ESP32 or the LEDs, or 2) no current limiting (eg a fuse) to cut out the power supply. Other failures like a shorted LED are unlikely to actually cause a house fire, and the insurance companies and UL know this; they're more focused on preventing arc-faults that contribute to an estimated 50% of electrical house fires every year.

Good design and clean installation on your part, and using properly listed low-voltage power supplies, will mitigate the major fire risks, leaving just software bugs and lighting snafus for you to deal with.

As a matter of completeness, if there is an unlikely fire, be it from an LED project or from a candle falling over, the insurance company will still pay. But big or small, the claim will be recorded in the CLUE database along with the payout amount. This often reflects negatively on homeowners, so future rate increases may occur. But that varies by state. In any case, though, the insurance policy has still done its job: cover a non-intentional loss.

I would nevertheless advise you to have a look at what sort of homeowner policy your dwelling is covered under. Everything beyond HO-1 is nicer, and some even include limited claim forgiveness of some kind (for a price). Also consider talking to your insurance agent, who should be able to help interpret how the policy applies.

My first thought for a compact, air-blower would be the inflater for air mattresses. They're already fairly small, have a high flow rate, and exist in forms which accept 12 VDC.

Another option is a small tank of compressed air, but that option is either heavy (steel tank) or stores air at inefficient, low pressures (plastic tank).

I suppose a third option is to rig a can of air-duster so that it blows through the whistle. That would be mechanically simple to implement a solenoid to press the valve, although there is a small environmental cost to using cans of air-duster regularly.

Your primary issue is going to be the power draw. If your electricity supplier has cheap rates, or if you have an abundance of solar power, then it could maybe find life as some sort of traffic analyzer or honeypot.

But I think even finding a PCI NIC nowadays will be rather difficult. And that CPU probably doesn't have any sort of virtualization extensions to make it competitive against, say, a Raspberry Pi 5.

If using asyncio is too impenetrable, try using Trio instead. It's a sensibly-designed asynchronous library, to the point that you'll find it's easier to write non-trivial Python programs in Trio from the start, rather than bolting-on async support later.

Asyncio is just plain weird, IMO, exposing more low-level concerns than is customary for Python. Whereas Trio lets you get things done intuitively.

The 74AHCT125N appears to be a 3v to 5v level shifter, which I wouldn't expect to be drawing a lot of current. So if just the adapter's presence is causing 0.2v drop, then yeah, that would suggest the output current of the port's voltage rail isn't very high, causing substantial sag.

To be abundantly clear, is the Blueretro meant to work when only powered by the console? It certainly wouldn't be as convenient -- an extra cable and power block to deal with -- but everything is functional when externally powered by USB, yes?

Do I understand that your original post is debugging why the console isn't sufficient to power the Blueretro?

I don't have specific experience with game consoles, but the erratic behavior when powered by the console suggests that the port's voltage is sagging when the Blueretro is attached, possibly lower than what the AMS1117 can tolerate.

A quick search seems to show that the AMS1117 has a minimum dropout voltage of 1v. So for 3.3v output, the input must not drop below 4.3v. Other Low Dropout (LDO) regulators could have a smaller dropout voltage, but that might not be the root-cause.

It's possible that without load, the port provides 4.6-5v. But when loaded, it dips below 4.3v, producing the behavior you see. The problem then becomes: is it the NES that's not providing sufficient current on the voltage bus, or is it the Blueretro trying to draw too much current?

Are you able to measure the port's voltage bus when the Blueretro is attached? That would help prove if the bus is sagging. Does the Blueretro allow you to use USB power when plugged into the console?

Ah, now I understand what you mean. Yes, the stock C80 would indeed legally be a Class 2 ebike in California, by virtue of its operable pedals, whether or not it's actually practical to use the pedals. That the marketing material suggests the C80 is used primarily with its throttle is no different than other Class 2 ebikes which are often ridden throttle-only, as many city dwellers have come to fear.

As for the unlock to Class 3, I wonder how they do that: California's Class 3 does not allow throttle-only operation, requiring some degree of pedal input.

The spectrum of two-wheelers in California include: bicycles, ebikes (class 1, 2, 3), scooters, mopeds (CVC 406), motor-driven cycles, and motorcycles (aka motorbikes; CVC 400)

The "moped" category, one which has almost been forgotten to the 1970s, has seen a resurgence: the now-updated law recognizes 30 mph, electric, 4 HP (3 kW) max two- or three-wheelers. These mopeds are street legal, bike lane legal, don't have annual registration, no insurance requirement, but do need an M1/M2 license. These CVC 406 mopeds are not freeway legal, but darn if they're not incredibly useful for in-town riding.

I could get myself an electric dirt bike and plates for it, 100% legally.

Do you have a reference for "class 3 e-scooters"? My understanding of the California Vehicle Code is that the class system only applies to bicycles with pedals, per CVC 312.5.

Whereas e-scooters -- the things that Bird and Lime rent through their app -- exist under CVC 407.5, which previously covered the older, gasoline-powered 50 cc types of scooters. But apparently the law has now completed written out the gas-powered ones, only mentioning electric-powered "motorized scooters".

Strictly speaking, there isn't a requirement in the law for e-scooters to have a speed governor, whereas ebikes must have one, either 20 mph (32 kph) or 28 mph (45 kph). Instead, riders of e-scooters are subject to a speed limit of 15 mph (25 kph), a stalwart from the days of the gas-powered scooters.

The key distinction here is that an ebike over-speeding beyond its class rating is an equipment violation, akin to an automobile without operational brake lights. But an e-scooter over-speeding beyond 15 mph is a moving violation, potentially incurring points on the rider's driving license -- if they have one -- and can impact auto insurance rates, somewhat bizarrely.

I'm not saying CA law is fair to e-scooters -- it's not -- but I can't see a legal scenario where an e-scooter can overtake an ebike rider if both are operating at full legal limits.