Arducorder Mini Update: Sensor Board Mega-Update, and Capacitive Touch Wheel

Hi folks — two exciting updates to the Arducorder Mini project! The first is a mega-update on the sensors, including this video testing out the magnetic field sensor by detecting the magnetic fields from the transformer in a soldering station!

The second update (fresh from this weekend!) shows the capacitive touch wheel working, with a test visualization I wrote. Looks beautiful!

The full updates can be seen on the Hackaday.io project logs. Thanks for reading, and stay tuned!

Arducorder Update: Video and Sensor Board Assembly

Definitely making serious progress! Here’s a 2 minute video, the first for the Hackaday Prize, which describes the concept and initial prototype:

And a new project update describing the assembly of the first sensor boards can be found here, where all of the project logs can be found on the Hackaday.io build log for the project.

7069221405492908853

The Hackaday Prize and the Arducorder!

hackadayprize

I think it’d make a great story to say that the fellow who designed real (open source!) science tricorders made it into space, and so I’ve started the next chapter in the project — entering the hackaday prize to win a trip to space!

There’s something about a near-term fixed deadline that helps turn research projects and prototypes into complete and functional devices. The hackaday prize prototype has to be working in just over a month, and complete in a few months, with regular milestones on the way. This challenges you to be fast, efficient, make your mistakes cheaply, and make interesting but safe design choices to ensure that the design is completed on time. I confess that I’ve been excited about exploring the space of open source science tricorders, and so I’ve incorporated a lot of hot-off-the-press components into the designs that in many cases don’t yet have a lot of support or examples to work from. This makes for interesting and high-risk experiments, but it doesn’t lead to the end-game that I get so many e-mails about — actually having an inexpensive science tricorder-like device in your hands. Hopefully this will help change that.

I’ve redesigned an open, inexpensive, modular, mini version of the Arducorder — this time with more processing power, and transitioning back to a bright, beautiful OLED display. Part of the requirements for the hackaday prize are documenting your project, and I’ve taken this further to document the entire process from creative sketches, concept, and industrial design, to taking those designs and making them real. The first four project logs can be found here. This means much more frequent updates in the weeks and months to come, and I’ll post the links to new project logs here on the blog. The first logs are:

Step 1: An Introduction and Background
models

Step 2: Concept and Industrial Design
concept

Step 3: Schematic and Board Layout Part 1
motherboardboard_norouting

Step 3: Schematic and Board Layout Part 2
motherboard_withrouting_graphic

With more to come!

How can you help?
The hackaday prize is judged on several criteria, including community voting. There are three ways that folks interested in the project can help:

  1. Vote: There are two mechanisms for voting, and both require an account on Hackaday IO, but it only takes a moment to sign up. Once you’ve signed up, please visit the project on Hackaday IO and select “Give the project a ‘skull’ symbol” to show your support. This helps show your support for the project, and show it to more folks who visit Hackaday IO. buttons
  2. More Voting: The second set of voting helps determine the interest in each project concept entered into the hackaday prize. It takes a minute or two to complete this step, and as a bonus you get to quickly become familiar with some of the other great projects in the competition!
    vote
  3. Write a kind note: The kind words of encouragement that folks send are genuinely helpful, and are very appreciated. If you like the project and have a moment, please feel free to write a note in the comments (either here or on the Hackaday IO project site). I read them all, and apologize that there sometimes isn’t enough time in the day to reply to them all while still making progress.

Thanks for reading! With the first set of boards being made as we speak, it should be an exciting few months! Stay tuned!

Source Release — Open Source CT Alpha

openct-source

I’m very happy to announce the first release of the Open Source Computed Tomography (CT) scanner project. This is an early alpha release, and contains all of the source at the projects current stage, including the laser cutter design files for the machine structure, EAGLE source files, and the sample Arduino sketch.

The source is available for download here [zip], and is also available on GitHub. For potential contributors, the TODO file also includes near term project goals at a variety of skill levels, from adding end-stops and designing the official Arduino shield, to designing parallel detectors that decrease scan time, and developing a new source/detector pair for different wavelengths of interest.

I’m excited to see what folks do with this project, both now and as it matures. If you build one, want to contribute to the project, or encounter any issues, please send me a note.

In other news, the Bay Area Maker Faire is coming up in a short two months. With a good amount of progress on the Open Source CT Scanner, I’m going to switch gears for a while back to the Mark 5 Arducorder — I’d love to have the firmware and basic functionality working and demonstrable by then.

Open Source CT in MAKE Magazine

makemagazine_ctscanner400

Very exciting news — the Open Source Desktop CT Scanner is featured in this month’s MAKE Magazine Homebrew Section. I’ve been a great fan of MAKE for years and presented the Science Tricorders at their first Hardware Innovation Workshop, and so it’s very exciting to see the project in this issue.

Source Files: There’s been a lot of interest in having the source files for the alpha version of the scanner, and so I’ll endeavor to have these up within a week or so. I’m in the process of collecting and packaging the source, as well as moving everything to GitHub (including TODO lists) so that it’s much easier for folks to contribute.

I think that the best thing for an open source project is to bootstrap an initial community of users that can grow into a community of contributors, and so I’d like to cut out a few sets of the laser cut parts to send to one or two folks who are interested in building (and ideally contributing) to the project. If you’re interested, please send along a note with your background and how you’d like to contribute, to peter at tricorderproject dot org.

thanks!

Dr. Jansen, or: How I Stopped Worrying and Learned to Love the Barium

pepper_overlay1

After a marathon build session, the first images from the open source CT scanner are here! The story…

The Detector
dsc_0425

Recall that in the last update, the stock Radiation Watch Type 5 silicon photodiode high energy particle detector was found to be calibrated for Cesium, with a detection threshold likely somewhere near 80keV. This was too high to detect the ~22keV emissions of the Cadmium-109 source, and so I put together an external comparator that could adjust the threshold down to the noise floor. After testing the circuit on a protoboard, I designed a tiny board that sits on the back of the Type 5, and through the use of a 10-turn potentiometer allows you to recalibrate the threshold down to the noise floor.

dsc_0417

I designed some mounting plates that could mount to the linear carriages for the source and detector.

dsc_0436

Here, the detector is mounted onto an offset mounting plate, which in turn connects to the detector carriage. The wiring harness breaking out all the detector pins feeds through the center of the carriage to a fixed mount point on the bore that acts as a strain relief. Looks great!

The Source

Even with the upgraded extra-sensitive detector, I was still seeing many fewer detections than I was expecting — albeit about an order of magnitude more than without the enhancement. A kind fellow on the Radiation Watch facebook group made a spice simulation model based on the helpful schematics that the folks at Radiation Watch make available, and his simulations suggested that the noise floor for this circuit is around 30keV. This means that with Cadmium 109, whose primary emissions are around 22keV, I was likely still missing the majority of the emissions, and getting many fewer counts than I was expecting.

Enter the Barium-133. There are a number of radioisotope check sources that are commonly available, but many of them have very high energy emissions in the many hundreds (or thousands) of keV — likely far too high energy to be usefully absorptive for everyday objects. The emission spectra I’ve seen for the tubes in commercial CT scanners tend to have broad spectrum emissions centered around 60-70keV, and the datasheet for the silicon photodiode suggests it’s most sensitive from 10keV to 30keV, where the sensitivity drops off afterwards. A higher detection efficiency means that we can get by with a less intense source, and with check sources that are barely detectable over background a foot away, it’s a battle for signal, and every photon counts.

Barium-133 has primary emissions around the 33keV range, and seems to be one of the few commonly available radioisotopes (aside from Cadmium-109) with such low emissions. To give the system the best possible chance of working, I ordered a 10uCi Ba133 source (up from the 1uCi Cd109 source I was using previously). With the source 10cm away from the detector, with the background rate at 20 counts per minute, the Cd109 source reads about 70 (so a delta of 50), and the Ba133 source reads around 1500 (!), so we’re definitely detecting many more of the lower energy emissions, and this should have a much better signal-to-noise ratio, and decrease the acquisition time required for collecting good data.

dsc_0465

The Ba133 source also comes as a sealed 25mm disc. I designed a sandwich mount for these source discs that contains between 3-6mm of lead shielding at a variety of angles, and a very rough approximation of a lead collimator with a 3mm hole drilled in the front to give some directionality to the source. Testing out a few angles, this appears to have brought the reading down to about 60 cpm at 15cm away, except for directly ahead, where the intensity is about 550cpm at 15cm. Sounds great!

dsc_0477

Putting it all together

dsc_0482

I have to confess, I’m a bit of a late sleeper (and a night owl), but I was so excited about finally putting everything together and collecting the first data, that I woke up early Saturday. After a marathon 13-hour build session, I finished designing and fabricating the source and detector mounts, and putting the bore back together.

dsc_0482

With one of the bore covers removed, these pictures make it a little easier to see the complete linear axis mechanisms that are contained within the bore. You can thank my dad for discouraging my rampant hot glue use at a young age, and encouraging me to design things that were easily serviceable. I’ve given a few students the same talk when I see them wielding a hot glue gun for one of their projects… ;)

dsc_0488

openct2

Putting it all back together — looks beautiful!

And now, the data!

openct1

After the marathon build session, I took the very first data from the instrument — a quick absorption image straight up the center of this apple. Data was low resolution and noisy, but fantastic for the very first data from the instrument.

open_ct_xerocraft2

A very tired, but very pleased person after collecting the first data off the scanner around 1am.

rsz_avocado_picture

I had some time Monday evening to write some basic firmware for collecting images, storing them to an SD card, specifying the size and resolution parameters, the integration time for the detector, and so forth. In probably one of the strangest things I’ve ever done, and feeling very much like Doc Brown, I went to the grocery store and found a few vegetables that have internal structure and might be interesting to scan. I decided to start with the avocado…

I’d previously determined empirically that the optimal integration time for this setup is about 90 seconds per pixel — that tends to give a stable count of around 550cpm +/- 4 cpm. Lower integration times will give proportionately more noise, but be much quicker to scan.

The avocado is about 10cm by 12cm, and so to capture a first test image I set it to a 5mm resolution with a relatively fast 10 second integration time per point (bringing the total acquisition time to 20 x 24 x 10 seconds, or just over an hour).

avacado1b_log10

And it worked! The image is certainly a bit noisy (as expected), but it looks great. The table and the avocado are clearly visible, and the seed might also be in there, but we’ll need a bit higher integration time to see if that’s real structure, or just noise.

avocado_overlay1

Overlaying the scan atop the picture, the scan is a perfect fit!

avocado2_60sec

The integration time for the first image was only 10 seconds per pixel, and so I setup a longer scan with an integration time of 60 seconds per pixel. Beautiful! This still isn’t quite at the empirically determined sweet spot of 90 seconds, but it really cleaned up the noise in the first image.

avocado2_log10_60sec

The same data, with log scaling rather than linear scaling. I’m not entirely certain whether avocado pits are more or less absorptive to 33keV photons than the surrounding avocado, so it’s not clear whether we’re seeing lots of absorption at the center because of the seed, or because there’s 10cm of fruit between the source and detector…

rsz_dsc_0606

But I’d love to see some internal structure. So tonight I put the bell pepper on, which is about the same size as the avocado, and set it to an integration time of 20 seconds.

pepper1_20sec

And the result! It definitely looks like a bell pepper, and you can clearly see the seed bundle inside. Incredibly cool!

pepper1_log10_20sec

The same image, log scaled instead of linear scaled.

pepper_overlay1

And the overlay. Looks beautiful!

What a fantastic few days for the open source CT scanner, and the initial data looks great. There’s still plenty to do — now that the source and detector are working, I can finish designing the Arduino shield with four stepper controllers (two for the linear axes, one for the table, and one for the rotary axis). The source is also currently collimated in only the most liberal of senses, and in practice the detection volume for a given pixel is likely a pyramid that starts from the ~3mm source aperture and meets the ~1cm square detector — so the images should sharpen up a good deal by better controlling the beam shape. Once all of that is working, and I add an accelerometer sensor to the rotational axis to sense it’s angle, I should be able to scan from 180 degrees around the sample, and test the ability of the instrument in computed tomography mode, backing out the internal structure of a given slice from a bunch of 1D images. Very exciting!

Thanks for reading!

The Shape of Things to Come: the Mark 5 Arducorder

rsz_dsc_0358
I thought I’d take a few moments to introduce the next prototype open source science tricorder that I’ve been working on, the Arduino-compatible Mark 5 Arducorder.

I wasn’t having a great deal of luck with the earlier Mark 5 design, and so I decided to start from scratch and create something completely different under the hood. The new design has a larger sensor suite (a few sensors have been updated, and a multi-gas sensor had been added), but it should also be easier to program, easier for folks to tinker with, more modular, and less expensive to produce. It’s also Arduino Due compatible, so the hundred thousand folks out there who love Arduino programming and building simple circuits should feel right at home tinkering.

dsc_0284

Like the Mark 1 and 2, the Mark 5 Arducorder has a separate motherboard and sensor board. I think community building is a huge part of a successful open source design, and in this spirit I’d like it to be as easy as possible for folks to build new sensor boards for their Arducorders, or add expansions that I can’t anticipate. The Arduino folks have been very good with designing their boards to be expandable using “shields” that have standard, easy-to-prototype, 0.1″ headers. Similar to the idea of a shield, I’ve designed the Arducorder to have a 34-pin header for the sensor boards that expose a variety of pins for the I2C, UART, SPI, Analog, PWM, and Digital I/O peripherals, so that there are plenty of pins for expansion and interfacing to most kinds of sensors.

These boards were an interesting challenge to design. Conceptually the Arduino motherboards are fairly simple, but in order to maintain perfect compatibility with the Arduino Due board the routing was a little complex in areas. The whole Mark 5 Arducorder system is small — really small — and having the large easy-to-use sensor connector consumes a lot of real-estate, totaling nearly one quarter of the board area. Because of this I had to move to a 4-layer design, which takes a little longer to get fabbed. Still, the entire Arducorder including the 2.8″ LCD, WiFi module, and sensor board fits in about the same footprint as the original Arduino Due (or, about the size of my Blackberry), so it’s all quite compact and I’m very happy with the footprint.

dsc_0296

In terms of hardware, the prototype Arducorder motherboard currently has the following specifications:

Motherboard

  • Arduino Due compatible, using the Atmel SAM3X8E ARM Cortex-M3 CPU
  • 84MHz CPU Clock, 512KBytes of flash, 96KBytes SRAM
  • External 128KByte SPI SRAM
  • microSD card socket for data, graphics, and so forth
  • 2.8″ TFT LCD display w/touch panel
  • FT800 Graphics and Audio Controller to offload graphical rendering. Supports JPEG decompression.
  • CC3000 802.11b/g WiFi module
  • Two user-selectable input buttons, one on either side
  • microUSB for programming and charging (Due “native port”)
  • Exposes the second programming port through a header, as well as the two erase/reset buttons on the side, to maintain Arduino Due compatibility

Having some mechanism to render quality graphics has been a requirement since the Mark 1 using its external SED1375 graphics controller, and was certainly the case with the Mark 2′s beautiful dual organic LED displays. But graphics of any resolution have always been difficult for microcontroller-powered systems, like the PIC family (used in the Mark 1) or the Atmel microcontrollers used with the Arduino family of boards. Even with a microcontroller fast enough to perform graphics rendering, most microcontrollers don’t have nearly enough memory to support even a single framebuffer for a 320x240x16bpp screen (128k), so any graphics they do render tend to look choppy.

Enter the FT800 Graphics controller, a new product from FTDI, the same folks who make the popular FT232R USB-to-serial converter. The FT800 looks a lot like a modern version of the the 2D tile-based graphics controllers found in handheld gaming systems a few years ago, while also incorporating audio and touch-screen peripherals. The Gameduino 2 is a recent Arduino-powered project that makes use of the FT800, and it shows Gameboy Advanced-era graphics on an Arduino Uno — so I’m confident that an attractive and elegant interface can be crafted on the Arducorder. While it has less graphical capabilities than the original Mark 5 design, it should be much easier for folks to modify — and I’m excited to see the first user interface themes folks come up with.

dsc_0328

In terms of sensing capabilities, the current sensor board has footprints for the following sensors:

Sensor Board
Atmospheric

  • Ambient Temperature and Humidity: Measurement Specialties HTU21D
  • Ambient Pressure: Bosch Sensortec BMP180
  • Multi-gas sensor: SGX-Sensortech MICS-6814

Electromagnetic

  • 3-Axis Magnetometer: Honeywell HMC5883L
  • Lightning sensor: AMS AS3935
  • X-ray and Gamma Ray Detector: Radiation Watch Type 5
  • Low-resolution thermal camera: Melexis MLX90620 16×4
  • Home-built linear polarimeter: 2x TAOS TSL2561
  • Colorimeter: TAOS TCS3472
  • Open Mini Visible Spectrometer v1 using TAOS TSL1401CL 128-pixel detector, with NeoPixel light source

Spatial

  • GPS: Skytraq Venus 638
  • Distance: Maxbotics Ultrasonic Distance Sensor
  • Inertial Measurement Unit: Invensense MPU-9150 9-axis (3-axis accelerometer, gyro, and magnetometer)

Other

  • Microphone: Analog Devices ADMP401

Many of these are new or updated offerings that either offer new sensing modalities that weren’t previously available (like the lightning sensor from AMS), or that improve upon resolution, size, or cost over previous versions. Gas sensing has been on the wishlist for a long while, but many contemporary sensors are large and use power-hungry heating elements — so I’m particularly excited about trying out new line of micro gas sensors from SGX.

One sensor has been temporarily removed — the camera. There’s currently no easy way that I’m aware of to hook up a camera (which is a high bandwidth device) to an Arduino Due, which has limited memory. I’ve replaced the camera with a small board-to-board connector, in the hopes that someone in the open source community will develop a small SPI JPEG camera board with an onboard framebuffer shortly. If not, I’ll have to have a go at it once the rest of the device is functional.

dsc_0342

While the top of the sensor board contains the thin, omnidirectional sensors, the bottom contains many of the larger, directional sensors including the open mini spectrometer and the ultrasonic distance sensor. I’d love to find a shorter alternative to these sensors at some point, as right now they are the determining factor in the Mark 5′s thickness — about an inch.

dsc_0345

Currently I’m testing out the sensor board — some of the sensors are a bit expensive, so I’m iteratively populating the boards, testing, and so forth. I also have to 3D print more open mini spectrometers — my cats absolutely love to play with them, so the bunch I’ve made have vanished into the aether under the couch, never to be seen from again.

dsc_0361

My current TODO list is to verify the basic functionality of the hardware (currently the FT800 as well as a few of the sensors have been tested), write low-level drivers for all the sensors and peripherals, then move on to creating the larger graphical user interface. At first the graphical environment will likely be somewhat modest, but I’d love to recruit the help of some skilled folks from the open source community who would enjoy working on the interface side of things once the prototype hardware is stable. Please feel free to contact me if you’re interested.

Thanks for reading!

Additional Pictures:
dsc_0363

dsc_0371

dsc_0373

dsc_0379

dsc_0383

dsc_0392

dsc_0405