Monthly Archives: March 2017

Progress with LoRa Transmitter/Receiver

Posted on by

Abstract:

In this blog post we go over how to we assembled the LoRa transmitter and receiver.  We include instructions on how to set up the Arduino IDE as well as the code for our test devices.


Update: Transmitter (left) and Receiver (right) on separate breadboards connected to portable 5V power sourcesUpdate: Transmitter (left) and Receiver (right) on separate breadboards connected to portable 5V power sources

Update: Transmitter (left) and Receiver (right) on separate breadboards connected to portable 5V power sources

Materials:

These are the components connected to now separate transmitter/receiver (pictured above): 

Transmitter:

– Matbotix 1220 sonar sensor

– RFM9X LoRa Radio

– Adafruit Pro Trinket (3V Logic) w/ FTDI cable connector

– Red LED

– 51 ohm resistor

Receiver:

– RFM9X LoRa Radio

– Arduino UNO (5V out) w/ macro USB cable connector

– 81 ohm resistor

– Red LED 

– White LED

The transmitter and receiver have been placed on separate breadboards in order to test the range on the LoRa chips.  Code on both the transmitter and receiver sketches has been rewritten to send and receive the data values measured by the MB1220.  Other changes include the replacement of the Arduino Uno development board with the smaller 3V Adafruit Protrinket.  If you haven’t already, you will need to set up your Arduino IDE so that it recognizes Adafruit’s development boards when plugged into the USB port using an FTDI cable.  

SETTING UP THE ARDUINO IDE: You will need to go into Arduino’s Preferences, paste the Adafruit Board Support Package URL into the space next to “Additional Board Manager URLS”, click OK, then go into the Tools tab and select the “Boards Manager” found in “Boards:”.  Filter your search by choosing “Contributed” from the dropdown menu and typing “Adafruit AVR” in the search bar.  Then install the package “Adafruit AVR Boards”.  Once installed, you can upload your Arduino sketches to the Pro Trinket by selecting “Pro Trinket3V/12MHz (FTDI)” from the Boards dropdown menu.

The Pro Trinket uses the Atmega328P chip – the same core chip as our Arduino UNO – making it easy to switch between the two.  When transitioning to the Pro Trinket I realized it lacked pins #2 and #7 as well as the level shifting featured on the UNO (5V input on the Pro Trinket will have to be reduced to 3.3V to prevent damage to the board). To accommodate the Pro Trinket, I replaced interrupt Pin#2 for Pin#3 and digital write Pin#7 for Pin#6 and applied these changes to the UNO so the transmitter and receiver code can be used for either board.   Here are the updated versions of the transmitter and receiver code.

I have provided links to more information about the Pro Trinket’s limitations compared to the UNO and step by step instructions for installing the Adafruit AVR package.

– Marissa Kwon Undergraduate Student Researcher

Super Validator Wick

Posted on by

Cutting up the wick has been the last part of getting the evaporimeter completed. The method used to cut the wick is quite unique. We placed densely-packed wick inside an acrylic tube and then froze it. This is done so that the wick is easier to cut because when it is dry it is difficult. Freezing it allows us to cut it with a bandsaw really quick.The wick is as long as the tube itself and then cut to size.  Here is a picture of what the setup should look like: 


Setup of the wick inside the tube.Setup of the wick inside the tube.

Setup of the wick inside the tube.

After cutting them we just insert them into the evaporimeter and let the water melt. We then fluff the wick and the system is ready to go. The only problem with this method is that the wick gets dirty while cutting. The bandsaw cleans itself on the wick and since the wick is white it is really noticeable.


Fiberglass wick after cutting and fluffingFiberglass wick after cutting and fluffing

Fiberglass wick after cutting and fluffing

Getting in the air

Posted on by

Author: Jonah Siekmann

A few weeks ago, I started putting together various different quadcopter builds and comparing cost, efficiency, and lifting power. I’ve come up with a few builds that I think are pretty solid:

I also had two drones laying around in my dorm that I’d built the previous year, and I figured I could use those to do some tests on how long they could stay in the air with a payload of a given weight, since that would give us concrete data on what specs might or might not work.

However, to do that I needed to rewrite the flight controller I’d written previously, because the old version used rate mode – which means that the quad didn’t know which way was up, and it was up to the user to make sure it stayed pointing in the right direction. To carry a payload (and eventually navigate autonomously) I needed to make the quadcopter autolevel – meaning the flight controller needs to know which way is up, and can stay pointing up (instead of say, pitched 30 degrees forward). 

So for the last few days, I’ve been putting together a new flight controller paired with an IMU (instead of a standalone gyroscope) and trying to get that working. I had an issue that kept me grounded for about half a week where the MPU6050 (the IMU I’m using) wouldn’t start up unless the Arduino Uno was plugged in through USB – I’m still not sure what exactly was causing that, but I wired it up to a UBEC and it worked fine.

Today, I flew the drone with a payload roughly the same weight as the RFID reader we’ll be using – about 750 grams. The drone flew surprisingly well with the extra weight, although it was still very difficult to manage – the PID values are tuned for a drone about 750 grams lighter. Here’s a picture of me trying my best to keep it in one spot (hence the facial expression):

However, I encountered an issue where it seems like the Arduino Uno shuts off randomly, while leaving the motors spinning – usually resulting in the drone flying into a wall or nearby bush. This isn’t a very desirable outcome when carrying a sensor package worth almost $500, so I need to figure out what’s causing that before we do any testing with it. I have a feeling it’s due to a crappy solder connection on my part, so over spring break I think I’ll just rebuild the whole thing and see if it keeps happening.

-Jonah Siekmann, URSA researcher

Logging data on Adafruit IO

Posted on by

By: Alex Grejuc

Today I finally succeeded in getting “data” (arbitrary numbers that I either hardcoded or looped through) from the Arduino through the ESP and to Adafruit IO.

I troubleshooted my bad requests by sending in AT commands manually through the Arduino serial monitor. After digging around on the internet, I found that the Arduino serial monitor does not recognize the \r and \n (carriage return and newline) escape sequences, so I sent each line of the GET request in line-by-line, and it worked.

This was manifesting itself in my code too because my character counts were off (the ESP AT command requires the length of the argument you are going to send it and will not work properly if it is off). After troubleshooting, I found the “correct” character count for my requests and I was able to receive a proper response from an Adafruit test page.

After this, I looked into sending a GET request to the IO platform with data. I was able to get this working as well and published some test data to an Adafruit “feed.”

I plan on cleaning up the code by writing some functions to make it more readable and easier to use as well as updating my comments now that I have a better understanding of the process. Once I do this, I will publish the code along with some of the resources that helped me along the way.

Here is a screenshot of some of the data on the Adafruit IO website.


Current Progress on ESP8266 data logging

Posted on by

By: Alex Grejuc

After learning to interface with the ESP through the Arduino and hosting the basic web server, I started working on actually using the ESP to get data from the Arduino and log it on an online internet of things platform.

I started out by looking into a few different IOT platforms: Adafruit IO, IFTTT, and Xively. Of the three, Adafruit seemed like the best option because it was free and had tutorials for integrating a custom Adafruit ESP breakout board.

I started out working from an Adafruit tutorial. to simply learn how to connect to the Adafruit server and receive a response. However, this tutorial was intended for the Adafruit custom board and uploaded the code directly to the ESP8266 with an Adafruit library. I spent time “translating” their code into AT-commands by determining what they were doing, finding an AT command for it, learning how it works, and then sending it over.

Connecting to a network and starting a TCP connection with the Adafruit server was easy to do, however, the HTTP GET request has provided plenty of trouble.

Initially, after sending the request the ESP replied with “Send OK” but did not receive or print the response to the Arduino serial monitor. After trying many things, I thought there might be an issue with the Adafruit server I was attempting to get data from.

I then decided to try sending a GET request to a different server in case that was indeed the issue, so I set up an IFTTT applet. It would send my phone a text message when a request was sent in, based it off of a tutorial someone made for interacting with IFTTT using the ESP. This seemed like a good approach because I could see if the GET request worked without even reading any response in with the ESP, in case that was the issue.

This also did not work, so Dr. Udell and I came to the conclusion that the Oregon State wireless network might prevent the ESP from receiving the response somehow. This turned out to be true: after connecting to two different networks on campus (an OSU robotics one and a personal cellphone hot spot), the ESP got a response from the server.

Unfortunately, the response is a “Bad Request Error 400” response that I have been troubleshooting since. It seems to be a common issue based on forums, but no clear solutions have been found. I hope to provide a more robust update with code, links, and information once I can successfully get the request to work.

A Successful Test

Posted on by

After about a week of waiting, the Adafruit DRV8871 H-bridge motor driver breakouts were delivered. They will replace the MOSFET circuit driving the pumps, which were allowing all kinds of noise and voltage spikes and caused the TPIC shift registers to reset every instance the pumps were switched on. Additionally, the previous electronics setup was mysteriously allowing the valves to leak water through to the sample bags when switched off. With the pumps being driven by the H-bridge, this problem has completely disappeared. The original cause was most likely related to the valves “soft resetting”, where each valve was neither completely off nor completely on after the pump was powered.

We just received an email today letting us know that the rest of the valves have finally shipped, which will allow us to completely assemble our 24 bag sampler! While we wait for that, I’ll be working on translating the electronics to a PCB and getting that printed. I’ll also be reviewing the design and adding more functionality to the code.

I recorded of a video of the system in action, included below, which is the first recorded successful test of our water sampler!

Em50G Data Loss Solution

Posted on by

Losing data while performing field test is very inconvenient. The sensor cables connected to this data logger come out very easily and this causes data loss. I made a small clip that locks on the cable and rests on the sensor socket. This will prevent the wire from coming out. Here is the 3D model of the piece: 

Gripv13 By Manuel Lopez Modelo »

This grip will fit on most sensor tips. It is strong enough to keep clamp on the sensors but flexible to accommodate bigger sensor tips. Here is the actual piece on the Em50G. 


One concern with this solution is that the pieces might get lost since they are individual grips. The other concern is that while placing or removing the piece, the board might get damaged. Here is another solution that was proposed:

 

squeezev1 By Manuel Lopez Modelo »

This solution provides a more compact design because it’s only one piece. This design has a strong grip on the cable by pressing it against the foam. Here is are images of the actual piece. This design takes a little more effort to put in because you have to press the top really hard to get the sidelocks to get in place. 



Finalized Pole Attachment for Super Validator

Posted on by

The main body of the pole attachment has been done for some time, but getting the wires of the strain gauge through the tube was the lasting thing remaining. The main trouble was that the wires would only go through a section of the guiding tube and then get stuck. They now go through all the way very smoothly. 


 First design with 90 degree corner First design with 90 degree corner

 First design with 90 degree corner


Second iteration with a smoother pathSecond iteration with a smoother path

Second iteration with a smoother path

The first iteration had a right angle that impeded the passage of the wires. It would only get through the hole but not through the corner. The logical next step was to reduce the amount of curvature that the wires had to go through. To work around this problem, I inserted a piece of wire through the top hole and soldered all the tips of the wires from the strain gauge together. I then pull the wire, and since all the wires were soldered to it, they all came through. This worked well but is not ideal. This is why further development was needed. 

The final design was different than what I was initially thinking about. There is no curve to the side instead there is loft coming from the side of the block in the form of a rectangle to a circle. This design makes it so that the wires don’t have to go through corners.  


Final design of wire guideFinal design of wire guide

Final design of wire guide


Cross section of wire guideCross section of wire guide

Cross section of wire guide

This is the iteration that will be used for testing in Kenya. Here is an interactive model of the piece:

Polev52 By Manuel Lopez Modelo »

Checkvalves… An update!

Posted on by

The rain catchment check valve was essentially shelved mid summer to move on to projects that showed more promise after poor performance of the design. Recently a researcher requested I send a couple check valves to her to set up in Kenya later in March, and so I decided to spend some time seeing if I could redesign the checkvalve in a more purposeful manner rather than trial and error, this time with more knowledge and resources (the Fusion3 F400 3D printer is so fast!). The purpose of the rain catchment check valve is to allow water through flow, while limiting the size of (ideally sealing) the drain to significantly reduce evaporation of collected water samples. The water flows from the TAHMO station to the checkvalve and drains into a collection bag.

This design would be based on a similar function as the last one: water flows into a chamber and raises a buoy, opening a drain that allows the water in the chamber to flow down and into the collection bag. I decided to incorporate an O-ring to assist in blocking the drain when little to no water is left in the chamber. While the original design allowed the buoy to be printed inside the chamber during the same print, using an o-ring meant the chamber and buoy should be printed as separate parts. This actually turned out to work better, anyways. In order to seal the top of the chamber a third part, the cap, would need to be made. I designed it to be twisted on the outside of the chamber’s top, pressing a large O-ring against the top edge of the chamber with enough force to form a watertight seal. 

To connect to the TAHMO station, the side opening slides over the TAHMO’s spout and a long ziptie is looped around the TAHMO station and the valve’s outer wall, pressing the two together. This means the water enters the chamber at a low velocity and angle, which is significant because the momentum of the water is directed nearly horizontally and initially at the top of the buoy. This means the force on the buoy from the flowrate of the water acts to tilt it off of its seal rather than add force to the seal of the O-ring.

One of the largest issues in the original design was the buoy’s lack of a correcting method after being tilted. There were two ways I could fix this: place the center of mass of the buoy as low as possible, and to find a way to limit its movement to the vertical axis. While I kept the first option in mind, such a small mass (<3g) can easily be overcome by small pressures such as a water droplet or a defect in the print. The fins on the side of the buoy act to prevent more than a couple degrees tilting.

The main problems to overcome are friction and catching on the sides of the chamber walls. Some dimensions require adjusting to properly fit onto the TAHMO station. Overall, this design works significantly better than the previous version.