Team:CLSB-UK/Hardware
Hardware
From inception, our project aimed to produce a cheap, portable and effective screening tool for diseases. A large barrier to this is the quantification of fluorescence from our genetic circuit. We therefore set out to build a cheap and portable fluorometer.
Our combined fluorometer and densitometer allows our paper based test to be used in the field, in remote areas or less developed countries. It also provides a way for high schools and community labs that cannot afford a plate reader to quantify fluorescence and optical density.
Previous designs
Initially, we built a fluorometer using the previous design by the Aachen 2014 and Denver Biolabs 2016 teams. Their fluorometer uses an Arduino board, 2 LEDs, 2 light sensors, 2 breadboards and an LCD screen.
The light sensors output a square wave with frequency proportional to light intensity. The Arduino uses this to calculate either optical density or fluorescence. These readings are displayed on the LCD screen.
Alleyn’s School kindly allowed us use of their laser cutter to produce the casing and their 3D printer to produce the cuvette holder (as mentioned on our attributions page). Denver Biolabs' box design was fiddly to put together and was overcomplicated, so in the end we opted to not use it as we didn’t think the extra time, money and resources spent to make it were worth it.
The circuits in the previous designs were unnecessarily complicated. We simplified the circuit by removing excess wiring and components. This made the fluorometer far easier to build, troubleshoot and modify further.
Aachen 2014’s design
Our equivalent, simplified version
At first, all the readings came out as zero. After analysing our device we located the bug in Denver Biolabs' code and wrote a short solution. We later also removed some redundant sections.
You can download the fixed code from Github, however we recommend you use our far superior design using instructions below.
Our fluorometer and densitometer
We significantly improved Aachen and Denver Biolabs' design, having redone the most of the wiring and parts of the software. But we wanted to go further; we made our own combined fluorometer and densitometer, keeping only Aachen's cuvette holder design and their measuring principle.
Here we document the design decisions we made, how we built and tested it, and Judd-UK’s input to the design.
For the measurements, check out the measurement page.
Components
Our design uses only off-the-shelf components except for the cuvette holder, for which we couldn’t find an alternative. Aachen 2014’s design was good for this so we used theirs.
The key component is the Digispark, a USB-based development board similar to an Arduino except much cheaper, and with the ability to communicate with a host computer by mimicking keyboard events. It acts as a bridge between the light sensor and our interpreter app.
The device plugs in via USB so is compatible with almost anything, including desktop computers, laptops, phones and tablets. We created an interpreter application to be used on the device it is plugged into that can save the readings and convert them into common units transmittance percentage.
Our design is completely open-source by OSI standards[1]
- Our code for both the device and the interpreter is licensed under the GPLv3 license
- Our circuit design is licensed under CC BY-SA 4.0
- The keyboard library used (Digikeyboard) is licensed under the GPLv2 license[2]
- The design of the USB development board used (Digispark) is licensed under CC BY-SA 3.0[3]
As specific components wildly fluctuate in price and often go out of stock, we tried to use as many generic components as possible (the exceptions were the cuvette holder, the light sensor and the LEE filters swatch book). These components can be bought from any distributor, allowing teams from across the world to build their own.
In a real-world environment using generic components would reduce production costs due to lower shipping costs by sourcing them from a nearby manufacturer and there is more competition amongst generic components. As such we can’t give direct purchasing links but you should be able to find them online easily.
Component list with mass production prices. Switch to single production.
| Component | Cost (£) | Cost ($) |
|---|---|---|
| Cuvette holder | 1.80 | 2.34 |
| TSL235R | 1.26 | 1.64 |
| Digispark | 0.79 | 1.03 |
| 22 AWG wire (m) | 0.05 | 0.07 |
| 480nm LED | 0.03 | 0.04 |
| 600nm LED | 0.03 | 0.04 |
| 220Ω resistor | 0.01 | 0.01 |
| LEE filters | 0.03 | 0.04 |
| Total | 4.00 | 5.21 |
Software
To minimize costs, we didn’t use a display and instead built software to interpret the results. It gives a live readout, processes results and acts as a datalogger, exporting results to a spreadsheet for further analysis. The software can be run on any computer, tablet or smartphone.
The Digispark pretends to be a keyboard, that types the results extremely quickly into the computer it’s plugged into. The interpreter software can intercept this, along with other keyboard events for changing the settings to provide useful output.
As processing is shifted onto the device it’s plugged into, data analysis is much easier as readings can be automatically logged and exported to spreadsheets. With Judd-UK’s feedback, readings can be marked with ‘recording numbers’, making it easy to do batch measurements. Also based off their feedback, we added a button to export only the ‘recorded’ data to csv. See the collaborations page for more details.
Showing Judd-UK our fluorometer and densitometer.
This framework makes the device easier to modify as a few lines can be changed on the webpage rather than reconfiguring the Arduino board or rewiring the circuit with different components. This in turn also reduces the risk of irreversibly damaging the hardware through bugs in the code. Website programming is much more forgiving than Arduino programming, allowing people with less experience to modify the software. It is also much easier to debug as computers can spit out error messages to the screen.
Moving the complicated processing to the device it is plugged into also means you can use cheaper components in the fluorometer, further reducing the cost. It allows smaller and fewer components to be used, making the device more portable and easier to build.
The interpreter is designed to be used continuously. While the fluorometer is logging data, you can use the keyboard shortcuts to change the options.
Instructions
Our digisparks came with pins free - if yours do too, solder the pins to the board first so you can more easily swap components out if it doesn’t work.
To snap them simply use 2 sets of needle-nose pliers at the point you want them to break and twist.
If you don’t already have a soldering iron check your electrical engineering, physics department or local hackspaces. Most of the time they’ll give you instructions, but if not or you just want more guidance there’s lots of advice online on how to get started soldering. We were lucky enough to be trained by our physics teacher, but sparkfun’s guide looks pretty good too! Don’t hold us responsible for your safety - if in doubt ask someone who knows what they’re doing.
Our one warning is about the light sensors (TSL235R) - the pins are easy to break and they are fairly expensive so be careful with them!
Circuit diagram
Note there’s just one LED - if you solder both the optical density and fluorescence LEDs seperately and use pin headers you can very quickly swap between them.
If you want to be able to switch quickly (and for increased durability) you could implement a toggle switch into the design. We decided against this due to the added cost, however the if you want to do this click here to view the circuit diagram.
In the cuvette holder the LEDs should be laid out as they were in the Aachen design; the fluorescence LED in the bottom, the optical density LED on one side and the light sensor opposite the optical density LED.
Once it’s all soldered, you’ll need to upload the code to the Digispark (you can actually do this before you solder, it doesn’t matter when). Follow the instructions on the Digistump wiki to get set up. We didn’t write them here too as it’s likely to go out of date quickly. In the unlikely event that the wiki does go down, we’ve made a save on the Wayback Machine here.
Do make sure you follow the steps exactly, don’t just skim them and assume it’ll be alright! Although Digisparks are generally pretty hardy, messing up could still fry them, making it harder to troubleshoot and wasting your time and money.
Once you’ve got your environment set up, simply copy our code into the Arduino window, click upload and plug in the Digispark when prompted. It’s just a one time set up, if you’re uploading to multiple chips at once it’s very quick - just repeat the upload step for each Digispark.
Now you should be able to use it on any device. Simply open the hardware interpreter page on your computer, laptop or phone and plug the Digispark in. It will take at least 5 seconds to start - up to 15 seconds on some devices.
Some devices might require adapters to connect to the Digispark, especially phones and tablets. If you’re not sure where to start, try searching for an 'OTG' (on the go) female USB adapter for the port your device uses (e.g. microUSB, USB Type-C or Apple Lightning).
Performance
See the measurement page to see how our device performed.
References
- ↑ (n.d.). Licenses - Open Source Initiative. Retrieved October 8, 2017, from https://opensource.org/licenses
- ↑ (2012, 30 November). DigisparkArduinoIntegration/License.txt. Retrieved October 8, 2017, from https://github.com/digistump/DigisparkArduinoIntegration/blob/master/libraries/DigisparkKeyboard/License.txt
- ↑ Digistump (2013, January 2). Digispark License Terms. Retrieved October 8, 2017, from https://digistump.com/wiki/digispark/policy
