So I thought I was almost finished with the base software for the snitchboxes, but the universe heard me say that and chuckled to itself, knowing full well about the surprise it had laying in wait for me on the very next page.
For the last few days, I've been working on the software that will manage the snitchboxes, but not all snitches will be the same, so I'm taking some time to build a flexible foundation. And one of my biggest concerns while doing that? How to tweak and adjust them once they've been deployed, without having to drag them all back to my workbench to do it.
When spec'ing out the tank and lab monitoring equipment I would need, I completely overlooked a fairly important metric: power consumption for the lights. Yes, I've estimated the power requirements, based on the manufacturer's performance claims, but I haven't actually measured them. So what's the best way to do that?
The Kratky Tank target includes a mandate to set up data monitoring for the tank, but in hindsight, this can't be done in the isolated context of a single grow frame. I intend to try a variety of hydroponic, aeroponic, aquaponic (and even soil-ponic :-) systems, and each will have different attributes that need to be monitored, but they all need to fit into a cohesive data gathering system. So I'm going to split out a few related sub-targets to handle the development of tools to monitor these distinct elements.
Since I'll be capturing manual data as well as automated sensors, I need a way to quickly capture manual inputs too.
To that end, I've built a data collection interface in Memento DB that I can run on my phone. This makes it very quick to capture the data, which means I will use it more frequently than I would a more cumbersome process.
I have not yet built the central data collection module, but it will have to support bulk upload from the phone, or it could alternately present a web interface for manual inputs. I'll have to think about what makes the most sense.
Note: This task was later absorbed into Target SnitchApp.
My initial intent was to create open-volume containers of appx 4 sqft, but I've since realized that these are potentially problematic for some experiments, such as root crops, because they allow root networks to intermingle, so I need to be able to isolate the individual growing volumes.
Everything I've seen about Kratky so far treats the water requirement as a simple function of the tub size — whatever tub you're using, fill it deep enough to wet the bottom of the growing medium. This is of course practical, but completely avoids the question of predicting how big a tub to choose in the first place. To do that, we need to know how much water a given crop will need over its lifecycle.
For lights, I picked up a Roleadro 75W LED grow light but I quickly grew worried that 75W wouldn't be enough, so I replaced it with a FECiDA 1000W Dimmable LED system
The original plan for Kratky tanks was to build all my monitors from sensor chips so I'd be able to replicate a consistent instrument network throughout my lab inexpensively, but now I'm worried this will leave me trusting home-built equipment with no way to verify them.
Consequently, the Kratky Tank target is also going to get some off-the-shelf sensor gear for calibration and verification.
I've found 3 apps so far that look like they'd be helpful for calculating hydroponic nutrient mixtures.
- iFertigate is a smartphone app put out by the US government that looks quite thorough, but unfortunately, it no longer seems to be available.
- Hydrosolver is a very promising console tool for Linux.
- ScienceHydroponics provides an online solution that seems pretty capable.
I'm noting these here for future reference, but for now, they seem a bit more advanced than I'm really qualified to explore. I think a better plan for now is to follow the standard Masterblend formula, and then revisit these once I have a better understanding of what I'm doing.
If I'm going to do this right, I have a lot to learn about biology, laboratory methods, agricultural science, etc. I could take the “crazy recluse trying to cure cancer in his basement with dryer lint” route, but I happen to live a few blocks from a university with a specialty in agricultural research and it would be a shame to waste such a great resource.
In all my years of working and studying on campus, I've never actually made connections with anybody from the Ag Dept. But how hard can it be to knock on a few doors? Worst case, they dismiss me as crazy and call security.
But best case? I find a potential collaborator who actually knows what they're doing.
Found a good explanation of how to calculate nutrient solutions, but that might be a bit too advanced for now. I think I should start with whatever the common practice is until I've established some baselines. Then I can start tinkering with more advanced formulations and methods and compare them against the baseline.
That common practice appears to be simply mixing Masterblend (in a standard ratio with Epsom Salt and Calcium Nitrate) at a standard proportion per gallon of water. The recipe (given here, for example) is:
And note that it's important to do things in that specific order.
Eventually, designing a cheap, efficient, and robust lighting system for the fountain is going to be a project of its own, but in the meantime I still need some kind of lighting in the lab to provide consistent, controllable conditions for my experiments. But aside from the light that came attached to my Aerogarden, I have zero experience with grow lights.
So how’s an inexperienced gardener like me supposed to choose?
To make it easier to track trials, collect data, and avoid the predictable confusion of having 20 identical test containers, I've implemented a tracking tag system with barcode identifiers. These barcodes are scannable by my data entry tool (described above) which can then quickly pre-load the entry screen with the pertinent unit id and be ready for my readings.
For completeness, each tank will have an ID and each plant within that tank will also have an ID. When individual specimens are seeding/planted, their IDs will be linked to the tank ID in which they're placed, so that measurements of the tank (temp, pH, etc) can be easily matched to the success metrics of the plant.
For the record (in case anybody else is using Linux and wants to know about my toolchain) my tracking codes are simply the datestamp (to the second and without punctuation) of when the sample tag was printed. For example, the tag shown in the picture here is 20230318170214. This is printed over USB to a Dymo LabelManager 280, using the opensource dymoprint python script available here, and rendered in the code128 barcode format.
(For completeness, the command to produce the barcodes is: dymoprint -c code128 "$(date +%Y%m%d%H%M%S)")
In an earlier update I declared new policies to Let Data Reign and to Go Wide with it. The first refers to making decisions based on actual data, while the second refers to making sure I have all the data. And now the very first time I try to apply those principles, I’ve run into an unexpected roadblock.
When you think of a fountain, how big a thing do you picture? Are you imagining one of those little fiberglass deals in the corner of your yard that cycles the same 3 gallons of water round and round all afternoon? Or do you picture something bigger, like maybe the Trevi Fountain in Rome?
Well, size-wise, a calorie fountain will be somewhere between those two extremes, but this project isn't about pretty; it's about productivity. Here's what I think they might look like...
Calorie fountains can grow lots of different crops, so in theory, they can provide families with a varied and satisfying menu of foods. But most people have limited space to work with and don't want to spend all of their time managing the system, so in practice, the variety of foods available on your table will depend on which of its three basic modes you're operating in.
One of my goals for Project Calorie Fountain is that it be easy to build and simple to operate, so I should probably avoid requiring any expensive and/or complicated gadgetry in the mix, if at all possible.
But that doesn’t mean my lab has to be gadget-free. On the contrary. The more I can track and understand the variables in my setup, the better I’ll be able to diagnose problems as they arise, and steer the project toward simpler crops and methods.
The question is: what data needs to be tracked, and how?
The preliminary research I did to sanity check my basic premise contained several surprises. First: All the sources I could find about high calorie crops seem to have completely missed the seaweed option. Second: They all cited Jerusalem artichokes as one of the champion crops, even though it didn't make my top ten, once I'd factored in field area and time to harvest. And those surprises have taught me a useful lesson...
Before I can compute a crop with an optimal nutritional yield, I have to know what nutrients are provided by each one. Today I found this dataset that looks like a good place to start.
They cite the USDA Agricultural Research Service as their source, which seems credible. I'm going to take it on faith for now so I can stay focused on getting some code working, but I'm also flagging this post for later verification so I don't forget to come back.
When it comes to finding the optimal crops to support a family, there are a number of factors to consider: how much space is available, how many people are being supported, what are their daily calorie requirements, what vitamins and minerals does each crop provide... There's a lot to consider. And it's not like I can pick just one “best” mix and build a one-size-fits-all system around that. I need to figure out the optimal mix for my own scenario while allowing other fountaineers to figure out the right mix for theirs . Sounds complicated, right?
After looking at several online reports of methods to grow carrots (which are similar to salsify) I'm not seeing anything that appears to produce carrots at optimal size. This suggests that I may need to devise something different...
One potential problem with a project like this is that it will be easy to run madly off in all directions and not have any focus or accountability to the research. To counter that, I’m employing a simple microproject protocol that I call Target Tracking. Here's how it works...
So, let's talk about that name: calorie fountain. It conjures to mind an idyllic little garden feature, doesn't it? Burbling away in the corner of the yard and producing an endless supply of sweet nourishment — the very nectar of life, right? Well, the visual might not be right — the actual fountain will be neither small nor pretty — but I’m willing to look past that, because the rest of that imagery is right on point. And that's more important than you might think...
Sharing progress as it unfolds is an important part of Project Calorie Fountain’s DNA, which means not only building this website, but also keeping it up to date. But if there's one thing my years of experience have taught me, it's that websites done well suck up a lot of time, so if I want to have any bandwidth left for the actual research, I need to come up with a way to manage this site without letting it cut into my working time. Let's take a look at the architectural choices I’ve made to deliver on that, and the reasons I made them.
When it comes to feeding a lot of people efficiently, the size of the farm will be a major consideration. Whether I plant indoors or outdoors, the bigger the farm, the more labor, materials, and time it will suck up — all of which is typically in short supply. So during the opening stages of this project, my biggest concern is going to be the calorie yield. I want to find the crops that can produce the most calories, in the smallest area, and the shortest time.
But first I have to measure it.
Whether we look at its high calories per sqft per day or its slam dunk mineral profile, seaweed is the heaviest hitting crop I've come across so far. So many calories and nutrients, so quickly, and with nearly zero maintenance too. Too bad it tastes like soggy butt cheeks, right?
Project Calorie Fountain is expected to be an evolving thing: I want to get something started quickly and then iterate, iterate, iterate. Ideally each new version will be better than the last, but what does "better" mean, exactly? There are a lot of variables that could be improved: more calories produced, smaller area required, faster maturity cycle, etc. How do we compare them?
I made my first website in 1993, and I've made scores more since. I've done it both professionally and privately. I've built statics sites and dynamic ones. I've hand-coded custom frameworks from scratch, piggybacked on open source frameworks, and I've used most of the major "site builder" sites too. But there are only two kinds of sites I've ever built that are still running: the ones that take a pile of my time to maintain; and the static ones.