That sounds like the crate didn't have coexistence enabled or the defaults were really odd - so much boring stuff to write about BLE/WiFi Coex, but the short is "the default settings" are pretty good for low bandwidth IoT devices.

I'll peek at the code out of interest :)

$0.12 for microUSB female connector (rated 1A) $0.26 for a USB-C female (rated 3A). Needs 2 x resistors (< $0.01), 20% larger board area

I think the power capabilities are the biggest item. If you want to pull higher current from a laptop for development or supply from a wall, you have to switch to USB-C.

I don't think either of these prices are that aggressive - pretty sure the cost comes down at volume.

One thing jumped out here - I assumed CISC inside PIO had a mental model of "one instruction by cycle" and thus it was pretty easy to reason about the underlying machine (including any delay slots etc...).

For this RISC model using C, we are now reasoning about compiled code which has a somewhat variable instruction timing (1-3 cycles) and that introduces an uncertainty - the compiler and understanding its implementation.

I think this means that the PIO is timing-first, as timing == waveform where BIO is clarity-first with C as the expression and then explicit hardware synchronization.

I like both models! I am wondering about the quantum delays however that are being used to set the deadlines - here, human derived wait delays are utilized knowledge of the compiled instructions to set the timing.

Might there not be a model of 'preparing the next hardware transaction' and then 'waiting for an external synchronization' such as an external signal or internal clock, so we don't need to count the instruction cycles so precisely. On the external signal side, I guess the instruction is 'wait for GPIO change' or something, so the value is immediately ready (int i = GPIO_read_wait_high(23) or something) and the external one is doing the same, but synchronizing (GPIO_write_wait_clock( 24, CLOCK_DEF)) as an alternative to the explicit quantum delays.

This might be a shadow register / latch model in more generic terms - prep the work in shadow, latch/commit on trigger.

Anyway, great work Bunnie!

That list in 1.1 isn’t an exhaustive definition which is IMO, one of the causes of the fire. Again, "IMO", the list is an illustrative set of examples as there is no limiting language like "solely" or "only" and the clause even mixes services and purposes, which again signals it’s descriptive rather than definitive.

Saying that, whilst the list inside the definition of "the Platform" is illustrative, the category it defines seems scoped to Arduino-hosted online properties which could be argued is the intent. But its an argument alas...

Either way, ambiguous policy is being communicated by these T+C updates and that is a real problem.

I was confused by how CarPlay was working, as this requires the vehicle to be a host and the phone a device, but I'll assume it means wireless CarPlay (vs USB 2.0 CarPlay).

For the display, I wonder if the device is mimicking the assistive touch inputs via external USB PID (per the note) and using a mouse/trackpad HID can take a screenshot via assistive framework - I guess the app could see this arriving, process it and then delete? Also figure out what is being shown? would explain why the video is sped up a little, but YIKES. Also good luck stopping the app being killed in the background.

All direct USB streams require MFI auth, which might work for exactly 100 devices and could be an alternative, but requires Apple cert for bulk quantities.

I think ReplayKit can only work within an app and can't see the general output stream.

Cool use of tech and curious to see how it actually works :)

re: the notes on the use of the device keys (stored in the K/V store), assuming that they are per device would seem the most obvious vs that they are global. Global keys would be written in the main app body in my experience, not the KV store (but that doesn't mean people have not done unusual things here of course!).

I also want to share some feedback on the complexity of managing per device keys these days and the risks - there are lots of easy to use tools that per device keys like this much simpler to do in 2025 than 2015 and cloud platforms that take in CSV files and return very similar messages... Typically a security model for a device such as an air purifier can be easily defined as not having device encryption enabled if it has per-device keys on as the impact of breaching a single device remains compartmentalized to a single edge component and in this case, just a purifier (vs a car or something that explodes!). Not that I agree with this, but corporate security can! Device encryption causes lots of problems in factories that are often best 'ignored' if the product can afford it.

Per another comment, god bless ESP32 developers once the EU rule kicks in in August... !

USB-C development started in 2012 (I was not there!), but from wiki, the ever helpful source of truth: "The design for the USB-C connector was initially developed in 2012 by Intel, HP Inc., Microsoft, and the USB Implementers Forum. The Type-C Specification 1.0 was published by the USB Implementers Forum (USB-IF) on August 11, 2014.[1] In July 2016, it was adopted by the IEC as "IEC 62680-1-3".[3]"

I not sure of the logic here, but Lightning solved a problem way before USB-C existed and I'm sure, led to support of USB-C standards such as reversible connectors etc...

---

I was swept up in this article and the portrait for Amanda (barrows) - what a unique and strong person - this city is soo lucky to have her.

I want to respond that unlike some here, I came away with huge empathy and today's HN snark and frustration bounced off me pretty hard accordingly. The public order issues such as homelessness in the park have impacted me, but more so, how to translate the state of the world to my children. I always remind them that this person was once a little boy / girl and we might be older, but we're still kids inside and nobody dreamt to grow up in this environment.

The compassion and my own empathy shown here coupled with the pragmatic approach shown by Amanda washed over me and the policies and bureaucratic inefficiencies that make solutions slow and ineffecient are understandable, but also highly frustrating.

The unhoused individuals and their mental state vs the requirements to find a home are very frustrating - the city surely understands the cost of housing policies and is run by highly pragmatic people, but rules are rules and some top down accommodations and medications are needed to help merge this.

---

I personally don't see my opinions changed here - I think the posted text is a bit better but also agree on the uncanny valley issue. A little less brain swelling and I would have been all over the small signals :)

Personally, I find AI and the derivatives extremely helpful when it comes to communication (a booster for the mind!) and use it all the time when translating into other languages and also removing my northern British dialect from communication over in California.

Unlike some here, I came away with a deep sense of empathy, and today’s HN snark and frustration bounced off me pretty hard. The public order issues - homelessness in parks, the challenges of shared spaces—have certainly impacted me. But more than that, I struggle with how to translate the state of the world to my boys. I always remind them: every unhoused person was once a little boy or girl. We might be older now, but we’re still kids inside, and nobody dreams of growing up in these circumstances.

What struck me most was the balance of compassion and pragmatism that Amanda brings to her work. It’s easy to be frustrated with the policies and bureaucratic inefficiencies that slow down real solutions - but they are, in some ways, understandable.

The biggest frustration for me is the gap between the mental state of many unhoused individuals and the requirements needed to secure housing. The city surely understands the long-term costs of its policies, and it’s run by highly pragmatic people with limited budgets. But rules are rules, and at some point, top-down accommodations (including medical interventions...) are necessary to bridge this gap.

I'd be surprised if there was anything but cold hard contract negotiations going on behind the scenes that will shortly end in an amicable settlement and another 10 years of ARM based QCOM chips.

The PSRAM had a reasonable size page cache in the chip that made this memory quite responsive from a CPU perspective - a few rare cache flushes were needed, but things like DMA and bus masters (onboard radios etc..) were completely coherent and it made development much easier to manage.

My takeaway was that PSRAM was surprisingly capable (with the right can of hardware controller in place). Kudos to Realtek for getting the hardware to work without a thousand impossible to debug CPU lock ups...

Before purchasing, I had the exact same concerns as raised in this article. Here is what I found out:

- California mandates that PZEV certified vehicles be covered for 15 years/ 150k miles for all emissions related parts (i.e. the range extender engine).

- For batteries or energy storage devices of vehicles certified to the Partial Zero Emissions Vehicle (PZEV) emissions standard, they must be covered for 10 years or 150,000 miles, whichever comes first.

The i3 REX happens to fall into this PZEV category and so I've great warranty coverage. If the battery drops below 70% or outright fails, its fixed free of charge within this time frame.

This owner hadn't purchased an i3 with the Range Extender option - if they did however, they could move their car registration to CA and would get this repair for free. The warranty for BMW vehicles post 2011 is on the state a vehicle is registered in, not the state a vehicle was originally imported or last sold in.

Comments URL: https://news.ycombinator.com/item?id=37502036

Points: 1

# Comments: 0