Introduction
My daughter’s school studied the Hudson River in New York all year long and always brought home new and interesting facts of the river. One interesting fact was how the river "flowed both ways." This is due to the changing tides and its proximity to the Atlantic Ocean and would actually change its flow every 6 to 8 hours.
My daughter wanted to know if salter water entered in from the Atlantic. We always wanted to monitor the temp differences between the air and water and if it had any effect on the flow, salt content, etc. Even her school friends continue to talk about the Hudson throughout the summer. We often talked about a project to measure various things about the river; however, our trips to study it were often too short.
Therefore, to achieve these remote sensor readings, a project was born: a Raspberry Pi device with a number of sensors, placed out far enough to measure the flow and other readings. So we came up with a concept to build a device and measure the flow. That device can either be a buoy or a boat that simply floats.
But, how would we retrieve the data? This is where the low-powered Digi XBee3 Cellular Module kit comes in. This project would allow us to retrieve data in real-time to allow the class to plot daily graphs.
This project can easily be adapted for use for various remote sensors to work with any XBee Cell module and RPi using the gRPC source code and base structures, along the data bus and remote server code. All code and inputs were carefully abstracted to allow other users to take the project and modify to fit their means.
BOM
First, we need to break the project down into objectives to design, build, and test:
Step 1: RPi TCP communications data bus over the XBee module
We knew we wanted remote data retrieval in real time, or even batched in a timely manner. LoRa communications first came to mind; however, we do not have line-of-sight from our house to the river/location the buoy would be placed. Also, we were not sure where the US Coast Guard will have us deploy the device. Therefore, this is where the Digi XBee3 Cellular module comes in. So the project was designed around this module.
Next comes a parent (e.g. me) to use some software development skills. Our primary restriction is the low baud/data rate of the Xbee system. Therefore, we have to be careful on the TCP packet sizes and timeouts in sending and receiving ACKs over TCP.
The gRPC protocol over HTTP/2 seems optimum for this, as the data packets are serialized binary chunks of a predetermined format and we can wait indefinably for ACKs. gRPC is preferred because of its low overhead of keeping a long-lived connection. However, to save battery we won’t be using long-lived connections and will attempt to power-down the devices between updates, into a “deep sleep” mode. We’ll also avoid json to further cut down on packet size by creating a simple concatenated string of values. HTTP/3, using UDP, could possibly be of a further enhancement by cutting down on the TCP overhead.
Encryption is not needed for project like this. However, I personally secure every device I can. To achieve this, we only need to encrypt data-in-flight. This would be another advantage to HTTP/2 as it requires TLS encryption so we'll remain compliant. We’ll keep it simple and will issue our own self-signed certs that do not expire.
Step 2. Assemble and measure various sensors via RPi
If we are measuring and sending GPS locations, why not add a bunch of sensor data along the way? Being a Raspberry Pi, there is a plethora of guides out there with samples. So this step should be trivial.
We’ll want to build various sensor inputs and bundle them into the single binary packet we’ll be sending over the gRPC data bus. We'll also add a number of other metrics, such as battery voltage, internal temps, etc.
Going forward, we'll start calling this binary bundle, "The Package."
Step 3. How to determine the direction of the flows
We came up with two ideas: a stationary buoy anchored deep enough to allow the buoy to drift in one direction to measure the direction of flow via GPS changes; and, the other being a R/C boat we would launch and let "drift" over a few hours, measuring its position via GPS where we would retrieve the boat via remote control over that same cellular connection.
The buoy option seems the simplest because we would only need 1-way communications to send data as the R/C boat concept carries the risk of loss if we loose the GPS signal, battery runs dead (no more GPS positions), in-ability to properly control/sight/guide from 1000+ feet away to a location, etc.
The idea is simple: Take a few GPS measurements every 30 minutes and compare to previous results. As long as the GPS position data was precise enough to measure the drifting changes of the buoy, we’d know the direction of flow.
Let's figure a drift-distance of at least five meters from one direction to the other. To calculate this, we'll need to know the depth of the water at the place the US Coast Guard determines we can drop it at. Then a little geometry will help us come up with the exact length of line from the anchor to the buoy.
Step 4. Stress Testing
Oh, the fun parts! There’s nothing like asking your 7 year old to try to destroy something, on purpose.![:)]( "Smile :)")
But before we get to that stage, we’ll need to design our flotation device.
We’ll need to consider several objectives: Highly visible (to avoid collisions), ability to stay upright when blown/knocked over, and would not deteriorate being in the water for long periods of time. Not to mention, asking a 7 year old to take a yard stick to it to see how it withstands a simulated boat hit. We’ll also need something water-tight; but, to allow us to run a few antennas outside as well as sensors and sensor wires in and out of the device.
Step 5. Launch!
As with each step above, there are number of objectives needed for this step as well. What location would best measure the direction of water? Will it be in the way of boat and Coast Guard traffic? Contact the Coast Guard and ask for permission. Etc.
Once we have the answers and permission completed, we’ll finally need – a boat! Since we do not own one, we’ll need to find a way to launch it at the predetermined position; and, to retrieve it.
A word about Solar Power…
This would solve our power issues in the long run. However, we currently do not have much experience with, nor have a collection of solar devices for things like this. It would be great to add it to the bucket list; however, we are short on time on this project and felt it was out of scope.
So, we’ll plan on sticking as many batteries as possible together to make it last as long as possible. Because in the end, we only need to measure a few cycles of the tides, which is every 6-8 hours. So possibly a 24-48 hour cycle is all we need before the batteries die.
Video
TODO: Make sure to abstract, break up, and paste github links to...
None. All enclosures will have to be hand built.
My daughter’s school studied the Hudson River in New York all year long and always brought home new and interesting facts of the river. One interesting fact was how the river "flowed both ways." This is due to the changing tides and its proximity to the Atlantic Ocean and would actually change its flow every 6 to 8 hours.
My daughter wanted to know if salter water entered in from the Atlantic. We always wanted to monitor the temp differences between the air and water and if it had any effect on the flow, salt content, etc. Even her school friends continue to talk about the Hudson throughout the summer. We often talked about a project to measure various things about the river; however, our trips to study it were often too short.
Therefore, to achieve these remote sensor readings, a project was born: a Raspberry Pi device with a number of sensors, placed out far enough to measure the flow and other readings. So we came up with a concept to build a device and measure the flow. That device can either be a buoy or a boat that simply floats.
But, how would we retrieve the data? This is where the low-powered Digi XBee3 Cellular Module kit comes in. This project would allow us to retrieve data in real-time to allow the class to plot daily graphs.
This project can easily be adapted for use for various remote sensors to work with any XBee Cell module and RPi using the gRPC source code and base structures, along the data bus and remote server code. All code and inputs were carefully abstracted to allow other users to take the project and modify to fit their means.
BOM
- Digi XBee3 Cell Kit w/LTE SIM Card
- Raspberry Pi (for all sensor data processing and communicating with the XBee module)
- GPS device to track its location
- Various sensors: Salt Water and pH (flushing in and flushing out), Water Temp, Air Temp, Barometric Pressure, etc.
- Anchored Buoy or alike
- Large-enough batteries to last 24-48 hours minimal
- Solar Charging
- RPi Camera for compressed images over XBee and LTE
- TODO: Raspberry Pi connections w/XBee & sensor Inputs graphed via Fritzing
First, we need to break the project down into objectives to design, build, and test:
- RPi TCP communications data bus over the XBee module (and be two-way if using R/C boat)
- Assemble and measure various sensors via RPi
- How to determine the direction of the current/flow
- Stress testing (ability to float and stay upright, weather endurance, collision resistance, GPS accuracy, battery time, cell reception, etc)
- Launch!
Step 1: RPi TCP communications data bus over the XBee module
We knew we wanted remote data retrieval in real time, or even batched in a timely manner. LoRa communications first came to mind; however, we do not have line-of-sight from our house to the river/location the buoy would be placed. Also, we were not sure where the US Coast Guard will have us deploy the device. Therefore, this is where the Digi XBee3 Cellular module comes in. So the project was designed around this module.
Next comes a parent (e.g. me) to use some software development skills. Our primary restriction is the low baud/data rate of the Xbee system. Therefore, we have to be careful on the TCP packet sizes and timeouts in sending and receiving ACKs over TCP.
The gRPC protocol over HTTP/2 seems optimum for this, as the data packets are serialized binary chunks of a predetermined format and we can wait indefinably for ACKs. gRPC is preferred because of its low overhead of keeping a long-lived connection. However, to save battery we won’t be using long-lived connections and will attempt to power-down the devices between updates, into a “deep sleep” mode. We’ll also avoid json to further cut down on packet size by creating a simple concatenated string of values. HTTP/3, using UDP, could possibly be of a further enhancement by cutting down on the TCP overhead.
Encryption is not needed for project like this. However, I personally secure every device I can. To achieve this, we only need to encrypt data-in-flight. This would be another advantage to HTTP/2 as it requires TLS encryption so we'll remain compliant. We’ll keep it simple and will issue our own self-signed certs that do not expire.
Step 2. Assemble and measure various sensors via RPi
If we are measuring and sending GPS locations, why not add a bunch of sensor data along the way? Being a Raspberry Pi, there is a plethora of guides out there with samples. So this step should be trivial.
We’ll want to build various sensor inputs and bundle them into the single binary packet we’ll be sending over the gRPC data bus. We'll also add a number of other metrics, such as battery voltage, internal temps, etc.
Going forward, we'll start calling this binary bundle, "The Package."
Step 3. How to determine the direction of the flows
We came up with two ideas: a stationary buoy anchored deep enough to allow the buoy to drift in one direction to measure the direction of flow via GPS changes; and, the other being a R/C boat we would launch and let "drift" over a few hours, measuring its position via GPS where we would retrieve the boat via remote control over that same cellular connection.
The buoy option seems the simplest because we would only need 1-way communications to send data as the R/C boat concept carries the risk of loss if we loose the GPS signal, battery runs dead (no more GPS positions), in-ability to properly control/sight/guide from 1000+ feet away to a location, etc.
The idea is simple: Take a few GPS measurements every 30 minutes and compare to previous results. As long as the GPS position data was precise enough to measure the drifting changes of the buoy, we’d know the direction of flow.
Let's figure a drift-distance of at least five meters from one direction to the other. To calculate this, we'll need to know the depth of the water at the place the US Coast Guard determines we can drop it at. Then a little geometry will help us come up with the exact length of line from the anchor to the buoy.
Step 4. Stress Testing
Oh, the fun parts! There’s nothing like asking your 7 year old to try to destroy something, on purpose.
But before we get to that stage, we’ll need to design our flotation device.We’ll need to consider several objectives: Highly visible (to avoid collisions), ability to stay upright when blown/knocked over, and would not deteriorate being in the water for long periods of time. Not to mention, asking a 7 year old to take a yard stick to it to see how it withstands a simulated boat hit. We’ll also need something water-tight; but, to allow us to run a few antennas outside as well as sensors and sensor wires in and out of the device.
Step 5. Launch!
As with each step above, there are number of objectives needed for this step as well. What location would best measure the direction of water? Will it be in the way of boat and Coast Guard traffic? Contact the Coast Guard and ask for permission. Etc.
Once we have the answers and permission completed, we’ll finally need – a boat! Since we do not own one, we’ll need to find a way to launch it at the predetermined position; and, to retrieve it.
A word about Solar Power…
This would solve our power issues in the long run. However, we currently do not have much experience with, nor have a collection of solar devices for things like this. It would be great to add it to the bucket list; however, we are short on time on this project and felt it was out of scope.
So, we’ll plan on sticking as many batteries as possible together to make it last as long as possible. Because in the end, we only need to measure a few cycles of the tides, which is every 6-8 hours. So possibly a 24-48 hour cycle is all we need before the batteries die.
Video
- TODO: Video of build steps, assembly, launch, and retrieval
TODO: Make sure to abstract, break up, and paste github links to...
- Establishing and maintaining gRPC long-lived, bi-directional connection to a remote server
- Remote server "listener" source code
- Reading sensor data on intervals, sending on data bus
- Listening on data bus, receiving instructions/updates
- Receive gRPC bus data and plot on graphs
None. All enclosures will have to be hand built.