Archive for Projects

Watching Plants Grow

 

I’ve been into timelapse photograpy for a long time, often focused on driving the cost down by hacking existing digital cameras.

That follow up post (already written almost two years after the original work) promised project pictures that were never delivered, so here, I went spelunking in some nearly decade-old backups for them.

 

 

Recently, I came across the ESP32-Cam, which basically hits all of the cost/hardware requirements I was aiming for, nearly a decade ago.

It uses an Espressif ESP32, which I’m very familiar/comfortable with, and is about $6. The camera sensor is 2MP, which is small for images, but fine for video.

There are a lot of timelapse projects out there using this board, but none of them really have the features I’m looking for. Espressif even has an official “webcam” codebase that others have packaged up into cool projects. But here are my requirements:

  • A web interface to control capture / timing parameters
  • Serving up images over the web interface to check that those parameters are good
  • Saving images to SD card
  • Nonvolatile storage of the parameters, along with the current snapshot number, in order to gracefully recover from power failure
  • SD card images available to download over the web interface
  • Over-the-air updating
  • Reasonably well-laid out codebase that’s easy to hack on

Essentially, I want to be able to plug this into a hard-to-reach closet and not have to ever physically touch it again. Lots of projects have a subset of these features, but nothing has hit it all, that I have seen.

One of the other ideas I had to improve upon the typical timelapse design was to get the ESP32 periodically grabbing the real-world time from NTP servers. It’s set to run every half an hour, which is probably too often to make a difference that overcome the latency from hitting the NTP server. Regardless, it should keep average timelapse interval perfect over a long period of time.

So I hacked something together. Originally I used PlatformIO with the Arduino framework, because it’s quicker to get a project off the ground than the official Espressif ESP-IDF. The branch is still there, but I abandoned it after running into issues with partitioning, OTA updating, and the additional PSRAM hardware all working together. The main branch uses the ESP-IDF now.

It’s essentially a webserver that controls the camera. You can open up a page and modify settings, including timelapse intervals:

 

You can also get existing parameters:

 

And snap a one-off photo to check your setup without touching anything. That made this super easy to tweak with one hand, while holding a laptop with the other.

When a sequence is done, it’s easiest to grab the SD card and plug it into a computer to copy over the files. For longer sequences, maybe to check progress, it is totally possible to grab the images over the web interface. Just slow.

To stitch together all the images, initially I used this command:

ffmpeg -r 30 -start_number 1 -i %06d.jpg -vcodec mpeg4 -vf "transpose=1" -y movie.mp4

That results in a pixelated and honestly pretty crummy output. It’s fast, though.

This got much better results:

ffmpeg -start_number 1 -r:v "480/1" -i %06d.jpg -c:v libx264 -preset slow -vf "transpose=1" -y -f mp4 movie.mp4

ffmpeg is a little inscrutable, so the parameters that require tweaking warrant an explanation. Order matters, too – Some of the parameters affect the input, some affect the output, depending on position.

-r:v is the input frame rate, relative to the base (25 FPS) framerate. So a 250 frame video with -r:v 25/1 would be 10 seconds, while setting it to -r:v 50/1 would result in a 5 second video.

The -vf transpose option rotates the video. The ESP32-Cam’s camera is mounted sideways, but that’s a minor irritation.

To mount the device, tripods are the obvious choice. I created a quick, minimalist enclosure that allows access to the GPIO pins, SD card, reset button, and fits a 1/4″-20 nut that is compatible with most tripods. A Gorillapod, in my case.

 

For the video posted at the top of the page, here is the setup:

 

It was done with a picture taken every 40 seconds, 8 second exposure, low gain and brightness.

ffmpeg -start_number 1 -r:v "120/1" -i %06d.jpg -c:v libx264 -preset slow -vf "transpose=1" -y -t 00:00:08 -f mp4 movie.mp4

 

The -t option sets the end-time, there was a lot of “content plant” at the end that wasn’t moving much.

Future goals might include shoving the whole mess into a closet, along with timed control of the lights and a watering pump, and leaving it for a month.

POV Globe – Electronics

 

This is a fairly old project that I just wanted to document to current-state and provide a conclusion. See here for the old logs.

Some of the original design goals for this project were ease of design, and manufacturabilty. Ideally, the design would be clean and turnkey enough for me to be able to at least sell the populated PCB as part of a kit. I also didn’t want to spend a lot of time doing anything cutting edge enough to turn into a time consuming side project, as some of my designs are wont to do.

So here is where I started.

The board is 7cm in diameter with 0805 side-mount LEDs all around the perimeter, green on one side, blue on the other. The LEDs were too easy to see individually (right), so I used hot glue to create a diffusion layer (left).

In the centre, I decided to go the easy route and make the board battery powered. The cutout can hold three LR44 batteries in series.

After some hemming and hawing about how to mount them exactly, I found an acrylic tube with a 12mm ID (just barely larger than the batteries), cut a slope into one side so that it can be inserted into the slot and then rotated to lock in. On the PCB, there is battery spring on one side, and some copper braid on the other to hold the batteries tight and make electrical contact. This solution works better than it has any right to, it is fantastic but blows my “manufacturable” requirement right out of the water.

For driving my LEDs – twenty per semicircle – I used a TLC5947. It’s a constant current, 24 channel PWM LED driver, controlled over SPI(a requirement for speed). There are two of them, and they seemed to work well, with one caveat that I’ll get into in a bit.

There is an interesting power section that I never ended up populating. The goal with it was to have a switch mode power supply attempting to boost the battery voltage to 4 or 4.5v from whatever voltage the batteries sag to. The idea being that with fresh batteries, it wouldn’t be doing much of anything, but as the battery runs down (internal resistance gets higher), the power stage attempts to pull more and more current to keep the output rail steady. The circuit ended up working fine with all of that jumpered over and direct from the battery, but it was an option in case that hadn’t turned out.

I also had a clever system on there to ensure proper polarity to my circuit regardless of how the batteries were hooked up, but again, didn’t matter enough for this version to use.

The TLC5947 has an SPI output pin to allow chaining multiple chips together, but naturally, it would halve the refresh rate I’d be able to get. I ran a trace between the two chips, just in case, but I was also able to avoid using that. The dual effective SPI ports I managed to get working(written about in a previous log) saved me from that.

Early tests were promising – I quickly got a recognisable image of the world showing.

Introducing blue turned it into an unrecognizable mess, though. All further testing stuck to green, for now. The problem is that my hot glue light diffusion is too good, and allows light to be directed back through the sphere. Some sort of baffle on the inner side of the LEDs is needed.

An additional problem that I hinted at in the last logs is that my vertical resolution isn’t really high enough. The world map is recognisable, if you know what you’re looking for, but it isn’t fantastic.

And the final problem, the real deal killer: the TLC5947 blanks its output before displaying the next value. That is, a channel displaying 255 (full on) when a new value is sent to it, even if the new value is the same. It will go 255->0->255. That’s why you can see vertical gaps in all the images I’ve posted. This is mentioned nowhere in the documentation, and is just poor design. So I future version will have to rethink this portion, too.

 

For the mechanicals, due to an unfortunate move, the old system got a little bit damaged and I 3D printed a replacement. This one also uses a dirext drive brushless DC motor instead of the old brushed motor and DC motor. Again, just for fewer components and faster to put together.

 

It worked well, other than some harmonics causing a lot of vibrations on some narrow bands of frequency. Future versions would also have a proper magnet holder, my hand is not a permanent solution.

A Matter of Time

I’m on another clock kick. More of a wristwatch this time.

The dream is to have a couple metal bars floating in oil, and when a button is pressed, they float to the appropriate hour and minute positions.

For an initial version, I’m paring this way down to just a single indicator hand.

On the mechanical side, I start with some preliminary sketches.

There were many more, with very little polish in any of them. They’re just to get the mechanicals down and direct the overall thrust of the design.

Watch crystals are quite inexpensive from China, so I picked up a selection of sizes, and while waiting for shipping, I modeled and 3D printed some tests for the three most likely candidates. Shown here are cases I designed for sizes 30mm, 34mm, and 38mm faceplates, but you really can’t tell that they’re different sizes in pictures. The 38mm one seemed to fit best on my wrist, so that’s what I went with.

Rolling my sketches into the CAD, I came up with this:

The main body is just a shell with internal threads, and inside there’s a stack-up consisting of:

  • 1.2mm crystal face
  • 37mm OD x 1.5mm o-ring
  • Double sided o-ring retainer
  • Another o-ring
  • 15x3x1mm neodymium magnet
  • Faceplate PCB
  • Control PCB
  • Coin cell battery
  • Threaded cap

Dimensionally, it’s a very tight system. It doesn’t really fit with the battery, so stuff will have to be moved around. The o-rings are there to seal in the oil, which is kinda fun.

Jumping to the electrical side, I need some electromagnets.

A guy named Carl Bugeja has designed coils drawn out in PCB traces to make a PCB motor. He shows off the design a lot here.

Included, naturally, are a set of gerbers which were worth ordering to play around with.

I tossed a magnet on there and was able make it jump around the coils using a small bench power supply. The resistance at each phase was about 12 ohm, the same value that Carl Bugeja measured. Each phase does go through three entire coils, however, so assume 4 ohms per coil.

The coil pattern is illustrated quite well with Carl’s coloured gerber export:

Application of the right hand rule shows that as current goes in a clockwise spiral direction (curl your right-hand fingers in that direction), your thumb will point in the direction of the magnetic field, out of the screen. Interestingly, the ordering of the coils on the layers isn’t from top to bottom. Carl ordered it from layer 1(top)->layer 3->layer 2->layer 4(bottom). Probably to (very very slightly) increase the length of the current path and therefore the resistance of the coil.

To drive a coil with any polarity we like, we need a standard H-bridge circuit. A future version might do some interesting stuff with that, so the fine control that an H-bridge provides is kinda cool. Generally an H-bridge consists of a couple matched pairs of transistors of opposite substrate. Poking around, there’s a single chip MOSFET solution that looks suitable, the VT6M1.

So here’s a quick PCB layout of how that would work:

But of course, just dropping that into a board is boring! We’re going to make a pretty PCB, we might as well go all the way! I’ve spoken before about PCBModE. Using my tool to convert the above PCB into a compatible format, I pull it into PCBModE, cleaned it up, added some electromagnetic spirals, and a little bit of flair. There are solder pads to hook this PCB up to another PCB, containing all the brains.

Figuring out a compact way to drive all those connections is somewhat challenging. With six coils around the perimeter and one in the centre, a “drive high” and “drive low” connection for each side, there are 28 signals, plus power and ground. All of those need to be transferred out to a “controller” PCB, so I added those green teardrop solder pads. The idea being that pins are to be soldered onto them, and then pushed into through-holes on the controller PCB.

For the controller, after all of the through-holes that connect to the above-mentioned solder pads are placed, space is very tight! Investigation of various shift registers and their sizing yields no encouraging results. NXP has a cool line of miniature 74HC series logic, but even those don’t fit in my given space.

Fortunately, there is a nice STM32 part I was able to squeeze in.

Despite actually being designed in ECAD software, I think it turned out quite beautiful in its own way.

Some first revision woes:

In retrospect, this was a terrible way to design the electronics. By putting the MOSFETs on the faceplate PCB, I maximised connections needing to cross to the other PCB, and minimised space on the controller by filling it up with through-holes. By crossing with the coil connections directly, I would have needed only two wires per coil, instead of the six that the H-bridge is requiring (plus grounds).

An unregulated coin cell is just about the worst possible power supply for a miniature, portable, long-running device that can’t be opened easily, and leaks oil when it does get opened.

Additionally, I was rushed to get PCBs out and forgot to add a button to activate the watch face.

Next version, with more time, will include improvements for all of the above, as well as a proper external RTC, and LiPo battery circuitry.

Jumping back into the mechanical side:

Everything was 3D printed to test fit. Surprisingly enough, threads worked pretty well. There was a ton of stringing in the internal threads, though.

Initially, I was using a knife to clean those up, but that got old quick. Additionally, oozing from the print of the outer threads made it a little tough to mate for the first few cycles. So I printed a tap. You can see the taper on the leading threads, and the notch to clear out the chips.

That worked great! Passing it through the system a couple times made the threads work easily.

Here all the non-electrical components:

 

 

Here is the faceplate PCB:

 

And, assembled:

Testing the coils directly with a benchtop power supply once again made the magnets jump around.

And then adding the H bridge transistors and testing with a low current signal to control the direction of the magnetic field.

Status: super cool. Listen to that click!

For prototyping, everything is 3D printed. The goal would to mill it all out of aluminum and then anodise it dark blue.

The o-ring holder needs to be lathed or otherwise made out of a solid material, too. 3D printed parts are going to have a bad time if I try to use them to seal an oil filled cavity with porous plastic.

 

I got the endorphin hit I needed out of this for now, though – Some interesting concepts have been demonstrated, and perhaps I’ll come back to it another day to add polish.

Infin1D

This is a follow up from Infin1D, Rev 0.5, where I threw together a proof of concept in a few hours. This is the one where I spent some actual time on it and built a base that, while still quite rough, can be incrementally improved to arrive at a final product.

This miiight have been the original inspiration I saw, but the video link is unfortunately dead.

Right off the bat, I should mention that PCBWay kindly sponsored the 4 layer PCB for this. In addition to using them for most of my personal stuff, I get more complicated professional boards assembled by them as well. The quality, speed, price, and communication are all better than what I’ve gotten domestically. So I’m genuinely happy to plug them, they rock.

 

 

On to it:

I mentioned previously that I’d like to use a scanner sensor instead of the easy line sensor module I had before. That previous module was 128 pixels long, greyscale, and $20, but also well documented, ubiquitous, and easy to use (mechanically and programmatically).

A linear CCD sensor out of a scanner, on the other hand, is almost the complete opposite. It’s huge (107,000 pixels long), poorly documented, electrically hard to control, full RGB, requires external optics, and needs to be mounted to a circuit board. It is also only really available via Taobao, but it is about $7 in singles. Or at least, the one I chose is.

I started by scavenging a bunch of scanners and seeing what was inside. Most of them happened to be the Epson Perfection 1250. I guess it was just an insanely popular scanner.

Searching “Epson Perfection 1250 Service Manual” yields excellent results, so this particular RGB linear CCD is a 22-pin package called ILX555K.

The main processor chip on the PCB is the National (now TI) LM9833, which is a little ridiculous. It contains an analog CCD reader, DRAM storage, high current stepper motor outputs, a USB interface, and even extra helper functions like paper load detect. Basically a single-chip scanner brain.

Initially, I didn’t even have to do any proper hardware hacking (sad day), because there are Linux drivers to talk directly to the chip. It uses something called SANE, an easy Linux scanner interface. SANE is actually a really nice codebase to hack on. Well laid out, clear, and simple.

There are also convenient Python bindings!

First:
sudo apt-get install python-dev libsane-dev sane-utils
git clone https://github.com/python-pillow/Sane
cd Sane python setup.py build
sudo python setup.py install
sudo pip install pillow
sudo pip install numpy
sudo mount --bind /dev/bus /proc/bus
sudo ln -s /sys/kernel/debug/usb/devices /proc/bus/usb/devices
sudo sane-find-scanner
> ...
> (vendor=0x04b8 [EPSON], product=0x010f [EPSON Scanner 010F]) at libusb:001:002
> ...
sudo nano /etc/sane.d/plustek.conf

That file gets modified with the found USB vendor/product/etc info.

And you’re done!

Running scanimage will run the scanner, including homing and making the carriage move, but it doesn’t provide the granularity we need. The source for that provides detail around line 1862, probably calling feed() or reset() / initialise cmd. Sending the initialise byte for a long scanner homing sequence is still pretty high level, so it must be handled within the IC.

That was a fun detour, but ultimately not what I wanted out of the system.

So I threw together a really quick PCB, and I made many mistakes. But that’s okay, that’s what revision 1 is for.

And it works! My initial firmware can display images and I also wrote a bitmap generator to save to the SD card.

A rudimentary interface:

Obviously lots of bodges had to be made. Mostly because of the many voltage rails – the sensor has 5V signaling, while the CCD itself is charged with 12V, the microcontroller is 3.3V, and there’s the whole 5V / battery voltage mess. So this board is more bodge wires and hot glue than PCB at this point.

So how well does it work?

Well, here’s another difference between the original module I used and this sensor: The sensor doesn’t have an integrated lens.

Due to ubiquity, I picked up an M42 camera lens mount for a couple bucks and found a $20 lens on Craigslist. The M42 lens is an old 35mm standard, which is coincidentally just the size of my sensor. Used to be very popular too, so good deals can be had.

However, I have not yet designed a chassis, so anything the image captures will be a blurry mess.

One more issue is that I’m still tweaking the hardware around the analog output. The sensor datasheet recommends feeding its output through the base of a BJT transistor as a sort of transimpedance amplifier. It’s kind of a strange way of doing that, so I’m playing around with proper op amp methods to do that consistently and repeatably. That requires a fair amount more tweaking though, as the datasheet has no information on the nature of the output that is expected. That’s just a matter of putting more time into the investigation, but in the meantime, I have poor dynamic range.

So here’s the first test image that came out of it:

 

The scan is the red channel only, from left to right. Starting with something dark covering the sensor, and at a very obvious point in time, I removed it and put an object centre of the sensor. I would consider that a success, albeit not as pretty as I’d hoped.

Here’s the object:

In addition to the many above changes, some software updates I’ll write down the line are to integrate better the two obvious viewing modes: waterfall, and histogram. The histogram mode is useful for getting focus right, and then switching over to waterfall mode (as shown above) to see images.

Histograms, similar to the feature that is often available in DSLRs, could show the sensor input intensity as a vertical line on a graph, with pixel position on the horizontal. The steeper the histogram, the sharper the focus.

Summertime, and the livin’ is easy

People often ask me, “Jarrett, what is the Best Thing in Life?”

I’m not sure why people keep asking me this, but depending on my mood, the answer is one of two things: Floating on a lake, or swinging in a hammock. At peace with the world.

Frustrated by this bounty of choice that I just couldn’t narrow down, I began righting this wrong in the world.

 

So I bought a boat.

 

 

And I bought a hammock.

 

 

 

And I bolted them together.


It even got me a sweet discount on the boat.



In truth, it actually took several false starts to build this successfully. Part of the challenge was that I wanted to avoid making any permanent modifications to either of the two structures, and the other difficulty is that while mulling over the challenges, well, I had a hammock in which to ponder design decisions. It’s nigh impossible to exit a hammock once you’ve settled in: fact.

The hammock frame is made out out of steel tubing, but the pontoon boat’s frame is aluminum. This made things a little challenging. No welding, really.

 

My first attempt used some steel flat stock.

I used a hydraulic press in an only sort-of-sketchy set-up to bend them in a half circle to go around the hammock frame’s steel tubing.

 



While putting any kind of weight on these, they’d bend distressingly, and have a sort of spring effect that I could see multiplying forces in weird ways, so I decided to abandon that route.

That made me sad, though, look at those bends!

 

In parallel with the above, I also picked up some straps and built a method to fasten them around the pontoons.
Aluminum tube, a slit, and some filing (oh so much filing) did the trick, along with some new holes, bolts, and cotter pins.


Also positioning the whole contraption without mashing the pontoons against potentially sharp machine shop floor was tough. I finally settled on this lumber solution, which helped me see the final fastening solution.



Back to the scrap bins, I found nearly the identical black anodized aluminum tubes that the pontoon boat is made out of. They slot right into the existing frame and couldn’t be more perfect. I hear they’re from an old bedframe.

First I tried to bend one.

 

Then I tried harder to bend it.

 

Naturally, I kinked it, but I continued to try to bend it, this time using a convenient streetlamp garden decoration.

 

I still couldn’t get the bend angles I needed! Just not strong enough or heavy enough or clampy enough! I abandoned that attempt.

So attempt number, whatever.

I tossed two more of those scrap tubes into the boat frame, and clamped it on with some u-bolts.

 

Well that was easy. It brought the hammock a liitttle higher than I really wanted, but I decided to gopher it and fix it in rev 2 if it was a disaster. Summer is running out.

 

Before launch day, with much thought and much more relaxing hammock meditation, I decided that the boat tooootally had enough side-to-side stability, and that I’d have more issues front-to-back. This is because the hammock in resting position really wasn’t too much higher than the original boat’s seat, but the leverage on the hammock’s front/aft mounting points was way further out than the pontoons.
This later turned out to be completely correct.

But, burn that bridge when we get to it! I will probably add an outrigger to the back of the hammock frame. The water wings and pool noodles are not intended to be used, they’re just there as a last resort hammock rescue device, which we didn’t need.

And grab a couples friends and off we go.


Here’s the maiden voyage:

 


Spoiler:


But with a little more careful weight distribution, it works! It actually works really well, I was kinda blown away. It’s pretty much the best thing ever and I can’t believe it didn’t kill me.

Bliss.

POV Globe – The Mechanicals

The mechanical design for this project follows the “as quickly and easily as possible” maxim even more so than any other section. I used flat pack laser cut design strategies that results in pieces that snap together. I like that because it could in the future be turned into a kit reasonably easily, and in the meantime, it’s just a quick way to design and iterate.

For this first version, aesthetics plays no part, I just wanted to get the PCB mounted and spinning, along with an appropriate motor.

I used off the shelf mechanical components wherever possible, too. Standard bearings, shafts, collars, and couplers. Oh my.

Coupling the PCB to the drive shaft was a challenge that went through a few ideas to keep it manageable. Something off the shelf, or quick and cheap to manufacture. 3D printing is right out. This picture illustrates the problem, along with a laser cut mock up of the PCB:

One of the solutions I explored was to use clevis pins, intended for RC helicopters.

I found some aluminum ones and some nylon ones, but the former ended up being unsuitable for size. The nylon still wasn’t perfect, but here’s a tip for when your shaft is inappropriately large:

You can grind down steel rods to make a serviceable cutting edge, turning it into a poor-but-functional drill bit. Then they’ll drill right into the nylon.

One more issue was battery holding. Ideally, I wanted a cylindrical battery (or batteries) held longitudinally in the centre of the sphere. That seemed best for keeping the spinning disk balanced. For electrical reasons, I chose three LR44 coin cells stacked up to make 4.5v nominally.

After much fruitless battery holder searching, I grabbed a 12mm ID acrylic tube, and cut away part of it such that it could be fit into the PCB and then twisted to lock it in place. Like so:

That actually locked together pretty solidly, and I added a battery spring to the PCB to hold the batteries together.

For the overall frame, I tossed something together in Fusion 360:

With the very first cutting, made from totally scrap laser material – mostly acrylic, but some plywood in there for good measure – I found a minor setback: I had the wrong belt size.

I’m not sure if I calculated wrong the first time, or did some redesigns after purchasing my belt or what, but a second calculation did confirm that my on-paper expectations should have matched my physical fit. I had a 300mm belt, but 82mm between centres at the middle of the adjustment distance, so there was no way that was going to fit.

A 200mm belt proved much more suitable and revealed the next issue, which I vaguely suspected would crop up.

First of all, the system worked. Laser cut pulleys work great, I’ve used them before on other projects, and my tension and belt driven design seemed good.

When that main shaft got split and attached to my PCB mock up, however, the shaft was no longer properly supported.

The belt put leftwards force on the shaft (1), causing it to cantilever in that direction (2), and then cause the pulley to rub against the bearing block (3).

I was hoping that the two bearings above the belt would fully constrain the system, but alas, there is too much flex in the shaft or slop in the cheap bearings, with not enough distance in between them.

So, version two. This time with a supported shaft on either side of the driven pulley. I was trying to avoid that because the design and assembly both get a little more complicated.

One more change was getting rid of the clevis pins. They rattled and I didn’t like them. Instead I swapped the smooth shafts out for D-profiled versions, and laser cut a notched circle to couple with the PCB.

After cutting and reassembly, it works great!

No more mechanical changes need to be made for this prototype to demonstrate that it works. Next section!

POV Globe – The Software

Persistence of Vision globes are a relatively simple project that everyone has to build, it seems. The fusion between mechanical, electrical, and firmware domains lead to some interesting challenges that are deceptively difficult to overcome.

It’s a great project with a low barrier-to-entry, but it’s also easy to put your own spin on it. Heh. Spin.

Teaser:

This post will only focus on the software (embedded and desktop), with other sections to follow.

Initially, the rough code flow for the PIC microcontroller for this was going to be:

  1. Rotate Hall Effect sensor past a magnet, sending a signal to…
  2. An input on the PIC, generating an interrupt
  3. Copy a timer’s internal value to a variable
  4. Clear the timer
  5. Divide the variable’s value by horizontal pixels to get transition times
  6. Set an interrupt at the next transition
  7. At interrupt, change the interrupt to trigger at the next transition
  8. Set data pointer to start of the vertical pixel data array
  9. Send out data at pointer via SPI to LED drivers
  10. Goto (7) until (1)

But that was before I discovered a new, amazing peripheral that some PICs have! Even the PIC16F1619 that I happened to be prototyping with.

It’s called the Angular Timer, and it’s pretty much designed for these applications.

The process is now:

  1. Set up AT with input, period, and and interval interrupt settings
  2. At period interrupt, set horizontal data pointer to zero
  3. At interval interrupt, send vertical line data at pointer via SPI to LED drivers
  4. Increment horizontal data pointer
  5. Wait

Substantially simpler, and much more responsive than polling and manually changing timers would be. The only thing that’s missing is a DMA peripheral, which only a few of the 8-bit PICs use.

This link to all of the files, code, firmware, mechanicals, and PCB are all on the Github repo.

In lieu of an elegant image update method for Revision 1, everything is hard coded into the firmware. The world map for the globe is stored as a set of arrays, and generated by a Python tool I wrote. In the tools folder of the above Github link, there is complete documentation. The gist of it is that you can pass it a PNG image, and it can process that image in a few different ways and spit out another PNG, CSV, or generated C files. Then simply include that C file in your firmware when programming the project.

uMesh

I’ve been working on an ESP32 module.

Part of the problem I’ve been seeing with inexpensive IoT dev boards, is that the design around the power system hasn’t been very good. Here’s my attempt to fix that. This is a battery-ready module with a proper lithium battery charge circuit, lithium battery protection circuit, power supply, and antenna, all in a 1 inch by 1 inch package.

The goal is to have a tiny, inexpensive module that can immediately accept a battery and be deployed in the field, along with 30 of its mates.

The battery/power circuitry is surprisingly complex, which is why the built-to-a-price-point applications often don’t have the “proper” battery control, opting instead for “good enough”.

And when I say tiny, I really do mean tiny.

 

The main interface to the world (other that WiFi or Bluetooth) are castellated headers on the left and right side. Those grant access to input voltage, battery voltage, output voltage, TX/RX pins, bootmode selection, and a few GPIO. Because of them, this module can be soldered directly down to a larger host board if necessary, and can even provide regulated 3.3V output to it if given battery power.

What sets this apart in terms of battery handling are a few things:

  • There is a buck-boost power supply to provide a constant 3.3V to the ESP32 through a battery’s entire range (3.0V-4.2V)
  • There is a cut off for battery when it hits 3.0V, to prevent over discharging it
  • When the module is plugged in (through castellations or through the USB connector), it will switch over to using that as a power source. It can be hot-swapped
  • Also while plugged in, there is circuitry for constant-current/constant-voltage charging of the battery
  • The battery will still charge while the device is switched off

The battery just solders on to some pads on the back. Any size of single-cell will do, although the programmable charge speed relates to a resistor value that is soldered at manufacture time.

 

The USB port is for power/charging only, and has unconnected data pins. I also somewhat expect this microUSB port to shear off at some point, as they have kind of a history of doing that.

For the microcontroller, I’m using an ESP32-PICO-D4, driving a metal stamped antenna for 2.4GHz through a pi filter and 50 ohm impedance matched traces.

I haven’t really considered applications just yet, but it certainly does fill a niche for most IoT projects, given that a battery is usually necessary.

While waiting for shipping, and personal time to build it up by hand (mostly the latter though, Oshpark is awesome), I wrote an assembly and bring-up manual. It’s currently clocking in at 17 pages, but that includes a lot of reference. I’ve uploaded it as PDF here. That includes full schematics, part positioning information, net list, and BoM.

Here’s the Oshpark link to the project where it can be ordered (or gerbers downloaded too). It is a 4-layer board, and costs $10 for three.

Soon, I’ll write about programming it in an extremely sketchy way, programming it with the programming host board I designed, designing and tuning the antenna, and how to design it into a larger project.

LightBeam

In the deep, dark, depths of my project “to-do” list, I’ve always had a persistence-of-vision bicycle wheel light penciled in. I felt capable of doing it many years ago, and indeed, documenting the wiring was one of the driving forces for starting this website, but never got around to building one.

Eventually, products like the MonkeyLight came out, which did everything I wanted and more. Because “having the finished product” is rarely the goal of my projects, the very existence of a commercially available solution is sometimes enough to stop me from bothering.
For reference, the good version of MonkeyLight is $1000. Highway robbery! It is a great looking system, though.

But in August of 2017, I found a 32-LED bicycle spoke light on AliExpress. The cost at the time was $4.30.

Even now, it’s less than five dollars! That’s ridiculous! I can’t get individual components for that.
The only problem is that it displays preset patterns, and nothing more.

So I’m going to be upcycling! Get it?

And so I bought two.

 

Here are a few terrible pictures of what they look like in action:

 

There’s the top and bottom. Fairly straightforward. Light-dependent resistor and vibration sensor feeding into a microcontroller.

It’s super hard to photograph white soldermask in a way that displays the traces. A combination of that and buzzing pins out results in a schematic, like so:

U2 is probably (similar to) an AT24C02, an EEPROM chip, which isn’t populated in this PCB. Cost reduction on display! There’s an associated pull-up resistor and connector, also missing. Presumably there’s some model out there where you can plug in an I2C device and talk to the microcontroller, or add data to the flash chip.

 

The other one is probably an EM78P153B, based on its pinout. Or very similar. Depending on the exact model, it’s either one-time-programmable memory, or masked ROM from the factory. Either way, there’s nothing I can do to its code. So, removal it is!

It’s interesting to see microcontrollers that rarely come out of China like this.

 

I have a pile of PIC18F14K50, so I threw the footprint onto a small board and headers that matched the 1.27mm pitch of the original microcontroller. I was using Upverter for this PCB, and it provides a pretty neat histogram:

 

After that, gotta see if it fits, using the convenient laser cutter on hand.

 

 

It most certainly does not! So the microcontroller was swapped with a smaller one, the PIC16F1619.

 

And it totally fits, so off to OSHPark it goes. You’ll notice how neatly the traces were able to be routed on this one. The PIC16F1619 is one of the newer PICs, and they all have something called Peripheral Port Select. Basically, any peripheral can be reconfigured to any pin. It’s pretty fantastic for simplifying board layout.

 

 

Receive boards, solder, inspect, looks good!

 

And then at the same time, remove old microcontroller…

 

…add new flash chip and headers…

And then solder the whole thing down.

 

 

Feel free to fork/download/whatever the hardware files from Upverter, here. I’d be pretty stoked if someone else made some of these, too!

Another hardware update and software is coming in another post very soon. It’s a bit of a tangled web of interrupts, so I’d like to document it properly.

This PCB mostly worked, but the (optional) Hall effect sensor was bad and I changed it. And, final pictures of the result! That’s pretty important.

Infin1D, Rev 0.5

Before YouTube existed, I saw a video online. There was no spoken dialog, just subtitles in Japanese, with upbeat music in the background. It shows pictures of point-to-point soldering of a document scanner’s sensor and some sort of microcontroller. Then the single line sensor is put into a box (with a lense) and taken for an adventure.

I’d love to find this video again, but the main takeaways were that by reducing your camera to one dimension, you can fake the second dimension to create infinitely long images.

The creator of that original video set it up beside some train tracks, and got a long image of an entire train as it drove past the camera. Similarly, you could put it beside a road and get images of cars, or in the playa at Burning Man and capture the eccentric costumes as Burners ride past on bikes.

 

I wanted to build a quick test. Lurking in my parts bins, I have a single-line camera module, and a massive pile of old LCDs. For this, I selected an Arduino shield labelled MCUFRIEND 3.6″.

Searching around reveals that this model doesn’t actually seem to exist, but okay! The standard method of most Arduino LCD shield driving is to find example libraries that look like they have a reasonable chance of working, and then try them all until something does. I had to borrow an Arduino, because I’m not a huge fan, so I don’t even own one. How embarrassing.

In this case, the official-looking repository by prenticedavid is here, and GLUE_Demo_400x240 seemed to do a good job of driving this one. The code initialises it as 0x9327, which is the ILI9327 LCD driver. The datasheet for the ILI9327 is very good, so I may keep the LCD and write my own drivers for whatever non-Arduino architecture I eventually go with.

I did attempt to follow the maze of #defines in the Arduino library code, but I don’t recommend anyone do that if they value their sanity. I also put a logic analyser on it to grab just the output; this resulted similarly convoluted and unhelpful results.

 

 

While I’ll eventually be using a sensor designed for document scanners (lots more on that, stay tuned), the TSL1401 is a bespoke solution good for this test.

 

All-in-one sensor, lens, and brains that take logic level timing, and spits out analog values. 127 pixels tall, greyscale, and tiny, it’s objectively kind of bad, but fits the bill for now. I got it up and running in an hour or two.

 

Cool! That means I have a reference implementation. I’m not running this on an Arduino in the final version, but it got the job done in a quick-and-dirty way.

The whole thing was modeled up in SolidWorks, along with dimensionally accurate stand-ins for the electronics.

 

There are two 3D printer parts, adapted from the models of earlier jigs I’ve done, in keeping with the ethos of this test: quick and dirty.

I typically design around M3 screws, and used brass heat-set inserts to turn 3D printed cavities into threaded holes. As much as I dislike 3D printing, it has its uses.

 

Both halves of the 3D printed enclosure failed while doing some of the top few layers, but the baseplates are there so nothing that can’t be fixed with some standoffs and hot glue.

 

The results from this test project, predictably, are pretty bad.

This is a handheld scan across my keyboard.

 

As a stepping off point, it’s served its purpose. Here is an incomplete list of changes that future prototypes will feature:

  • A better microcontroller. Probably an STM32F1 or STM32 F4 series. I like the flexible memory controller, which can be used to map virtual memory regions to LCD driver chips.
  • A better sensor. The current one is only 128 pixels tall, greyscale, poor quality, and relatively expensive for what you get.
  • UX – rotary encoders, buttons, LCD widgets:
    • Start/stop capture
    • Speed up/slow down scan/capture rate
    • Integration time adjustment
    • Post capture stretch/compress
    • Histogram
  • Saving to SD card
  • Battery power

Changing the sensor might not actually make it to the next rev, it’s a big project on its own. Sourcing a sensor through Taobao probably, figuring out how it works, driving it, building a board to work with it, and all the mechanical work of lens selection, mounting, and measuring.

Either way, I’m happy to leave this for now, and return to it when I have cleared out some of my project backlog.