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!
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.
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.
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.
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.
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 :)
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://tinytapeout.com/chips/ttgf26b/tt_um_coffeepot