| December 27, 2018
No comments

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.

Category: Globe |
| December 4, 2018
No comments

PicFix

Here’s an issue that was causing me some grief:

In newer versions of MPLAB X, Microchip’s IDE, My PicKit 3 clone wasn’t able to supply power anymore.

Some investigation revealed that in MPLAB 8 and before, they didn’t used to properly check for “correct” voltage before attempting to continue programming. Which is great! But they fixed that.

Here’s the message it displays:

 

PICkit 3 is trying to supply 3.250000 volts from the USB port, but

 the target VDD is measured to be 2.875000 volts. This could be

 due to the USB port power capabilities or the target circuitry

 affecting the measured VDD.



The target circuit may require more power than the debug tool

 can provide. An external power supply might be necessary.


Connection Failed.

 

 

Cracking open the case reveals that it’s made by Sure Electronics, and there was possibly some nebulous licensing deal with Microchip to sell these, and then they got cloned and the deal evaporated. Or something. It’s hard to tell.

Oh look, a schematic. Relevant schematics on page 69 and 70.

I had a sneaking suspicion that there was a bad voltage divider somewhere that was causing ADC readings to come back too low.

Before having to properly poke around, this post confirmed my suspicions and made things super easy.

Near the linear voltage regulator, the AMS1117, there are two resistors named R17 and R24. They are 470 and 680 ohms, respectively.
Swapping the 680 ohm resistor with a 750 ohm is recommended. I didn’t have one, so I desoldered one leg and put a 50 ohm resistor in series, making kind of a tower on my board. Results in 730 ohms, but it seems to work. My PicKit can provide power again!

Category: Quick Tips |
| October 1, 2018
5 comments

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.

Category: uMesh |
| September 17, 2018
No comments

I Made An IoT

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.

 

 

Category: One-day Builds |
| June 2, 2018
One comment

PCBs of Unusual Style

Shallow

 

As a test, I designed a nautilus-themed PCB in PCBmodE.

 

PCBmodE is not your standard ECAD package. It’s a collection of JSON files that get converted into SVG or gerber files.

There are some limited tools to convert SVG files back into JSON, too. It can be thought of as forward- and back-annotation.

There’s no schematic editor. There’s no traditional PCB editor. The only interface is Inkscape itself. (Inkscape is an open-source vector software, like Adobe Illustrator)

The end takeaway is that these circuits are drawn, not engineered.

 

The whole repo is here. All of the JSON files are the source files, which can then be compiled into SVG (for viewing and some minor edits), or to gerber (for manufacturing).

 

 

The OSHPark gerber viewer says it’ll look like this:

 

 

And here is the final board:

 

It’s surprisingly difficult to photograph purple LEDs. It was suggested to me that they may have strong UV components that are overexposing that part of the image, so they usually show up as white or very light blue.

 

Rest assured, they are way more pleasing to the eye in person.

 

 

It’s interesting to note that the battery holder footprint was a Boldport component (it looks like a ladybug!). It’s designed for one of those cheap stamped metal CR2032 battery holders, but I don’t have any. It was easier/faster for me to grab some sheet copper and cut out a holder with tin snips.

 

The workflow of PCBmodE is a little bit jarring for someone expecting a standard PCB tool. It’s all laid out in the official docs, but I didn’t believe it until I tried it. Editing JSON files is almost the only way to interact with the software. You edit, compile, and view it in Inkscape. Some very small amount of things – Component position and traces, mainly – can be extracted back into JSON, but that’s it.

Even for outlines, the best method is to draw them in Inkscape, then copy the SVG paths and then paste them into the appropriate JSON:

For moving components around, there are a lot of SVG layers present for each component, but the extract command only seems to care about the origin. That little dot in the middle:

 

Three last things:

There’s also no “generate new board” command. Official recommended procedure is to fork one of the existing boards and modify. The docs are outdated, the sample is for an old version of PCBmodE that won’t work. I like BINCO for something really simple, or The Lady for something that uses every trick in the book.

Don’t use the official repo. This fork(as of June 2018) is the almost-official dev branch that has a lot of improvements (including Python 3!), and presumably will be merged back into mainline at some point. This command will install the proper one:

pip install git+https://github.com/threebytesfull/pcbmode.git@improve-test-coverage

 

And, finally, there is one issue that will prevent manufacturable gerbers. I described it here.

 

The next step

So, obviously this software requires some fussing, initially. It’s pretty nice once you have it set up, though. No issues, as long as you know what they are ahead of time.

What’s still a pain for daily use, however, is building usable circuits. Lacking a schematic and having to hand-draw traces as vector paths is painful.

So I quickly grabbed the first complete PCB available in Upverter, my LightBeam board. And then I wrote a conversion tool.

Here it is in Upverter:

 

And then in PCBmodE:

Workflow is now: Make a PCB in Upverter (or import it from something else!), Export as OpenJSON, convert it with my tool, then edit the PCBmodE JSON files as required to prettify them up, and transform them into something amazing.

The tool is here, pull requests / issues welcome. Only a small amount of available things to convert are completed, there’s lots more work that could be done.

Category: Interfaces, One-day Builds |
| April 2, 2018
One comment

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.

Category: LEDs |
| January 19, 2018
No comments

Clipping the Leads

Here’s a quick one.

 

I’m tired of having to solder programming headers onto projects that don’t need them after initial development.

 

So I bought a bag of clothespins for a couple bucks from China and went wild with some epoxy and Pogo pins.

Soldering made the epoxy fail faster than I expected, so I had to reglue it afterwards.

It works great!

The clothespins are ubiquitous on AliExpress. From the pictures, I expected them to be larger, and plastic. All good, though, these tiny wood ones worked fine.

It’s pretty sturdy on the programming headers. Clips on quickly, and doesn’t need soldering! Success!

 

To make this more repeatable and less like an epoxy-globbed-on mess, I took critical dimension measurements and mocked up something in Fusion 360 for future, more polished versions. They should be possible to 3D print, for all occasions.

 

Here’s the original duplicate half-clothespin, to be modified for any new debug header encountered. A full clothespin consists of two of these, plus a torsion spring. Download here.

 

Here’s a 5-pin holder, designed for the PIC header format, or any other 5 pin design. Download here.

Next I’ll probably do a 4-pin version for SWD that STM32 (and many other ARM) microcontrollers use. Nothing I have right now regularly requires larger JTAG systems yet, but I’m sure it’ll come. This system should work fine with those, too.

Category: One-day Builds |
| January 11, 2018
One comment

Storytime! A switch mode tale.

A lot of the switch-mode power supplies I’ve built have relied on Skyworks Technologies controllers. This is because they are very cheap, and seem to go obsolete almost immediately after purchase.

This is a quick story of bringing up a new switch-mode circuit from a different manufacturer to test its viability in some battery-powered devices.

I’m using a Richtek RT6150A buck-boost controller.

For a 3.3V output, buck-boost topologies are necessary when the input is a LiPo battery. The ~3.0-4.2V safe voltages for charge and discharge are perfectly bracketing the 3.3V target in a way that is about as inconvenient as possible.

 

Other than cost, the reason that I selected this chip was that it seemed marketed towards this exact application. Battery technology is written in the advertising materials, and the datasheet shows this:

 

Oh yeah,  perfect! An undervoltage cutoff. That should be good for LiPo protection.

so I drew a schematic like this:

 

And then sent it off as a one-off PCB through OSHPark.

It costed about a dollar.

 

 

I got it back, soldered it, and did a quick bench-test. Instead of cutting off at 3.3v like I intend, it didn’t turn on until close to 5v.

No good!

So I pulled out the scope and checked the voltage at VINA:

 

 

The input voltage was completely stable, so that wavy portion in the middle of the voltage divider wasn’t coming from the input.

Going back to the datasheet:

 

This was ambiguous, but hindsight tells me it’s not actually intended to be a voltage cutoff. This is just the power for the control circuitry itself.

What was happening was that the internal control circuitry was drawing enough current that the voltage at the middle of the divider sag enough that it hit its cutoff, and turned the chip off, making the voltage rise enough that it turned on again, etc.

This chip is advertised in Richtek’s appnotes as being good for LiPos because of that cutoff, I assumed, but it doesn’t actually work!

So, I bodged VINA to VIN, and now it works, albeit at the full range of the chip. That’s not exactly what I want.

The other thought is to use EN as the cutoff.

It’s supposed to shut the chip off at “logic level low” whatever that means for a wide input voltage chip.

 

Logic level is anywhere from 1.4 to 1.8v, which is annoyingly wide.

 

But I gave it a shot.

 

 

 

Some test results:

Channel 1(Yellow) is output, 2(Teal) is the EN pin, and 3(Purple) is the input voltage.

At 1.11V input, output is still disabled.

 

At around 1.59V, the output springs up to 3.24V:

 

Weirdly, as the EN pin gets closer to the theoretically 1.55-ish point where it’s supposed to turn on, output noise starts to hugely increase:

 

Until right at the logic level high point, the output voltage has almost a full volt of non-periodic, constant noise:

It’s possible that it’s not a coincidence that is right when the controller switches from boost mode to buck mode.

So again, let’s bodge this back into a manufacturer-recommended specification:

Replacing R3 with a 0-ohm resistor (or: a wire) gets this back into spec:

In this case, the output (teal) is still disabled until the input(yellow) starts to hit 1.50V.

 

From there, there’s a sudden switch-on at 1.56V to 3.2V output:

 

And it quickly rises to a 3.3V and stays there for the full range, up to 5V input:

Output ringing is a periodic 1V peak-to-peak for about 20ns, every 1us or so. This gets a little lower when the output is loaded and provides some damping.

 

So the moral of the story is that the Richtek RT6150A works quite well, but only when the datasheet is closely adhered to. Anything “interesting” in the design leads to unacceptable noise or unpredictable results.

 

In the meantime, the RT6150A seems to be on the way to phasing out. Stock on Digikey is 0, with a 16 week lead time for new parts. The catalog not-so-subtly hints at using the RT6150B variant, and the datasheet is almost identical. The glaring differences are a few added lines in the marketing copy on the first page saying that fixed 3.3V operation is possible by tying the feedback pin directly to the output.

Anyway, that’s my debugging story. Nothing was particularly novel or unusual, but it was a good process to document irregularities while abusing the chip.

Category: Quick Tips |
| December 13, 2017
No comments

An Extra Special Parcel from China

This is a slightly different post than usual. Typically, I try to only post progress that has already been done, otherwise it ends up as so much vaporware.

For an upcoming project, I wanted to order some parts, write some code, and then use the code to order more parts, but it’s taking a backseat at the moment. So I’ll write about the intended roadmap, instead.

 

For some backstory:

AliExpress is great. There is a ton of cheap stuff, but it is a littttle bit limited in stock. Popular items only.

Taobao is the answer to that. Chinese language only, but it has everything. Google Translate is your friend. They also don’t ship internationally, but there are reshippers that get around.

Reshippers/fulfillment services are starting to pop up everywhere. I have gone through DirtyPCBs’ service, and the price breakdown is like this:

$item cost + $magic shipping cost + $3 per vendor
+ $15 shipping fee + 15% declared value customs fee

 

That eats into the savings pretty quickly if you’re buying $2 semiconductors from 5 different vendors. That $2 vendor fee is the largest cost that is avoidable.

 

The obvious optimisation here is to find all items as you’re trying to purchase, from as few vendors as possible. Many will have a large amount of semiconductors, for example, but no easy way to sift through the matrix of what they’re selling and how it matches up to your shopping cart. That is the basis of what I’d like to do. I’ve written a rudimentary scraper that can grab search results and merchant data, but no overall design of how the interface should look, or how data should be displayed. Future me: probably going to use MechanicalSoup.

 

A good proof-of-concept to try and spur me on to start implementing this came up recently, when I got a generous offer of PCB coupon from Seeed Fusion. I’ve used them before (and bought items from the marketplace, too!), and they’re an awesome company, so it was very appreciated. They do PCBA, stencils, 3D printing, and CNC services too, so they’re positioning themselves as kind of a one-stop shop for prototyping.

I opted to get a few copies of Benjamin Vedder’s vESC project.

It’s a nice candidate for this because each board requires six expensive MOSFETs(IRFS7530) that cost about $7 each. Taobao lists them at closer to $0.80, although the quality is somewhat suspect.

These boards look fantastic, however:

 

I opted for yellow, expecting a loud, obnoxious colour, but this turned out to be a very pleasing orangish hue. I may use more of this soldermask colour in the future. Because it’s a 4-layer board, you can see internal layers in the fibreglass that change the look significantly, so I can add three totally different FR4 shades in the “Seeed Fusion yellow” entry in the colour palette I’ve been maintaining.

 

So this is currently in a mostly-shelved state. When I have a more pressing need for it, I will continue with the Taobao companion application (codename: TaoBeau), and attempt to build out the Seeed board with a $20 BoM cost instead of the Digikey cost of around $90.

Category: Organisation |
| November 10, 2017
One comment

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.

Category: Infin1D |
« Older Entries   Recent Entries »