Since my last blog post, the Hub has been making its rounds to conferences and demos from interested parties.
The Hub made its first conference appearance at the American Geophysical Union at the Fall meeting in 2017 in New Orleans, LA and again this past winter at the AGU meeting in Washington DC. In Novermeber of 2018 the first academic peer reviewed draft of the OPEnS Hub paper was sent in to the Frontiers in Earth Science special topics section.
Today I am proud to announce that the Paper has been accepted for publication and is currently being typeset! A link to the abstract can be found here.
I can’t wait to see where this project goes from here and I am happy to have been a part of its creation.
Smart Rock rev 2 has been making great progress! Current focus has been around finalizing what electrical components will be used and minimizing the overall size of the Smart Rock.
As you can read in our last blog post, preliminary sensor testing has been completed. Since then, we have integrated the sensors together with a custom PCB that will be used in the Smart rock.
Over the past few weeks, the Smart Rock team has been collaborating with Laurie Childers to design a ceramic cover for the Smart Rock. This cover will act as protection, camouflage, and means of securing the smart rock in place.
Next steps include:
Running calibration tests for the total dissolved solids sensor we are working with
Integrating and testing Bluetooth communications with OPEnS Project LOOM
Finalize components and minimize components used to save space
Finalize the current case design
Identify methods of securing the Smart Rock to stream beds using the ceramic cover
To begin, we’ll assume that you’ve completed the Navspark EVB Getting Started guide. This is a prerequisite for programming the GPS units in this tutorial. Without getting an RTK measurement, we can’t be certain that the GPS unit’s serial port has been reconfigured properly
A 3D Position Fix in GNSS Viewer
An RTK Float in GNSS Viewer indicates the serial port baud rate is correctly programmed
The above images show a GPS rover receiving RTK corrections correctly on a serial port at 57600 baud from the GPS base. The position starts as a 3D fix and eventually resolves to a Floating RTK measurement. Now, we are going to program the rover and base to communicate at 115200 baud so that they can be used with the Freewave radios!
Programming the Base
This step is relatively simple: connect to the base by setting the baud rate in GNSS viewer to 57600 and then click “Scan Port” in the lower left corner of viewer. If you don’t see the base in the viewer, it is either not connected properly to the computer or not at the baud rate that you selected.
To set the RTK output baud rate, select “Configure Serial Port” from the “binary” dropdown menu. Set the baud rate to 115200 and update to SRAM and Flash.
Setting the base baud rate, 1
Setting the base baud rate, 2
Programming the Rover
Before setting the rover’s baud rate, we need to understand how the serial ports work. The each GPS has a master and slave UART. The slave UARThandles the RTK data and the master UART handles position calculation and resolution. The RTK data comes into the unit via the slave’s UART on (RX2) and is then processed and the NMEA (position) strings come out on the TX1 pin. So, to program the slave’s baud rate, we have to enter a passthru mode!
Click on the “RTK” dropdown menu, and then click “Enter Slave UART Pass Through (Master Only)” from the “RTK-Pass Through” option.
After using this command, the GNSS viewer should stop updating the position and new position data will no longer be coming in (visible in the serial window). Next, set the baud rate the same way as we did for the RTK base. Finally go back to normal mode (Menu option below “enter slave UART pass through). Connect the two GPS modules and wait for the rover to get an RTK Float and hopefully an RTK fix (depends on satellites in view).
Now that we can send and receive data using the Freewave radios on passthru mode, it’s time to use them to send RTK data and get and RTK fix with a GPS. If you’re using this post as a guide for connecting the radios and haven’t yet sent data via the radio link, go back to the first configuration of the Z9-T DEVKIT blog post and follow the setup procedure listed there.
Terminology Used
Rover: The rover is the GPS unit used to read actual position measurements. It receives corrections from a “Base” GPS unit to resolve a very specific geo-spatial reading.
Base: The base is the GPS unit that has a stationary position and sends RTK corrections to the “rover.”
Gateway: This is the server radio in a network. Its serial RXD connects to the Base’s serial TX. There can only be one gateway in a network and any data received by the gateway’s serial RX transmitted to all the endpoints in the network.
Endpoint: This is the radio that receives all data transmitted by the gateway. With our application the endpoint’s are connected to the rovers in the network. The endpoint’s TXD connects to the GPS RX2.
Settings for GPS RTK Data
The Navspark S2525F8-GL-RTK is an RTK GPS module that is able to use corrections sent from another receiver to cerrect it’s readings and improve GPS spatial resolution from 3-5m to 1cm. Two GPS units are set up as “rover” and “base.” The base sends correction data to the rover on a UART serial connection, the rover then uses these corrections and outputs location strings in NMEA format on a separate UART.
Here are the settings for RTK communication:
Freewave shell settings for the Gateway radio.
Freewave shell settings for the endpoint radio
Configuring hardware for transmission
After the radios have been configured, disconnect them from their power sources. On the gateway, move the 5 pin x 2 pin jumper block to the D9 TTL port setting. The D9 TTL connector is used for communication with the GPS unit. To connect the D9 port to the Navspark base, use female stacking row headers (a row of 4 and a row of 5) inserted into the D9 port and jumper cables connected to the Navspark’s RX1 and GND pins. The GPS GND connects to the Freewave GND (D9 TTL port, pin 5) and the GPS TX1 connects to the Freewave RXD (D9 TTL port, pin 3).
Female stacking row headers interfaced into D9 serial port
To verify that data is being read, sent, and received with the Freewave radios, power on the endpoint and connect it to an opened terminal. Check that the endpoint is communicating with the terminal by opening the Freewave shell. Check that system.serialmode=Passthru_Data, then save and exit the Freewave shell but leave the terminal open. Now that you’ve updated the settings for the radios’ serial protocol, check the Tera Term serial port settings and make sure that they are matching the settings the freewave SerialPortConfig showed. Specifically the baud rate is 115200 and flow control is off. Once you see the terminal filling with random characters coming in once every second with the settings as shown, the Freewave radios are properly programmed for this test.
Getting the RTK Fix
Once the endpoint is receiving the RTK data and the terminal is displaying this transmission, disconnect the radio from the computer and power. Change the endpoints 5 pin x 2 pin routing jumper to the TTL side so that the signals are routed to the D9 serial port.
Routing Jumper Configuration
Next, connect the Navspark rover’s GND to the Freewave endpoint’s D9 GND (pin 9) and the Navspark RX2 to the Freewave endpoint’s TXD (pin 2). Power on the Navspark GPS by connecting the mini USB connector to your computer. Open up the GNSS Viewer to see the GPS position data in real time. Then power on the Freewave.
Within the GNSS viewer you should be able to see the GPS position measurement go from 3D position fix to differential GPS to RTK Float to RTK Fix within a few minutes. Once the position reading is RTK float you can be certain the Freewave radios are connected and working properly.
If you can’t get a RTK position, here are a few things to try:
Make sure the base’s antenna has not been moved since being turned on. Just power cycle it to have the base resolve a new fixed location within a couple of minutes.
Check that the GPS can get an RTK position reading with the hardwired serial connection shown in the Napspark Getting Started guide.
Make sure that the freewave radios are configured properly.
Program the GPS rover serial port baud rate to be 115200. Program the GPS base serial port baud rate to be 115200.
In future Smart Rocks, water velocity, dissolved oxygen, pH, and nitrate will be researched for implementation. We look forward to determining the feasibility of these measurements closer to the summer of this year.
Additionally, this Smart Rock will utilize a Reed Switch. The switch allows for the Smart Rock to remain dormant until a user interacts by holding a magnet near the device. Smart Rock can save battery this way.
This Smart Rock will also use a feather m0 adalogger featherwing– an add-on to the feather m0 that has a real time clock and micro SD storage.
For the upcoming weeks, a custom PCB, internal structure, and external structure will be designed to make the Smart Rock compact, water proof, and electronics accessible. A ceramic shell will be custom made to make the device look like a rock while keeping electronics hidden.
OPEnS House 2019 was a public event where academics from Oregon State University and industry professionals interested in environmental sensing could check out some awesome projects, ask questions and get a better idea of some of the research going on within the lab.
For the event the SlideSentinel team decided to get a working demo up and running to showcase the system so far. This demo provided the perfect opportunity to integrate working components into a single coherent system.
To set the demo up the team deployed the hub on top of OSU’s Weiniger Hall. The Hub contained the RTK GPS module, the Freewave Z-90 for receiving NMEA strings from the rover and the Adafruit FONA 808 for making HTTP requests to the PushingBox API capable of logging the rover locations in realtime to a Google spreadsheet. The total distance between the hub and rover was roughly 1000ft. This was super exciting news as the link travelled through multiple concrete buildings and data was still being received by the hub, intact and at a consistent rate.
The Rover for the demo featured a relay module tired to a real time clock and accelerometer. Upon substantial orientation change or movement the accelerometer would flip the relay to power the devices, and the Rover would attempt to get an RTK fix and begin sending NMEA strings to the hub. For a better visual representation of the system the team logged the coordinates on the Google spread sheet to a Google map in real time.
The demo went incredibly well and it was super exciting to see all of the components working together! During the live demonstrations team members would take the rover and go on a brief walk, and spectators could observe as the rovers location was logged live to the Google map in real time.
The OPEnS house was an awesome opportunity to showcase some of the work that has gone into this project. The team met multiple other researches and academics interested in the technologies we are developing and are looking forward to a live deployment in March.
ROCKBLOCK is an out of the box satellite communication module manufactured by Rock7. The device is constructed to interface with embedded microprocessors such as Arduino’s and Raspberry Pi’s. What makes the ROCKBLOCK such an incredible device (and also an appealing tool for the SlideSentinel project) is the fact that it can send Short-Burst Data (SBD) through the Iridium Satellite constellation, an aggregate of 66 active satellites used for worldwide voice and data communication. This means that projects using the ROCKBLOCK satcom module can send and receive data from a basestation from just about anywhere on the surface of the Earth that is exposed to the open sky.
Slide Sentinel Use Cases
ROCKBLOCK+ placed outdoors for signal testing.
Due to the remote nature of the SlideSentinel deployments and potential weather hazards, the team has opted to use the ROCKBLOCK module for sending data from the base node to servers where it can be further processed and recorded via Google spreadsheets.
ROCKBLOCK+ Interface
The ROCKBLOCK+ exposes a 7 wire interface
GND
9-30 VDC input
RS232 TX
RS232 RX
On/Off control (sleep pin)
Ring Alert Indicator
Network Availability
For simple use cases involving synchronously sending data, the only needed pins are the RX and TX lines, however the On/Off control pin, Ring Alert Indicator, Network Availability offer useful functionality which merit discussion. The ROCKBLOCK+ has an internal super-capacitor which requires roughly 10 seconds to charge. Once charged the module can begin sending data. If you are constructing a time critical application the On/Off control pin puts the module into a “sleep” mode, in which minimal power is consumed to maintain the super-capacitors charge. This allows the module to wake up quickly (perhaps due to an interrupt) and skip the 10 second capacitor charge wait before sending data.
The ring alert indicator is an active low output from the ROCKBLOCK+. When the voltage on the pin goes low there is a in incoming message in the MT queue which can be read by the module. This pin is useful for bidirectional communication with the module.
Finally the ROCKBLOCK+ presents an active low network availability pin. When the ROCKBLOCK+ module is on, the device periodically polls for an available Iridium satellite connection. If such a connection is found there is a high likelihood that data can be sent and received by the device and the network availability pin will go low.
For the official developer documentation on the ROCKBLOCK module follow this link.
Talking the ROCKBLOCK+’s Language, RS232
All outputs and inputs to the ROCKBLOCK+ must present RS232 voltage levels. Thus if communicating with the module with a TTL device an RS232 level shifter must be used. In the case of the SlideSentinel project the Adafruit Feather is used to send AT commands to the module. For testing the module on a breadboard we used the MAX3232 IC, which convert 3.3 volt TTL to RS232 and has two line drives and receivers. This linked article provides a concise explanation on the RS232 standard.
In order to receive the network availability, On/Off, and ring indicator signals an RS232 level shifter with at least four receive lines is required. For the SlideSentinel PCB interface to the ROCKBLOCK+ we decided to use the MAX3242 IC which presents 5 receive lines and 3 transmission lines.
With the RS232 interface configured the last step is sending AT commands to the module. The IridiumSBD is a convenient library for interfacing with the modem. Below are three photos depicting the a serial output from an Arduino script which communicates with the ROCKBLOCK+, a picture of the probed RS232 UART signals between the Arduino and ROCKBLOCK and the PCB designed to interface with the module for the Adafruit Feather. The Arduino script asks the module for its firmware version, then is asks the module for a number between 0-5 indicating signal strength and finally sends an AT command which transmits the string “Hello World.”
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
Next Steps:
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!
Smart Rock Rev 2 is making headway as the new staff catch up with the project. New design criteria is being laid out and tasks are being distributed. The two task categories are electrical and mechanical. On the electrical side, an optical flow sensor has been purchased to test and see about possible use. The sensor will be used for water flow rates. Reed switches are coming in to be tested as an option. The Smart Rock would ideally be off for the majority of the time while deployed to conserve battery. A reed switch can be used to turn on the rock, connect, and collect data. On the mechanical side, the rock will now be horizontal rather than vertical and more water-tight than previously. OPEnS House is coming up soon and a poster is being put together.
Abstract: An update on where the Evaporometer is and addressing the issues as well as what the future plans are for the project.
Temperature Compensation Issues:
There are a few things that we are in the process of implementing within the project. To start, temperature data collected last summer had readings that spiked from 26 degrees to 700+ degrees resulting in huge inaccuracies. The reason is because the previous Op Amp would fluctuate in mass when the temperature changed. To fix this issue, we are replacing the previous OP amp with an INA125P to hopefully reduce temperature compensation problems.
Sustainability:
Another improvement we are hoping for this year is sustainability. We are changing the material of the Evaporometer from ABS to ASA filament in order to weatherproof the encasing, making these devices last longer. Depicted below is the encasing after a 3-6-month period vs. newly printed encasing. By using ASA filament, we can reduce the yellowing of the encasing from overexposure of UV radiation.
3-6 Month Used Evaporometer vs. Newly Printed Evaporometer
Future of Evaporometer
Dr. Selker is planning on deploying approximately 50 Evaporometers to Africa around May.
