Hi — after getting shiny new boards last month, this month we’ve been back to grinding on code. I’ll do my best to make this interesting, but no promises.
Hardware
We got around to testing all of our mainboards from our batch of 50 (Yes, that’s 49 boards above. I have the other one.) 47 of 50 pass the basic hardware test with no issues—not bad. If you look closely you’ll see a few have an X instead of OK. The issues found:
- One board has a bad LED connection. Easily fixed with a hot air station.
- One board is throwing some odd initialization errors with the random number generator. Most likely, the hardware is probably fine on this one and this is some bug in the microcontroller manufacturer’s init code for the random number generator, but Jeremy’s marked it as a fail for now and will investigate it more thoroughly later.
- One board is not establishing the link between the two microcontrollers. This is probably a solder joint issue, as both microcontrollers work individually.
All in all, not bad for our first true production batch, and other than the random number generator, probably simple fixes. It’s normal to have a few issues to be fixed with some quick soldering rework—this is why we test everything. Having not used this assembler before, we’re really pleased, and that’s one less thing to worry about.
This is all checked on a basic test system we will be sending to our assembler, so these kinds of failures won’t be shipped to us. We’re going to have a more thorough test system that we run in Austin (Jeremy’s got the hardware and basic firmware support, but hasn’t written the test scripts yet), that will individually test various subsections of the board and measure power consumption.
Speaking of power consumption, Jeremy describes the production boards as “awesome.” Can’t characterize what the real world battery life will be yet, but with the fine control over data sampling and reporting we’ll give you (see firmware below), you’ll be able to pick your own balance between battery life, resolution, and responsiveness.
Mechanicals
On the plastics side, we were hoping to get first samples around now, but it looks like it’s going to be several more weeks. The molder has gotten through their backlog, and is finally starting our molds. We should have those samples 🤞 by the end of this month, and if they work well, we’ll approve getting the molds shipped to Texas and start full production.
In the meantime, we’ve still got code to write.
Firmware
Jeremy’s been working on the firmware directly on the orange production boards. We have the core of our configuration system working, which will give you fine-grained control over enabling sensor channels, setting if you want them to record to the database, and per-channel sampling rates—i.e. how Pickup collects and logs sensor data. If you want to read temperature once a minute, and light levels once an hour, and transmit it all once a day, you’ll be able to do it. If you want to monitor and record all sensors every 13 seconds, go for it.
Right now, the configuration format looks like this, but we’re going to wrap it in a friendlier interface:
The list of work done this month, in more detail:
- system-wide configuration of devices and sensor channels
- configurable per-sensor timing
- power management/sleep mode support
- automated test process
- Firmware updates over MQTT
Software
Here’s my production board, plus several from the previous batch (which only have mechanical changes so they won’t fit in the case). With all the extra Pickup boards I’ve got hooked up, I needed more colors in the dashboard.
The bigger work I’ve been doing here is in the connections between the different bits of software, how sensor data gets moved around, authentication, a graphing interface and a bunch of polish in general.
All these working boards are surfacing lots of fun bugs that we’re fixing, and I’ve been adjusting some things in the software due to new firmware. Pickup may be fairly flexible but its default plug-and-play experience requires tight coordination between hardware and software (and therefore Jeremy and I).
Accessibility
Another critical but underrated feature that we’re building in along the way is accessibility for people who can’t use screens and interfaces the way they’re designed for most people. A long-time backer (hi, Scott!) with a blind and deaf spouse impressed the need upon me when we were working on the Range smart thermometer. It’s not that hard to do—the Web and most computing platforms support alternative interfaces—it’s just a matter of being mindful and adding some information to all the UI bits to tell those alternative interfaces how to present them to users. What’s great is that this benefits all users—for instance, it makes it easy to move around a web interface with only a keyboard
The framework I’m using to code the app, Svelte, even reminds you where this information is missing, so all that’s required is that I care. Hopefully any of you who has an investment in alternative interfaces can help test Pickup’s accessibility when we release beta software. Give us a shout in the forum.
So it’s been a slow grind of late. Hardware is exciting sometimes, but mostly it’s just slowly doing more things with greater consequences. Next update will be 80% more exciting, I promise.
Crossposted from Pickup Kickstarter update #11