Ian's Build Log

Hello!

My name’s Ian, I’ve been a programmer for some time (25 years) and have worked on all kinds of stuff (networking, climate models, geospatial data analysis, cloud infrastructure, more “normal” web apps, and more). I recently started a job that involves embedded work (currently doing some things using Nordic’s nRF52840 chip for some wireless mesh networking). I realised that I don’t know enough electronics for this sort of thing! And then I realised what a world of fun things there are that I could do if I did know more electronics! (My “maybe” project list gets longer nearly every day.)

Unfortunately, my previous experience of electronics education was not so positive (learning electronics as a physics undergrad involved 16 hours of lectures on semiconductor physics and some “tricks” for wiring up transistors). A second try later on as a graduate student didn’t work out too well either (maybe a PCI data capture card wasn’t such a good first project, hmmm?). But now, this looks like it has a chance of working, and I’m looking forward to getting started!

Cheers,

Ian.

Welcome @ian,
I look forward to hearing more about you progress. Do you have any particular projects in mind?

Hi @Steve_Mayze,

I have a couple of near-term things, a couple of longer-term (very hard/perhaps impossible for me) things, and one or two potential commercial products I want to start on in a year or so. As a sample (i have ideas coming out of my ears…):

  • One nearer-term thing is a sort of art project. This is a clock with a face made up of RGB LEDs laid out in something like a Fibonacci spiral (like the seeds in a sunflower), behind translucent plastic as a diffuser, with the clock display varying in interesting ways through the day. That would probably involve some funky microcontroller programming (Forth, maybe, just for fun), capacitative touch controls, power management (lots of LEDs), building a reflow oven (who wants to solder 100+ SMT LEDs by hand?), and maybe something odd for long-term clock stability (I’ve heard that mains power is surprisingly frequency-stable in an aggregate sense over the long run, so I was wondering about stabilising the clock to mains hum…).

  • One potential commercial product is something I’ve been thinking about with my wife, who’s an occupational therapist. She treats a lot of patients with rheumatic finger joints using a manual traction method, and we’ve been thinking about a “finger puller” device that would allow patients to treat themselves at home using this method. It’s a bit more complicated than it sounds, since it involves some issues to do with mechanical design for safe holding of the finger being treated, it needs to be able to generate a reasonably significant force safely without pulling the joints too far, and so on. From an electronics perspective, it’s mostly a fairly standard sensors + actuators + tiny UI on a microcontroller project, but two parts of it are interesting: one is that at least one of the actuators will probably be some sort of piezo + flexure thing, and I don’t know how to generate the voltages needed to drive that, and the other is that the things that grip the finger being treated will probably be some sort of pneumatic actuator (they need to be able to grip securely but compliantly, which doesn’t leave too many choices), which again has some interesting power and miniaturisation issues.

  • One long-term “could I really do that?” project is a satellite ground station. I used to do a lot of work with remote sensing data for ecological and climate monitoring, and a lot of the satellites carrying the instruments we used transmit data that can be picked up by local ground stations as they pass (as well as relaying data to central ground stations for aggregation and further processing). I know nothing at all about the details of how to do this, except that “it’s probably really hard”, but it would certainly be pretty cool to be able to pick up frames from, say, MODIS, as it flies over the house.

I’m definitely at that “don’t know what I can’t do” stage of things! I think I’ll make some blinkies first…

Cheers,

Ian.

Hey Ian,

I’m working on the same nordic chip for several consumer devices as well :slight_smile: - it’s an interesting little guy and the 5340 is looking like a pretty cool part as well.

With regards to your occupational therapy idea - a soft robotics solution immediately came to my mind - I remembered reading about this device ( https://www.aceo3d.com/3d-printed-soft-robotic-glove-for-rehabilitation/ ) a while back and I think something in that vein (with a different actuator geometry and the correct blends of silicone picked). I have done a few soft robotics projects over the years and while fiddly they are really really versatile in biomedical applications

Also your satellite idea isn’t at all as bad as you think - In fact it’s fairly easy assuming you are willing to spend a little bit of money on the receiver and antenna - for reference here are some folks picking up NOAA imaging with a hackrf and literally scrap wood , scrap coax and some random pieces of scrap metal ) - https://www.instructables.com/id/Receiving-Images-From-Passing-Weather-Satellites-N/

M

Hi Matt,

Thanks a lot for the information!

I’d not seen the nRF5340 yet. That definitely does look nice. I like the idea of having a core dedicated to running the radio stack. I’ve been having endless problems with stability writing custom code (nRF5 SDK + FreeRTOS + OpenThread + custom MQTT-SN client library + application code) and it would be nice to be able to just run a pre-built radio stack to avoid that and keep the custom code on the “application” core.

I really like soft robotics too! I think it has a lot of potential for lots of things. I’d seen something a little like the link you posted before (a research group in Korea, I think it was), but I did not know that you could now get silicone 3D printed commercially (this is from Wacker in Germany). That’s pretty great! There are a couple of extra tricky things with that particular application (exercising spastic hands). First, if the hand is really tightly curled up, it can be very hard to even get these devices on (it’s certainly too hard for the patient to do it themselves). Second, apparently it’s much better to push from the inside of the curled fingers than to pull from the outside (for joint health). That means that you need something that can collapse more or less completely to get it into the inside of the curled-up hand, and I think that more or less rules out silicone for that particular application. I had been wondering about mylar as an alternative material: it’s common, strong, air-impermeable, bondable, and very thin. I don’t know how well that would work. Anyway, I’d be very interested to pick your brain about your soft robotics experiences some time.

As for the satellite ground station: that antenna is wonderful! I’d been thinking you’d need a steerable dish, so a 2x4 plus some wire is a fairly significant reduction in complexity! The part that I thought might be hard/impossible was actually designing and building an SDR. As a learning project, I don’t think I’d buy an off-the-shelf receiver. But now I’m thinking it might just be “very hard” rather than impossible: looking at the HackRF One schematics, the component count is way lower than I expected. I was expecting exotic wiggles on the PCB with dozens of little RF modules, but all these super-integrated RF chips (like the MAX2837 RF transceiver) make it look like a human could design these things.

But not this human, not just yet! Maybe in a year or two.

Cheers,

Ian.

Yeah - so from talking a bit with the Nordic guys FreeRTOS still isn’t super mature on the 52840. They are a really excellent company and are super responsive to users and even forum posts which is refreshing. We’ve had some issues along the same lines as well

I think you’ll be pleasantly surprised to discover just how far you can get with the right kind of quite literally paper thin silicone rubber - material properties are pretty damn impressive.

On the receiver end - yeah a DIY sdr is pretty doable - this conference badge https://github.com/rad1o is pretty much a full SDR strongly inspired by the hackRF I believe . Also apparently this 16 year old kid got bored and did his own SDR based on a vendors reference design - http://electronics.kitchen/misc/freesrp/ - happy designing :slight_smile:

Thanks for the SDR pointers: those things look really interesting. And you’re probably right about the silicone: I need to make some stuff with it to get a feel for what it can do.

The hassle I’ve had with the nRF52840 has mostly seemed to be due to problems in the radio driver built into the OpenThread libraries. There have been a few comments in the past on the Nordic forums about things like this, and they’ve been fixed, but they’re all horrible race conditions, so there are probably some more lurking in there. (The problems I see tend to look like the transmitter side of the radio driver getting stuck and refusing to send any more packets. That means the device gets dropped from the network eventually. Reset the chip and it reconnects instantly with no problems. Sometimes it goes for half day without getting stuck, sometimes it lasts 10 minutes. Fun times. I’m just going to identify a quick way to diagnose the problem and reset when it happens. Not ideal, but it seems like the most pragmatic way to go.)

I’ve been working through the first CE projects and having a lot of fun with it. I didn’t send out any boards for manufacture for Getting To Blinky because I had a stupid idea to do something more with that. I’ll write about it when it’s finished. It’s nothing very exciting, but I find it quite amusing: programmatically generating Morse code blinkies with some Python code for placing logic onto 74xx chips and using SKIDL to generate netlists. Totally useless, but good for learning some things. I’m going to work on that tomorrow, and hopefully get it finished so I can go on to more useful things.


In a more sensible vein though, I’ve been working on the CE Header project. That has been interesting mostly because of the huge amount of time I took trying to make sure the various connectors were the right way round. It’s amazing how confusing that can be. First I tried to do it in my head, just staring at the footprints in KiCad.

Then I gave up with that and made some paper models, one for the Teensy, one for the Teensy breakout board and one for the sensor board, and sat at my desk trying to convince myself that things would line up right. That was enough to convince myself that I had things the right way round for connecting the Teensy to the breakout board.


It wasn’t quite convincing enough for the CE header itself though, so I spent an hour or two working out how to quickly get 3D models for a “CE header plug” and “CE header socket” together. That was easy enough in FreeCad, because it just involved chopping some pins out of existing models for 2x10 pin headers and sockets (make a “cube”, do a Boolean difference, repeat until done). Finally convinced that everything was OK, I just ordered the boards!

The main lesson learned from this was that some little things can be surprisingly time consuming…


I’ve also been doing some nRF52840 firmware programming for work this week. I had been having all sorts of problems with instability using the OpenThread networking protocol, and had been blaming it on all sorts of things, none of which were my fault. It turns out though, that when Nordic say “the OpenThread SDK is not thread-safe”, they really mean it! I had been trying to protect all the OpenThread SDK calls with mutexes (I’m using FreeRTOS), but there always seemed to be one more place that wasn’t properly protected, so I was making race conditions rarer but they never really went away.

In the end, I gave in and did what I should have done in the first place, which was to turn everything inside out and make the OpenThread SDK access “manifestly thread-safe” by using message-passing through a FreeRTOS queue from the other threads that wanted to do OpenThread things, and having a single “OpenThread server” task pull commands from that queue and service them. That ensures that all OpenThread SDK calls happen in the context of that one task, and also that all callbacks from the OpenThread SDK happen in the context of a single thread (I think this is what had been causing the trouble before).

Fingers crossed, but it’s been running without problems for 6.5 hours now…