Viewing blog entries in category: #Mouser
As part of our project Hudson River "The River that Flows Both Ways" with my daughter, let's setup our communications device: the Digi XBee3 Cellular Module.
Spoiler: Now that we got to play with the Digi Development Kit, it may have just uprooted out entire plans (for the good). MicroPython to the rescue!
A Brief Introduction to XBee Communications
XBee modules allow two or more devices to talk bi-directional using serial ports via a wireless connection. You typically configure and load firmware directly onto the XBee modules; and, once they are powered on, they can connect to each other and transmit and receive data. Your device connected to the XBee module just needs to open a serial port to start sending bytes directly, which transmits to another XBee device where the bytes are received.
(Photo courtesy of Embedded Basics)
There are many projects out there showing many forms of these communications. However, we have a different setup this time around: the XBee3 Cellular Module.
The Digi XBee3 Cellular Module
This particular flavor of the XBee family has a unique feature in that it can connect via cellular, as the name implies. Something else not really mentioned in the sparse packaging was that it also has a Bluetooth radio! We won't be using that this time around as our project is too far away for that. We can also disable the Bluetooth radio to save power consumption as well.
Setting up an XBee3
Digi requires you to install software called Digi XCTU to configure and write the firmware to XBee modules. For this development kit we are using, Digi has setup a Setup Guide that walks you through step by step how to setup and configure the device to connect to your LTE carrier.
It took a little digging around the Digi website; but, we eventually found the full documentation to this device - and much more!
The additional examples all worked as well. My daughter especially had some funny conversations with the ELIZA Therapist Bot example (tip: don't use Eliza as a real therapist).
Connects Directly to Server?!
During the setup process, I was surprised by all the different methods of Cellular connectivity this module has:
The example demos in the documentation all center around TCP. However, I am eyeing that SMS option for a future project. And, UDP is quite interesting for increasing some bandwidth by lowering the overhead of the TCP stack.
However, even more surprising was that I could configure a "Destination Address" - to connect directly to a remote IP and TCP port!
This means I do not need another remote XBee3 Cellular module. I just need this one device to talk to a remote server!
MicroPython - On the XBee3!?
The surprises didn't end there. The documentation then calls out MicroPython availability directly on the device! It promotes this feature as:
> You can use MicroPython to enhance the intelligence of the XBee to enable you to do edge-computing by adding business logic in MicroPython, rather than using external components.
Considering our entire project was based on setting up a Raspberry Pi Zero to take a few base sensor data and send it over the XBee3, we may be able to eliminate the RPi all together and use the XBee3 Cellular module instead!
This is just too cool.
In the next session, we'll focus on the MicroPython's abilities on the XBee3 to put it through it's paces with a few sensors.
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 MCP1700-3302E (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
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.
Build Log / Progress
- 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)
First, we need to break the project down into objectives to design, build, and test.
- Serial communications data bus over the XBee3 module
- Assemble and measure various sensors directly via XBee3, using MicroPython to interrupt/format forwarding data(?)
- 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)
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.
The configuration options are outstanding. But some of the most surprising are the network options.
I highly recommend going through the XCTU examples, if not only for a laugh.
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
None. All enclosures will have to be hand built.