Ian's Build Log

[ian (Ian Ross)]

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.

[Steve_Mayze]

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

[ian (Ian Ross)]

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.

[MPang (Matt Pang)]

Hey Ian,

I’m working on the same nordic chip for several consumer devices as well - 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

[ian (Ian Ross)]

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.

[MPang (Matt Pang)]

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 rad1o · GitHub 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 - Blog | electronics.kitchen - happy designing

[ian (Ian Ross)]

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.)

[ian (Ian Ross)]

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…

[ian (Ian Ross)]

I’ve finally finished my silly project inspired by “Getting to Blinky”.

For your amusement, may I present Morse Blinkies as a Service! You can read the details here and see the code here.

Totally useless, and it turned out to be something of a rabbit hole, but I learnt quite a bit. Going to send off a blinky board for manufacture now…

And then it’s back to more normal (and useful) Contextual Electronics content!

[Steve_Mayze]

Hey @ian great effort (and exercise) on getting into SKIDL. I have seen it being presented but not made the time to look into it.

[ian (Ian Ross)]

It’s pretty cool. I think it could be a really useful tool if it was fully integrated into the KiCad schematic editor.

[ChrisGammell]

That is a really interesting idea to put a web front end on top of SKiDL. Now you need another dynamically generated circuit to actually read the Morse code from afar

[ian (Ian Ross)]

I’ve been working through the Current Sink Or Swim project, and I decided to try to make a programmable sink that I can use for battery discharge experiments, tracing battery I/V curves, and so on. I’m planning to make something that will connect to a Teensy (since I got one for the CE Header project anyway).

I have a design that I think will work (schematic only so far), but I’d appreciate any input.

At the top level, there are some pin headers to connect the Teensy and a connector to attach the device under test. The idea is to power everything from the Teensy’s 3.3V supply. That can provide 250 mA, which seems like it ought to be enough, but one question I do have is about how you might estimate power requirements for a circuit like this. I started trying to do that, but realised I didn’t know what I was doing…

Following the approach in the course videos, there’s a current programming section, which in this case is driven by an I2C DAC to set the programming voltage that controls the current draw (with limits of 0 - 10A, set by a resistor divider between the DAC and the op amp input). As the FET used to draw current from the device under test, I’m going to use the Infineon BTS141, which has a pinout like a FET but has all sorts of protection features built in (overcurrent, thermal, etc.). Seems like a good part for someone who isn’t quite sure what they’re doing! There’s also an additional op amp unit used as a current level sense, with its output fed to one of the Teensy’s ADC inputs (they have a relatively low input impedance, hence the op amp as a buffer). That gives a way to monitor what current the device under test is really providing. (I’m using a TI TLV4333 quad op amp here, which seems quite jellybeanish, but ought to do the job.)

Finally, there’s a voltage limiting section, which sinks current from the FET gate if the total voltage across the device under test is too large. The voltage limit level is set by another DAC through a voltage divider to the input of an op amp used as a comparator, with the other comparator input coming from a voltage divider connected across the device under test. A final op amp buffers that voltage level for input to a Teensy ADC input for voltage monitoring. The way the voltage divider between the DAC and the op amp is set up limits the voltage range to 0 - 20V, but the idea is to control the maximum voltage setting depending on the current demanded to keep the total power dissipation in the FET below 20 W, which is what I think the heatsink I’m using will handle.

Questions that I have are:

1. Does this seem like a reasonable approach? Am I missing anything obvious? Have I done anything that’s just plain wrong?
2. Is there any way to get a reasonable estimate of the power requirements of something like this to work out whether driving it all from the Teensy 3.3 V supply is going to work?
3. Should I add any extra protection components? For example, is it worth putting a Zener diode (with Zener voltage somewhere between 2.1 and 3.3 V) between the negative input of U102C and ground to protect the op amp input from excessive voltage from the device under test?
4. Is using a pair of DACs to set the current and maximum voltage levels overkill? Would it be simpler to use a couple of PWM outputs from the Teensy with low pass filters? (I didn’t go that way because I didn’t know how to calibrate the resulting voltage levels, but I guess they’re just linear in the PWM duty cycle, aren’t they?)
5. Generally, do the component choices seem OK? The BTS141 seems solid, the DACs were chosen to have predictable zero output at power on reset, the op amps don’t seem to have very demanding requirements, and the heat sink was chosen to handle 20W of power dissipation in the FET.

That’s a lot of questions, I know! Any input at all would be gratefully received!

[ian (Ian Ross)]

Started putting together my CE header things today, and discovered 3 mistakes. Three mistakes, in such a tiny thing! One was just stupid (mistakenly ordered one chip in some micro-something package instead of an SOIC: Maxim sure do love their tiny tiny packages, don’t they?), but the other two were educational (in an annoying way).

I’d ordered female header sockets that I thought would fit normal square male header pins. Turns out there are more kinds of connectors in the world than you can ever imagine, and I ended up with sockets with little round holes the bigger square pins wouldn’t fit into. Lesson: look carefully at the mechanical drawings for connectors to make sure that they’ll, you know, connect…

The last mistake taught me the valuable lesson that SOIC packages come in different widths and that you sometimes have to look very carefully to work out which package you’re actually getting when you order things. Mouser says it’s in an SOIC-16, but they also have a little “width” field lower down! I managed to squeeze a 5.3mm wide chip onto a 3.9mm wide footprint, but it’s not the prettiest. Lesson: check the full part number on the manufacturer’s website to see what the package really is! This is a TI part, and it’s easy to find the exact package information if you look.

Ho hum. And I just went and checked, and I have another board on the way with the same SOIC width mistake for half a dozen chips… That’s going to be fun to solder!

[ian (Ian Ross)]

I’ve been suffering from footprint woes today. I ordered boards for the CE header sensor board and for my Morse blinky example, both of which have SOIC chips on them with 5.3mm wide bodies. I screwed up the footprints, and used a 3.9mm wide one everywhere instead. (In my defence, there doesn’t even seem to be a 5.3mm wide SOIC-14 footprint in the KiCad libraries.)

I gamely tried to solder the wider chips on to the narrower footprints, but it’s not very effective. For the CE header sensor board, the shift register (a 74HC595) has most of its pins not quite connected, but I think I might be able to repair that with some adventurous soldering. (The LDR and the I2C temperature sensor on there work fine.)

But the Morse blinky looks like this:

Every one of those 74xx chips is perched on a footprint that’s way too narrow, so most of them have pins floating in the air or just beyond where solder on the pads can reach them. Here’s a picture of the chip in the top left of the board that I attempted to do some more aggressive work on. You can see that the pins are still nowhere near the solder blobs on the pads…

So that’s all a bit sad. I’m very tempted to respin the Morse blinky example, just so I have something to show from that silly project. (The CE header stuff I’m less bothered about, since most of it worked, and it was a pretty useful learning project.) This was all a very valuable lesson anyway, since I will henceforth be just about the most paranoid person in the world about footprints, which can only be a good thing!

So, tomorrow will be redoing the Morse blinky, doing some breadboarding on PWM outputs from the Teensy as a possible thing to use on the Current Sink or Swim, and if I can get that working satisfactorily, laying out the board for that and thinking about what’s needed for the firmware and software to go with it.

[ChrisGammell]

@ian

I screwed up the footprints, and used a 3.9mm wide one everywhere instead. (In my defence, there doesn’t even seem to be a 5.3mm wide SOIC-14 footprint in the KiCad libraries.)

This was actually something that happened on the BenchBudEE that was part of the past versions of CE. It was a hassle, especially given that people were often learning to solder while attempting these fixes.

Much like you allude to, I have taken to checking datasheets and matching up against the width of the footprint in the library. I find that the SO family parts are particularly bad, followed by the QFN families.

The solder job on this board looks like a valiant effort! I would recommend trying to “fold the pins under” by bending the pins down and underneath the part. There are older components that did this to improve how the parts were socketed, but sometimes i have seen them soldered down as well.

[ian (Ian Ross)]

Folding the pins under sounds like a good thing to try. I’ll give that a go!

[ian (Ian Ross)]

Well, I tried the “fold the pins under” trick on the CE sensor board, which only had one chip with a bad footprint. I can see how the technique could work if you had decent soldering skills. Unfortunately, I have soldering skills that could best be described as “woefully amateurish” and I made a complete hash of it.

The other board with the problem had five chips with bad footprints, and I couldn’t quite face the prospect of folding the leads under all of those and trying to solder them down. So I just fixed the layout and sent the boards out to OSH Park again. Avoiding the frustration of trying to fix the thing is definitely worth the US$6.50 it costs to get new boards made!

I’ve been out of action for electronics the last few weeks because of an enforced house move (not recommended during a pandemic lockdown, but we didn’t have a choice), but I’ll be getting back into things again. I’ve started laying out the PCB for my Current Sink Or Swim variant, which I’m calling Teensy Load, because it’s a programmable load with a Teensy attached. I think I need to work on product naming for the future…

The next project on my list is a solder fume extractor (everyone does the same projects when they start, don’t they? there are hundreds of designs for these things out there!). In homage to Jon Thomasson’s Solder Sniffer 9000, I’m calling it the Solder Snorter. It’s going to have one functional variation compared to Jon’s design, which is to have a resistive touch switch to switch it on and off, with the contacts made up of the nostrils of a cartoon pig silkscreened onto the board. (Hence “snorter”.)

It’s mainly a vehicle to learn a little about battery charging and DC/DC conversion (the “Full Charge Ahead” videos from the legacy CE course are really useful for this). Plus the resistive touch switch thing looks like it might be funny to do. I thought it would be simple, but a first quick search indicates that there might be “traps for young players” involved somewhere. So there’s going to be some breadboarding required to work out just how to do that.

[ian (Ian Ross)]

Boards and parts ordered for my Teensy Load (basically a programmable version of the Current Sink or Swim using a Teensy for the programmability).

Took two tries to get a board layout I was reasonably happy with. This is the first project that feels like “uncharted waters” where there are a few things where I’m really not sure what I’m doing. (Any feedback would be welcome: the KiCad files are at https://github.com/ian-ross/teensy-load/tree/master/hardware – the schematics haven’t changed much from what I posted a little while ago.)

I think that the critical bits of the design are OK: fat traces (with 2 oz. copper) for the high current loop (and the loop made physically as small as possible given the sizes of the components), power ratings for the sense resistor and FET should be OK (I think the heatsink might be overkill: the 3D render looks pretty ridiculous anyway…), and everything else pretty vanilla. Some “safety by design” using voltage dividers to make the full range of the DACs used for setting the current and voltage limits correspond to the maximum ranges of those things that I want. The only limit that needs to be managed in the Teensy firmware then is the overall power limit, done by capping the voltage limit to make sure the power limit isn’t exceeded.

OSH Park’s 2 oz. copper service for cheap boards is slower than their regular service, so now the long wait begins…

[ian (Ian Ross)]

While I’ve been waiting for boards (I need to find a cheap PCB house in Europe: OSH Park are good, but it’s a long wait for delivery from the US to Austria), I’ve been working on this solder fume extractor project. I kind of retreated from the idea I originally had, which was to have some sort of resistive touch switch using a couple of pads on the PCB. That seemed like it ought to be quite easy to do, but it turned out to be trickier than I thought.

So, a normal switch it is, since this thing was mostly about learning a little about batteries and battery charging and power conversion, and I’ve done that.

I’ve read more datasheets for battery chargers and boost converters than I ever really planned to! How the hell do people find stuff to use among the thousands of options? Do you just end up with a small list of go-to options, and add a new one occasionally when you hear about something new and cool? Or do you do the whole parametric search + read all the datasheets thing for every project?

Anyway, I ended up with a disappointingly simple schematic for all that work.

Layout next, which should be reasonably simple, but both the main components have layout guidelines to follow, which is a new thing for me.