School Study: Hudson River "The River that Flows Both Ways"

Thank you everyone!
We came in 1st place from all of the community voting! To see all of the entries, you can visit the original contest and other submissions.

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." The tide and the proximity to the Atlantic Ocean are the reasons for the change of direction every 6 to 8 hours.


She wanted to know if saltier 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 flotation device with a number of sensors, placed out far enough to measure the flow and other readings. Our design settled on building a low-cost device to measure the flow, and measure any sensors along the way. 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 comes in. This device would allow us to retrieve data in real-time over an LTE network to allow the class to plot daily graphs.


Why not use a Raspberry Pi, or an Arduino? The reasons to use an XBee were simple: MicroPython is available directly on the XBee module to process data; the XBee has such a low power draw compared to a larger Arduino or even a RPi Zero; ability to go into a very low-powered "sleep" state, as well as powering off all sensors during the sleep state (the trick is to use the DIO9 pin to power the sensors on wake); compact size and so on.

So the theory will be this: read inputs, interpret, format, buffer, and spit out results on long intervals. This is very much different than the way XBee normally works, which is to mirror the input/outputs between the device.

NOTE: This post is a work in progress and subject to change (e.g., we may no longer need a Raspberry Pi!).

  • Digi XBee3 Cellular LTE-M/NB-IoT w/LTE SIM Card
  • Raspberry Pi (it seems the XBee3 Cellular module itself has MicroPython built in!!)
  • Microchip MCP1826S-3302E/AB (3.3V, TO-92 style, ~1µA) VREG (shown as 78XX in diagram)
  • SUP500F GPS Receiver
  • TMP36 Air Temp Sensor
  • Custom made anchored Buoy or alike design
  • Large-enough batteries to last 24-48 hours minimal
TBD are various other sensors such as saltwater and pH (flushing in and flushing out), water temp, barometric pressure, etc since the XBee3 has several other inputs available. For example, I would like to add a battery voltage monitor on another input.

Future design enhancements could include:
  • Solar Charging for endless power
  • RPi Camera for compressed images over XBee and LTE

GPS and Temp sensors directly connected to XBee3, powered by an inexpensive voltage regular circuit to allow for larger batteries.

Additional XBee3 inputs may be utilized at a later time as project develops.

Hudson Riber Project - Schema_schem.png

Hudson Riber Project - Breadboard.png

Build Log / Progress

For the latest progress, check out our build thread over in the forums as we experiment and/or change directions and open discussions.
  • Setup the Digi XBee3 Cellular Module
  • Using MicroPython on the XBee3 Cellular Module (in progress)
  • Converting data locally on the XBee3 Cellular Module: No external processor?! (coming soon)
  • Processing GPS and sensors through XBee3 Cellular Module (coming soon)

Source Code

First, we need to break the project down into objectives to design, build, and test.
  1. Serial communications data bus over the XBee3 module
  2. Assemble and measure various sensors directly via XBee3, using MicroPython to interrupt/format forwarding data(?)
  3. How to determine the direction of the current/flow
  4. Stress testing (ability to float and stay upright, weather endurance, collision resistance, GPS accuracy, battery time, cell reception, etc)
  5. Launch!
Even these steps are a great way to teach and learn various levels of the project; therefore, we’ll be involving a number of children along the way.

Step 0: The XBee3 Cellular Module

We've never used an XBee before for projects. I always thought it was just a communication device. However, this project has opened our eyes to just how flexible (XCTU configuration), portable (low power consumption!), and adaptive (MicroPython) this little device can be.

Connecting couldn't be easier. Connect the antennas, insert the SIM card, power it on, and then to computer.

XBee-Setup-1 (1).png


The configuration options are outstanding. But some of the most surprising are the network options.

Digi-XCTU-Network-Options (1).png

I highly recommend going through the XCTU examples, if not only for a laugh.

XBee-Setup-Example-1 (1).png

Step 1: Serial 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, since we'll be sending over an LTE network.

TCP protocol seems straight forward for this. However, we don't want to flood the data bus. So we'll use some MicroPython to read all data inputs, interpret, and batch a single response on an interval. 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. UDP could also be a possibly by cutting down on the TCP overhead.

Encryption is not needed for project like this. However, I personally secure every device I can. Another option of the XBee3 Cellular module is to use TLS TCP! We’ll keep it simple and will issue our own self-signed certs that do not expire.

Step 2. Assemble and measure various sensors directly via XBee3, using MicroPython to interrupt/format forwarding data(?)

If we are measuring and sending GPS locations, why not add a bunch of sensor data along the way? There are not a lot of guides out there for these. So, as we add them, we'll create some additional Build Log posts here.

We’ll also want to build various sensor inputs and bundle them into the single binary packets we’ll be sending over the data bus. We'll also add a number of other metrics, such as battery voltage, internal temps, etc.

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.

  • TODO: Process funny video of daughter talking to the "Therapist" bot from Digi (or add it to the main video)
  • TODO: Video of build steps, assembly, launch, and retrieval

CAD Files
None. All enclosures will have to be hand built.

Blog entry information

Last update


More entries in General

More entries from eduncan911

Share this entry