In Which Jarrett Builds

I’ve used a lot of solder paste, usually from one of those big syringes.

When depositing little tiny blobs of solder on a few hundred little tiny pads, two problems emerge:

1. That big syringe has a big plunger that really starts to hurt the heel of your hand after a lot of usage, especially when the paste is still a little cold from storage. And,
2. when it’s so challenging, accuracy of deposition goes down.

Yes, both of these problems sound really minor, but they’re actual problems! And solvable!

There are a few different strategies for paste deposition. One of them, which I had a mild infatuation with for a while but never tried personally, uses an air pump connected to a syringe. It drives out the paste with air pressure. Apparently, though, the compression of the air leads to inconsistent and ultimately disappointing results.

Another strategy is to make it electric and attach motor, drivers, and a control system on the back of the syringe. The problem I’ve had with this is that it makes the whole assembly heavy, and therefore difficult to accurately control. The syringe-mounted button also seems like it might cause a little bit of unwanted movement when it’s being pressed.

So, like all quick projects, I let it sit for years while I pondered the issue.

After deciding on a strategy that would allow me to put the least amount of effort into this as humanly possible, I bought the following:

DC motor with gearbox and threaded rod:

Brass heat-set inserts:

1mL syringes:

Copper tubing:

And a pile of electronics I already had kicking around.

I 3D printed a syringe-motor adapter.

I soldered an insert onto the brass tube, and then with the motor, I had a linear actuator.

Pile of electronics:

Neat.

I also glued the rubber gasket/tip to the copper tube.

The solder paste I had available is a couple years old, and really chunky/nasty. Solder paste has a shelf life, and paying attention to that is important.

Put it all together anyway:

Little bit dribbly at first:

But not bad for a first test:

Obviously not perfect, though. The mechanism stopped being able to force the crusty paste through the needle, and broke the (admittedly flimsy) 3D printed bracket when the motor tried to exit its situation.

Using the flimsy bracket as a mechanical fuse might not even be a bad idea to keep around for future versions. The real problem was the paste, it was toast.

This will definitely be tweaked a lot. I’ll add pullback to the software to prevent the nozzle dripping, and maybe some other features. But it’s a start!

I haven’t actually made an Internet of Things, thing, before now.

This is mostly just to throw some stuff together that I already had lying around. I’ve got a DHT11 temperature/humidity sensor, a WeMos D1 Mini ESP8266 dev board, a switch-mode power supply module, and a solar panel.

I turned it into an investigation on solar charging and ESP8266 power modes, while spending As Little Time As Humanly Possible on cleanliness, quality, or polish.

Yeah, this is super simple, and equally janky.

Threw it together in an hour with liberal amounts of hot glue.

Predictably, the solar panel was never able to supply enough juice to handle the startup current of the ESP8266, and it never sent any data points.

So phase 2 was to add a maximum power point tracker (MPPT) module feeding a Nokia battery as a reservoir.

This one worked! It lasted about 18 hours until it died.

I’m sending data to Adafruit’s free(ish) MQTT platform, also for the same spend-as-little-time-possible reasons that this projectlet follows.

That spike/drop in temp/humidity is exactly the time period where I get direct sunlight in that window in May, so that’s neat.

Uptime is recorded in tens of seconds.

Now there are three problems left with this system:

There’s no way to get an idea of battery charge until it dies.

The switch-mode power supply is a buck converter only, so as soon as the battery voltage goes below 3.3v (or maybe even above that), the output voltage cuts off, or possibly sags. I haven’t read the datasheet on this, so I don’t know or particularly care in this case.

Ideally, the solar panel can keep on top of the power usage. It doesn’t currently do this, partially because it’s sending too many datapoints (temperature does not swing wildly enough to justify once every ten seconds), and because I did not use proper deepsleep in my code. It’s just a while() loop that keeps the microcontroller chugging away at full bore.

So here’s the next update.

The ESP8266 has an ADC, but it’s limited to 1V max. With a max Lithium Ion voltage of 4.2V, I used a voltage divider of 1k in series with 4.7k and 10k in parallel. And then I realised that there was a built-in 220k/100k voltage divider designed for ~3.3v max, so I swapped mine out for a series resistor get into the 4.2v ballpark. This is all very approximate and I only had 680k resistors on hand, so 7 in parallel got me to 97k.

From my Switch Mode Tale, I happen to have a SMPS kicking around that is perfectly suited to the voltage ranges of the battery, too, so that goes in.

And, finally, the code changes were trivial. Another data point (battery) was added, and naive delay loops were changed to proper deep sleeps. This also required tying pin 16 to RST.

Still curious about battery lifetime, I commented the deep sleep mode out while running another test. This is still a while loop:

It lasted three days, and you can clearly see the spikes in temperature for a few hours in the afternoon as the sun hits the panel directly. And look at that lithium battery discharge curve!

I haven’t looked into my MPPT in detail, but that would likely be one of my next targets for investigation. I know it charges the batteries because I left it to do that for a few weeks in between tests, and the batteries were fully topped up each time. But I suspect it charges them really slowly, based on the lack of noticeable bump on the graph during sunny periods.

At this point, I took a brief hiatus from this side-project to do Important Things, and then it became autumn.

Using this power usage analysis, eventually, I will chip away at some of the possible optimisations. Some of the considerations described by Erik are obvious, but some of the others are quite clever. A mental shift to paying attention to the order in peripheral bring-up in a WiFi device is fun, and not something I’ve had to do much before. I will come back to this, for sure. Likely when I finish Rev 2 of my Sugar Glider board. As it stands, this side-project is in danger of going over my allotted five hours of actual build-time.