The devil is in the details, and the process of ensuring stable operation has been full of them.
Issues during recent deployment
After multiple attempts with intermittent data transmission, it’s time to rebuild the nRF protocol. Some observations from the last deployment on 22 January 2019:
Range tests (simple call-response between nodes) on site are robust beyond 400 meters, when the required range is only around 150 meters.
Boosting the power with radio.setPALevel_MAX is essential to achieve desired range
The entire sequence only works intermittently from HyperRail hub to the sensor package, back to the hub, and forwarded to the ethernet base station at the main office.
The larger distance between the greenhouse and the ethernet hub is the component that is dropping data packets
The physical range constrained by the hardware does not appear to be the issue with the current nRF chips (Itead nRF24L01 + PA + LNA). Therefore, the code must be modified to address potential timing/network updating issues
I will work with the Loom team this week to “Loomify” the nRF protocol by swapping in the Loom functions for each of the 3 nodes.
Before next deployment, the system will be tested by recreating the field conditions to the best of our ability
On the bright side:
Around 50 data points were successfully sent, and the hardware was all very stable, especially the HyperRail system. The end is in sight!
The full-scale deployment has been successfully tested on a 25-meter OPEnS HyperRail. The full transmission sequence was verified from hub to sensor node, back to the hub, then relayed to an ethernet hub over 100 meters away. CO2 and other sensor data was sent from the greenhouse to Google Sheets and plotted in real time.
Three nRF transmission boards are under testing for reliability and range (Itead, SparkFun, Amazon). When the nRF is proven stable, the deployment will start running continuously with the help of a wireless charger.
More updates to follow in January 2019 with a live data feed from Google Sheets.
The custom PCB's are in, and the system is nice and stable. The Powerboost 1000c powers everything well, running off a 3.7V battery. The wireless inductive charging system also works as planned.
The first iteration of a 3D-printed enclosure could use a couple of adjustments, but it will work for initial testing. The main issue is that the HyperRail may be long enough to require an antenna for the nRF chip, which will not fit in the current enclosure.
The software reliably integrates the sensor system with the HyperRail with easy customization of time and distance intervals. Data can be transferred to the hub and forwarded to a second base with Ethernet capability up to 400 meters away. Construction, deployment, and experimentation begin in early September.
Check out the pics below for the enclosure, PCB, and powering system.
A big step for eGreenhouse today - we're connected to the internet! PushingBox code is integrated into the HyperRail hub code that pushes sensor data directly to Google Sheets. I set up my own account, so I can log up to 1000 data points per day (roughly every minute and a half).
Other new developments:
By digging into the documentation and doing some testing, we've determined that the whole system can run well on 5V. This means we can use a 3.7V battery pack with a Powerboost 1000C breakout board to boost up to 5V. This setup should be nice and efficient.
Also, the UART data lines (RX/TX) on the CO2 and particle sensors both run on 3.3V logic, so there's no need for a logic level converter.
I've crafted the new streamlined version with everything included into a custom PCB that's ready to send off for manufacture when can verify the Powerboost works as anticipated.
I built a 3-meter HyperRail in the OPEnS Lab, so I'm ready to scale up to the full version at the experimental location when parts arrive.
Run a 3-4 day experiment on campus to work out any kinks in the system before full deployment
Calibrate the K30 using an Irgason on campus
Design an attachment system for the sensor package on the rail
Great progress today - we got CO2, lux, temp, and humidity to transmit to the hub while the HyperRail moved the sensor package in specified increments. Video posted below.
The HyperRail GUI now allows for specification of the travel length, speed, and distance between stops. When the sensors get to each new location, the hub tells which sensors to take readings. Once the readings are complete and the hub receives the data, it moves the package down the rail to the next sensing location.
Next, we'll add a box to the GUI that allows the user to select which sensors to take readings from, without having to hard-code it. Also, the user will be able to select the time interval between runs down the rail and make it automatically loop throughout the day.
Crossed a major hurdle yesterday - the sensor package now communicates back and forth with the HyperRail hub.
The sensors wait for a signal from the hub, which sends an array of zeros and ones telling each sensor whether or not to take a reading. Once the readings are complete, the data is saved to the Adalogger SD card, then the values are sent back to the hub.
Next, we'll work on the timing at the hub to move the sensors a specified distance, wait for data, then move on. After that, I'll work on a live stream to the internet (Adafruit.io or Google sheets) from the hub.
A temporary voltage divider circuit was created with resistors to knock the K30's data lines down from 5V to 3.3V for the Feather. A logic level shifter (https://www.sparkfun.com/products/12009) is on its way for the proper setup.
I'll work on getting everything up on the GitHub page including wiring.
A successful Monday - got the entire sensor suite running properly.
One notable - and very easily preventable - issue that I ran into: I had wired the RTC into a ground rail that didn't tie back to the Arduino's ground. Always double-check your grounds! It's easy to overlook, but it can cause a lot of confusing data problems. A teachable moment, at least.
Testing in the greenhouse begins this week. I'll replicate the previous study's conditions as much as possible to see what kind of correlation we find.