Pioreactor development blog #9
Optics again! This time we are discussing LEDs performance in different environments, and a major optics change to the Pioreactor.
Pioreactor development log #8
The role of stirring in the Pioreactor is important for a few reasons: i) it allows for modest gas exchange between the media and the air, ii) more importantly: it creates a homogenous environment for microbes and nutrients alike. This last point also means that our optical signals won't vary spatially - something that would make the whole system much more complicated.
Pioreactor development log #7
The past few weeks I've been thinking a lot about optics. Too much. It's given me a headache. But we've characterized some really important details about how the Pioreactor works. Let's first talk about how microbial cells interact with light.
Pioreactor development log #6
By design, there is no Pioreactor "cloud". That is, all your collected data, the web interface, and computations are hosted locally on the Raspberry Pis. This has a number of benefits for you, the user:
- no additional monthly fees that are associated with a cloud model
- no latency issues
- if we, the company called Pioreactor, disappear, you can still use the Pioreactor (additional bonus: our software is open source so you can continue to develop it)
However, we also want to learn from users to improve the product. For example, we'd like to collect real-world statistics from bioreactor experiments, like the amount of noise in our optical density signal, or how LEDs respond to temperature. We can aggregate this data across all the Pioreactors, produce better statistical models, and return these models to users for improved performance.
This past week, we took our first step in this direction by setting up a very thin cloud service to collect statistics from Pioreactors (by the way, this is an optional service. You only need to turn if off in your Pioreactor's configuration). After specific tasks the Pioreactor perform are completed, it will fire a few data points to one of our cloud endpoints, and these endpoints store the data in a database. Later, we will analyze this data and improve our internal statistical models. See Figure 1 below.
The cloud service we chose was Firebase Functions. This was my (Cameron's) first use of Funtions-as-a-service, shortened to FaaS. The FaaS model is a recent trend in software architecture. Instead of building an entire app with the functionality of exposed endpoints, in a FaaS model, we only define the endpoints that run functions. This is really useful for companies that want to offload some computationally-heavy task (image resizing, video processing) off their main app. In our case, we just want endpoints to listen to incoming data, and store that data in a database. That database is provided by Firebase, called Firestore.
How does this help you? You get the accumulated knowledge of thousands of bioreactor experiments. You get reduce need for calibration, since we can give you better estimates of calibration parameters. All for free!
Figure 1. A schematic of how sharing with the Pioreactor Cloud results in improved performance for all Pioreactors.
Pioreactor development log #5
One of our goals with the Pioreactor is design it such that you don't need to be a biologist, or an electrical engineer, or relevant for this article: a statistician. This article describes our internal algorithm that computes the culture's growth rate, but importantly: you don't need to know this algorithm to use the Pioreactor! We've designed the internal statistical algorithm to be robust enough that you can sit back and watch. This article is for the users who really want to dig deep into how we compute growth rates and the statistics behind it.
Pioreactor development log #4
This week we investigated some sampling tricks to improve our ADCs, and managed to get a 50% reduction in signal variance, and gain many more bits in our signal, using data science!
Page 2 of 4