A very quick post with a very long picture -- but what I hope is a significant milestone after a year of collecting parts and breakouts. After a few weeks of sketches and stacking boards atop each other, I think a design for placing the major sensing components on the back of a phone has emerged.
The central ideas behind this iteration, Iteration 8, are to
- sit on the back of a phone, using the phone's display and communications capabilities, and
- to have a very low barrier to assembly, ideally requiring a shopping list of boards from major long-term vendors, and an afternoon with only modest (mostly through-hole) soldering skills.
I think I've largely been able to keep to these design goals, and put together a candidate motherboard design (currently being fabricated) to serve as a test platform for this idea.
Though I didn't realize it until after I'd begun designing the motherboard, fundamentally the motherboard is simply an Arduino Pro Mini, a low-power off-the-shelf microcontroller for interfacing with sensors, connected to a Raspberry Pi Zero W, a high-power board capable of running a webserver (for the phone to interact with, to display data), communicating with the Arduino Pro Mini (for sensor data), while also itself interfacing with the high-bandwidth sensors: the FLIR Lepton thermal camera, the standard Raspberry Pi camera, the Hamamatsu microspectrometer, and the Magnetic Imaging Tile. The rest of the board is largely universal 0.1" headers designed with enough room that it should be easy to connect whatever breakout boards the user would like to the system, with a recommended set supplied. This makes the system very simple, expandable, low-cost, much quicker to put together, and ideally with a fair amount of longevity.
The expense of this simplicity is two-fold -- the first being size (the backpack will add at least 15mm of thickness to the phone, in addition to some area on the side of the phone for the Pi itself and an air particle sensor that will protrude towards the front (screen side) of the phone). The second is power budget -- the Pi consumes a lot of power, and my hope is to be able to keep it in a low-power state with the Arduino collecting and buffering data, then regularly wake it either to collect data from the Arduino (then sleep again), or wake for longer periods for user interaction, or to use the larger, higher-bandwidth sensors.
Hopefully in a few weeks when the boards arrive I'll be able to finally test these ideas, get a sense of whether this is a viable design, and begin putting together the prototype.
Below is a quick sketch, to scale, with the major components depicted, as well as how they "stack up" in several layers on the back of an example phone:
thanks for reading (this admittedly very short post)!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Hmm, have you considered using ESP8266 in place of both the pi and the pro mini? It's capable enough to serve a simple web page (and the JavaScript code for the actual logic for it), and should be able to handle the I²C and SPI sensors. You might add an I²C ADC chip for the analog sensor. It would save you both power and space.
Are you sure? yes | no
Hi Radomir, if one were to remove the camera, rewrite the FLIR Lepton driver for the ESP8266, and be okay with the device not acting as a wifi bridge, then it's possible that this may work. One of the goals of this project is to move way from designs that take a lot of hardware and software effort to get to work (I remember rewriting part of the core chipkit libraries to bring them partially compliant with the Arduino 1.x standard), to relatively mature environments with low barriers to entry, or that folks may already know. I'd rather design something that's relatively power hungry but easy for other folks to build, extend, and maintain, rather than design another unobtainium Arducorder Mini that's very hard for folks to build. In addition to the technical questions, I've become interested in these community questions, and the art of trying to balance the two in open source hardware projects.
Are you sure? yes | no
Fair enough.
Are you sure? yes | no