hasheddan

If you want to search through all of the songs without scrolling on the iPod, you can hit the API[0] directly for the JSON.

[0] https://music.apple.com/includes/ipod/data/us/en-US.json

Fun fact: esp-idf includes an x509 Certificate Bundle API[0] that will pull in the entire Mozilla trust store by default. However, they will be stripped unless firmware calls `esp_crt_bundle_attach`. There is an issue[1] tracking removal of the eMudhra root CA certificate.

[0] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...

[1] https://github.com/espressif/esp-idf/issues/19282

To be clear, I agree that it is not a valid excuse and pushback is warranted.

This is unfortunately accurate, sometimes due to real constraints and more often due to loose threat models. I am hopeful that more open source firmware options (e.g. Zephyr RTOS) and more software investment from silicon vendors is helping to change the status quo. That being said, we are still a long way away from a "Let's Encrypt movement" for embedded devices.

You can check out the tiles for this project and their exact location on the TT chip[0].

[0] https://tinytapeout.com/chips/ttgf26b/tt_um_coffeepot

Agree RP2040 / RP2350 is great for debug and UART access! I wrote[0] about using picoprobe with this device as well.

[0] https://danielmangum.com/posts/risc-v-bytes-accessing-pineci...

Great episode. lcamtuf's blog[0] is one that every engineer should follow. Though if you're reading this comment you probably already do :)

[0]: https://lcamtuf.substack.com/

Author here, thanks for posting! Happy to answer any questions and would love to hear about any use cases in which folks have dynamically enabled / disabled FPU functionality throughout program execution.

Hey Arjun and Sid! I am CTO at Golioth[0], a connected device cloud platform. Just wanted to say congrats on the launch, and wish y’all the best of luck! There is lots of complexity to be addressed, and it is always great to see more folks building in this space. Happy to compare notes any time!

[0] https://golioth.io/

Good question! We wrote a few blog[0] posts[1] about the motivation for signy and how it is used in practice. The primary use case is complex devices with multiple MCUs and multi-protocol connectivity (e.g. Wi-Fi, Cellular, Bluetooth, etc.). In this context, each MCU may have different security capabilities, and manufacturing / provisioning may be simplified by storing a single set of credentials (e.g. a private key) in a single secure storage location, then using that key to generate a temporary signed URL that can be handed to the less secure domain for a scoped operation, such as downloading an asset. There are also more niche use cases, such as allowing an end user to access a private resource by generating a signed URL and sending it to a phone via NFC.

[0]: https://blog.golioth.io/signed-urls-for-embedded-devices/ [1]: https://blog.golioth.io/signed-urls-on-esp32/

> There are so many options and all are very cool to explore.

Very much agree, controlling a varicap via an MCU is a nice intermediate step of "digital tuning" without going all the way to SDR.

You will not be disappointed! Well worth the investment.

> it is very rewarding to pick signals out of the air

I could not agree more :)

——

This is quite possibly the most positive interaction I’ve had on HN — thanks Jacques!

Author here -- thanks for the comments and feedback! I typically use the solder stripping technique as well when actually incorporating the inductor into a circuit. Interesting you should mention variable capacitors as I just went through the process of sourcing 5 of them (will be discussed in a future post) from Amazon, and not only were they expensive, but they also took significantly longer to ship than was originally estimated.

I am somewhat surprised that the small loops would pick up a meaningful amount of noise, though I suppose meaningful always depends on the use case and tolerances. Do you have any references for how significantly this can impact inductor performance? Or is the primary concern just the rubbing and potential shorts?

Despite ferrite core inductors and loopstick antennas being old, fairly well understood technology, I have found there to be very little in the way of hands-on experiments with tangible results available. I'm hoping to continue testing various techniques and posting about them -- you've already provided some great variations for me to test out!

Could not agree more! And yes, though due to the lack of specifications available for the ferrite rods I purchased, it ended up being more of a calculation of their permeability based on the measured inductance. I'll have another post soon that shows measuring the resonance frequency of these inductors with various types of capacitors, which is a fun exercise in parasitic capacitance and inductance.

You can also throw together a cheap software KVM switch[0] using an ESP32 or similar.

[0] https://euer.krebsco.de/a-software-kvm-switch.html

Hey folks, author here. Appreciate the comments and discussion on the post! Happy to continue the discussion or answer any follow-on questions folks have about our investigation and resolution.

Author here -- thanks for posting! Happy to discuss Nordic chipsets, Wi-Fi support, etc. if anyone has any questions or follow up topics.

Great pointer! My sibling post in this thread references a few other blog entries where we have detailed using eDRX and similar low power modes alongside Connection IDs. I agree that many devices don't need to be immediately responsive to cloud to device communication, and checking in for firmware updates on the order of days is acceptable in many cases.

One way to get around this in cases where devices need to be fairly responsive to cloud to device communication (on the order of minutes) but in practice infrequently receive updates is using something like eDRX with long sleep periods alongside SMS. The cloud service will not be able to talk to the device directly after the NAT entry is evicted (typically a few minutes), but it can use SMS to notify the device that the server has new information for it. On the next eDRX check in, the SMS message will be present, then the device can ping the server, and if using Connection IDs, can pull down the new data without having to establish a new session.

An ad for... the IETF? All of the firmware discussed in this post is open source, and we even contributed DTLS Connection ID server side support to a popular open source library [0] so other folks can stand up secure cloud services for low power devices. Sure, we sell a product, but our broader mission is making the increasing number of internet connected devices more secure and reliable. When sharing knowledge and technology is in service of that mission, we do not hesitate to do so.

[0]: https://blog.golioth.io/golioth-announces-connection-id-supp...

The post details the use of CoAP over DTLS, employing Connection IDs.

Yes, thank you for calling out. It should read "more important". This has been corrected.

Author here -- thanks for engaging in the discussion! You won't find any pushback from us on using Zephyr -- we are contributors, the firmware example in the post is using it (or Nordic's NCS distribution of it), and we offer free Zephyr training [0] every month :)

[0]: https://training.golioth.io/

Author of this post here -- thanks for sharing your experience! One thing I'll agree with immediately is that if you can afford to power down hardware that is almost always going to be your best option (see a previous post on this topic [0]). I believe the NAT post also calls this out, though I believe I could have gone further to disambiguate "sleeping" and "turning off":

> This doesn’t solve the issue of cloud to device traffic being dropped after NAT timeout (check back for another post on that topic), but for many low power use cases, being able to sleep for an extended period of time is more important than being able to immediately push data to devices.

(edit: there was originally an unfortunate typo here where the paragraph read "less important" rather than "more important")

Depending on the device and the server, powering down the modem does not necessarily mean that a session has to be started from scratch when it is powered on again. In fact, this is one of the benefits of the DTLS Connection ID strategy. A cellular device, for example, could wake up the next time in a completely different location, connect to a new base station, be assigned a fresh IP address, and continue communication with the server without having to perform a full handshake.

In reality, there is a spectrum of low power options with modems. We have written about many of them, including a post [1] that followed this one and describes using extended discontinuous reception (eDRX) [2] with DTLS Connection IDs and analyzing power consumption.

[0]: https://blog.golioth.io/power-optimization-recommendations/ [1]: https://blog.golioth.io/turn-off-subsystems-remotely-to-redu... [2]: https://www.everythingrf.com/community/what-is-edrx

Indeed. It is used in this post to compile the Zephyr Hello World example for the PPR.

Author here. I’ve got a few more posts on VPR coming in the next couple of weeks. If you have any requests for deep dives into specific aspects of the architecture, feel free to drop them here!

awesome! keep up the great work!

There is a page[0] in the Bluesky docs on this, though it effectively boils down to “fetch each user repository”.

[0] https://docs.bsky.app/docs/advanced-guides/backfill

Good suggestion. I think that my pre-race fueling strategy was better than previous races, but certainly lots of room for further improvement!

I appreciate the kind words! Best of luck on your leap of faith -- it takes courage to attempt it in the first place!