Blog

It’s crunch time getting everything ready for planting in greenhouse so I haven’t been updating as I wished. Lots of little things to get right. But look at this:

Tray for hydroponic slabs (or transplant blocks) that automatically lifts and tares the balance load cells it sits on every 5 mins. Then the computer uses that accurate mass to schedule irrigation events. It’s finally working! Lots of other stuff to do next week but still on track to plant seeds July 1st.

This week I got all the line voltage stuff working for the greenhouse controls. Reserc pump for hot water heating, 2 irrigation pumps, fans for venting. I still need to hook up the arduino controls for those, but it’s pretty simple since the SSRs are in place and the arduino can control those directly.

The load cells for measuring the weight of the plants have been giving me tons of trouble this week. About 10% of the time they work fine, calibrate, etc. But the other 90% of the time they just return garbage, like the conversion from data bits to floating point number is all screwed up. Or they just don’t read at all. Part of the problem was loose connections, I’d bump it and it would start or stop working. I ended up removing all the pin / breadboard like connections and soldering but still wouldn’t work. In the end I got 1 hx711 chip working consistently with a load cell giving reasonable data over the whole weekend. However, this chip was purchased from a different batch, so maybe I just have defective chips.

I also found that the hx711 chip is extremely temperature sensitive. Putting a finger on the chip or breathing on it changes the reading by up to 150g on a 50kg load cell. I was under the impression that the temperature sensitivity on load cells was the load cell itself, but that error seems to be dwarfed by the hx711 temperature dependence. I will try to keep the hx711 chips in a junction box under the hydroponic trays where the thermal mass of the soil will limit temperature swings.

I ordered some new load cells and hx711 chips in hope that that will solve the problem. In the meantime, next week I will work on getting the arduino actively controlling the greenhouse climate and insulated doors for the fan venting openings.

This week was a bit frustrating trying to get the controls in the greenhouse. First I had to spend a day debugging the arduino IDE. It would occasionally work, then stop, then start… The problem was I have two different sets of arduino nano boards, some of which need the new bootloader option, some of which need the old boot loader option. Second, the 3 way solenoid valves I ordered were not actually 3 way valves but just had an extra hole connected to supply. But it doesn’t really matter because the orifice inside of them is tiny. That’s probably ok for filling up an air seal, but not good for letting out the pressure unless I had a vacuum. So I ordered a motorized ball valve, 1/2”. Should provide a nice large opening.

I tested the load cell, which was super stable on my desk. Very low drift, 2 g/hr. But then I built a rig to weigh a tray and suspended it from the greenhouse ceiling and drift was all over the place. I think the main problem here in retrospect was that it was pulling off axis. I might redo it in a more typical S shape. The other option is to put 3 load cells under each tray. That’s more expensive but the temperature should be more constant so maybe worth it. It also frees up space in the canopy which is good for light modeling.

I also had to revise my plan for microcontrollers. I got the arduino talking to a python script, but it’s just not that reliable. I like it for data logging and sending manual updates, but I don’t want to have anything mission critical like heating or irrigation or venting go from arduino to laptop filesystem to arduino. I want it all self contained in the arduino. So I had to order an arduino mega which has enough pins. I also found that adding extra cable to the i2c humidity and co2 sensors won’t work, too much interference/capacitance. So the arduino has to be in a watertight box in the greenhouse close to those sensors.

Lots of issues. But I did get all the pumps and fans wired in ready for a 5 volt control signal and lots of the pumping is done from the fertigation reservoir.

This week I worked on the modelica simulation and got that working for a constant LAI (leaf area index). The error was in vanthoor actually, but the reference had it correctly for the internal transpiration resistance at low humidity. In case you’re following along, you need to consult Stanghellini 1987 for that one. I then setup a system to do ray traces for all the possible combinations of LAI and canopy height for each time period. This is very computationally intensive, so I may need to adjust that later. It seems like the simple way to do it for now though. I have this ouputing into a table where each column is the absorption for a .stl file of the greenhouse for a given LAI and canopy height.

The next step is to make a modelica function that takes that table and interpolates for the current LAI and canopy height. I may not get to that soon though because I want to make sure the greenhouse is ready for planting on July 1.

I started on the greenhouse controls, a lot of which I can reuse from the growth chamber. The heating loop (which hopefully will not be used), fan motor controls, humidity and co2 sensors are all the same. The switch to hydroponics means I need two pumps (one for each row in the greenhouse so I can time their irrigation independently).

The tricky parts are weighing the slabs and sealing the greenhouse vents when they are not in use. For this I plan on using a low pressure compressed air system. Seals can be inflatable plastic tubing that is pressurized when the vents are closed as a tight gasket, then vented to allow opening. For weighing the slabs, I plan on suspending them from a 50 kg load cell. Because the cheap load cells have a lot of drift with time, the cell can be periodically deloaded with an inflatable bag beneath the slab holder connected to the compressed air system. This will allow for automatic re-tare as needed. I’m hoping for 10 min cycles.

This week I insulated the north, east, south walls of the greenhouse with 12” thick cellulose. That in the end seemed to work pretty well, but the blower I had would get clogged if I tried to do dense packed cellulose. So I’ll have to measure the true R value with heat flux sensor but I think it should be sufficient.

I also got the rayctracer linked up with modelica. The simulation flow works like this:

1) select some solcast historical weather data, put in a .csv file with sun angles

2) Make a CAD model of the greenhouse, label each part with my naming convention for the optical properties. Download all of part .stl files to a folder

3) run a python script that uses rayctracer to trace all the .stl files in the folder for the given solcast data period and saves the solar watts absorbed for each part in an ascii table file that modelica can use.

4) Run the modelica simulation using the same weather data and absorption table. Here you have to manually write in the modelica file which part .stl corresponds to which part of the model.

5) Enjoy accurate simulation of greenhouse temperature and model of tomato growth.

This all seems to work except the modelica model has something wrong with transpiration where the tomato plants are heating up to 150 degrees C… So I need to go back and fix that.

A few more things I like to add are more raytracing data points so that modelica can see how changes in crop height and LAI (leaf area index) change the light absorption, and to use the rayctracer to calculate view factors for thermal radiation between parts. These are optional though, thermal radiation is generally a small effect, and in the winter crop height is limited by the greenhouse height and LAI is pretty constant.

The goal is to get this working next week and run a long simulation so I have a good idea of what is important to measure in the greenhouse this summer/fall/winter.

Full disclosure: I wrote this to help promote my friend’s farm. But, I was really surprised that that difference in local vs imported is as big as it is! Part of this is because Nova Scotia is so far away from California, in other locations it might not be so clear cut. That’s all the more reason to grow more of our own food here.

Eating local has become a civic virtue, and with good reason. Local food gives one a sense of rootedness and belonging, results in fewer CO2 emissions, and tastes great. But how much better? A lot! Take lettuce, for example, which grows well both at St. Isidore Farm in Nova Scotia and also in California on the large farms that supply grocery store chains.

Eating local is one of those things you’re supposed to do, but how much of a difference does it really make? Is there a big difference in CO2 emissions and taste? I’m not really an epicurean, does it mater to me? I also don’t buy exclusively organic produce because a) I’m kind of poor b) I’m not completely on board with some of the permitted “organic” practices.

Local vegetable growing emits 4.3 – 8.6 times less CO2 than the Californian imports [5]. Locally grown has 1.4 – 2 times higher nutritional content [4], and lasts longer without spoiling, reducing waste [2]. In fact, the higher nutritional content means that local is also actually far cheaper, since to get the equivalent nutrients at the grocery store you’d have to buy (and eat) twice as much. Calorie wise it’s about the same, but most people aren’t eating lettuce for the calories.

When you buy local, the taste is better, they keep longer, and the nutritional content is higher! Another plus is that local vegetables can be heirloom varieties that taste better but don’t ship as well. Many vegetable varieties have been bred for transport durability as the primary concern to the detriment of their taste.

In contrast, from Californian harvest to Nova Scotia takes at least 3 days by truck, and generally 5-10 days with distribution centre layovers [2]. Not only does this affect the taste, but results in the loss of 30-50% of the nutritional content [4]. Have you ever wondered why things just don’t seem to keep in your refrigerator? They were already old when you put them in! 30% of food waste occurs in the home, but likely this is spoilage from long, harsh transportation, not consumer overbuying [2].

CO2 emissions associated with vegetables come from the farm production and transportation to grocery store. Californian farms are usually large scale and generate large emissions through irrigation pumping and mechanization. In fact, 6% of all energy used in California is used to pump water for crops, and that water use is often unsustainable [1]. Produce is usually transported by truck, 6000 km to Nova Scotia, with stopovers in refrigerated warehouses that also emit CO2 [2].

In contrast, St. Isidore Farm lettuce is hand harvested, with only a shallow well for irrigation. Ancient ground water aquifers are not depleted, and protection from the cold is a simple unheated greenhouse in the early season. Transportation is 30 km or less. Local vegetable production has at least 4.3 times lower emissions (with the exception of hothouses which have heating emissions higher than even Californian imports) [3]. All the more reason to continue with our solar greenhouse research that will allow for year round local produce without emissions.

[1] Agwaterstewards.org. 2020. Water & Energy – California Agricultural Water Stewardship Initiative. <https://agwaterstewards.org/practices/water_energy/&gt; [Accessed 8 June 2020]

[2] MacRae, R.J. 2020. Challenges of food transport in Canada. Food Policy for Canada: joined up food policy to create a just, health promoting and sustainable food system. http://foodpolicyforcanada.info.yorku.ca [Accessed 8 June 2020]

[3]Plawecki, R., Pirog, R., Montri, A. and Hamm, M., 2013. Comparative carbon footprint assessment of winter lettuce production in two climatic zones for Midwestern market. Renewable Agriculture and Food Systems, 29(4), pp.310-318.

[4] Klein B., 1987. Nutritional Consequences of Minimal Processing of Fruits and Vegetables. Journal of Food Quality, 10(3), pp.179-193

[5] Study [3] was comparing California produce to local produce in Michigan. For Nova Scotia, emissions could be twice as high since it is twice as far to ship.

Still recovering from sickness this week. But I did get some work done on the experimental greenhouse. I’m insulating the north, east, west walls with 12″ of cellulose insulation. This is probably not cost effective in the final version, but for now it should eliminate problems of heat loss through these walls. I also framed in two fans for air exchange, 1000 cfm each, one exhausting air and one pushing in air.

Well, I got sick. Probably just a bad cold since covid tests were negative but in this era that means staying at home. On the plus side I did get quite a bit of programming work done. I did get some nice plots of solar data comparing my sensors to the solcast-rayctracer combination:

Here the Ghi from solcast, sunlight 3 and sunlight 2 and Ghi traced should be the same. It works pretty well in the morning, but in the afternoon the measurements are consistently lower than solcast and the simulation. This maybe from the sensors not being perfectly flat or pointing due south. I’ve adjusted the sensor rig to correct that, but haven’t been able to get back out to collect that data.

Here’s the same thing but with the simulation including a single n=1.55 glazing, which should match sunlight 1. Again, it’s not bad in the morning, worse in the afternoon. It’s also possible that the times are a bit off, say 15 min from improper binning.

I went back and got the modelica model of the greenhouse running with yield model integrated with everything except the sun absorption and thermal radiation. These are the parts that require raytracing. The height to the canopy is a new variable compared to vanthoor but logically it should be related to the mass of the plant stem. I oven dried a piece of tomato stem to get an estimate of dry mass per m. I also figured out how to call an external c function from modelica. Sadly no c++, but c should work.

Here is the plan:

Load all the weather data into a python script, use rayctracer to precompute all the sun absorption for various levels of canopy height and LAI for each time period. Save this data into a .csv file. Write a c program that reads that data and interpolates sun absorption based on the sun angle, LAI, canopy height that modelica inputs. This way modelica can make as many function calls as it likes without worrying about the computational effort of ray tracing. My gut feeling is that all these functions are quite smooth in the 4D space of sun azimuth, sun zenith, LAI, canopy height so interpolation should be easy.

I’d be remiss if I didn’t mention another side project which may be the results of fever dreams. Direct air capture of CO2 probably needs to happen in a big way to save the climate at this point. Previously I’d been interested in using biomass to biochar as a nice low tech solution. The problem is, the potential is kind of too small. Even using all available forests it might not be enough sequestration.

Climeworks and others are working on a chemical absorption process… It’s pricey and requires a lot of industrial capital. High hopes labs piqued my interest with the idea of crystallizing solid CO2 from the stratosphere. I crunched some numbers, it could work, but logistically all these balloon ascents and descents are a nightmare. But what about the ocean? At 380 m of depth and 4c the CO2 in air will liquefy and can be drained off. By weight 1/2800th of air is CO2, so now the problem is how to move massive amounts air to 380 m deep and back again. I have some ideas and nothing seems like a show stopper… but this is not my area of expertise. I can’t find anything in the literature detailing a similar plan, so if you know of one please let me know. Anyhow, for now this is firmly in the “side projects” bin.

Whew! This week was hard! I cleaned up the rayctracer code data management and the python code for interpreting and plotting the data. Which sounds not too bad, but was very hard to keep everything working and organized. Probably that’s because I’m as good with python but it always has a tendency to turn into mess of scripts and not well organized like c++ into classes and functions.

Anyhow, I have finally got it running and not too bad of results: Here I traced a simple cube and compared the ray trace to the solcast file Ghi. It’s perfect for diffuse light. It’s just a little off on the direct light, and outside the error bars… I think this is related to the time used for calculating the sun position.

At any rate it seems accurate enough for my purposes. A lingering question for refractive media is that there seemed to be too many rays bouncing until they timed out (too many reflections). That’s something I’ll have to look into later, but in general that can happen in glazing due to total interior reflection. I saw it in the solTrace program and thought it was a bug at first.

This was a short week due to the Easter holiday, so I’m just getting to the update now. I deployed two boxes for ray tracing with sensors in the field by the test greenhouse. Then I used rayctracer to simulate the flux on the sensor using solcast data. The bare sensor agreed well with solcast global horizontal flux, so this is another validation of the rayctracer. I still need to collect the sensor data to compare.

There were larger error bars on the times with high direct flux. This makes sense, because the diffuse calculation uses all the rays equally, while the direct calculation is heavily influenced by a single direction. Plus, the direct light direction is approximate in the lookup of ray tracing data. So I think the way forward is to do a good diffuse calculation and save that as simply diffuse, then do a specific ray tracing for each direct light direction. The sun’s position is easy to predict so these can be done in advance for a real time prediction eventually.

More importantly, but less exciting, I worked on tidying up the python scripts for plotting and data analysis. I like c++. Python and I have a love hate relationship. Python has tons of useful libraries that are easy to import but it’s so slow if you have to write your own loop etc. Anyhow I’m trying to organize and speed up the plotting which has been a bottle neck for me.

I also got the book “How to Grow in a Modulair Glasshouse” by Dol. It’s been an interesting read and definitely useful on the growing side of things. I will hopefully do a better job irrigating the plants and steering them in the next growing experiment. It’s interesting that commercial growers are not using a mathematical model to predict the effects of their actions on crop growth. The model of Vanthoor is probably not sophisticated enough, though Dol alludes to “AI” driven management. Something to think about in the future.