[Shannon Hicks]

Try this: use X-CTU to reprogram both of the Xbee modules to 9600 baud and then change the baud rate in your Fio sketch to 9600 for the serial port and also 9600 for the software serial port (it’s easier and less confusing if everything uses the same rate). I’ve had trouble in the past with some of my Xbee units printing garbled text to the Arduino board at higher baud rates, so perhaps that’s where your mystery characters are coming from.

[Shannon Hicks]

Hi Dan and Jim,

You were at the Stroud Center last week attending one of our sensor station workshops, so your situation is a little different than most users on the forum. I’ll send you an email with more information about the stations and sensors and how we’ll be working with you in the coming months.

[Shannon Hicks]

I’m going to need more information if you want me to diagnose your problem. When you say “it doesn’t work”, do you mean that it doesn’t compile, or there’s no output on the serial monitor, or is there nothing transmitted by the Xbee?

Also, please answer these questions:
What type of USB-to-TTL adapter are you using to program the Fio?
How is it connected to the Fio?
How did you configure the Xbee radios? What settings did you change from their default values on the Xbees?
If one Xbee is in the Fio, where is your second Xbee and how are you viewing the received data?

[Shannon Hicks]

Past your code into this thread and I’ll take a look at it. Also, did you change the baud rate of the Xbee modules using X-CTU, or are they still set to the default?

Also, if you’re ever having trouble with a new sketch because you’re testing several new sections together for the first time, try removing some of them to simplify it and make sure each small block works separately before trying all of them together.

For example, remove all the SDI-12 stuff and the Xbee and the software serial and just make sure you can successfully get the FIO to say “Hello World” on the serial monitor port at 9600. Then use that same sketch but unplug the USB cable and put the Xbee module on the FIO. Use a separate battery (so you don’t get conflicts from the USB port) and verify that you see “Hello World” on your other Xbee coordinator receiver monitor. If you’re able to do that, then go back to the sketch and add the software serial on 2 unused pins and monitor that with your PC serial monitor. Verify that you see the same thing on the PC that you see on your Xbee coordinator. If all of that works, then you can add back the code for the SDI12 sensor.

Another thing to note is that you’re probably going to get an error when compiling the code if you’re using SoftwareSerial and SDI12 at the same time due to port interrupt conflicts. That’s why I created the SDI12_Mod and SoftwareSerialMod libraries that are found in our Github repo so that you can use those 2 libraries together without conflicts.

[Shannon Hicks]

If you’re using the Fio board, then your Xbee is forced to use the only hardware serial port on the board (pins 0 and 1). So if you really want to print out data to the serial port at the same time, you’ll need to use 2 other pins for that, using SoftwareSerial. I assume you’re using a FTDI adapter for connecting your Fio to your computer since the Fio doesn’t have built-in USB support. So just use some wire jumpers to connect the RX and TX pins of your FTDI adapter to 2 unused pins on your Fio and designate them as the SoftwareSerial pair in your sketch. So anything you want to send via the Xbee goes to the serial port, and anything you want to print on the computer’s serial monitor goes to the SoftwareSerial port.

But if you haven’t configured your Xbee using X-CTU or through at commands, then your Fio can’t communicate with the Xbee at 57600 baud so don’t use that speed in your sketch. You’ll have to either change the Fio sketch to 9600 or change the Xbee to 57600. Where are you transmitting your Xbee data to? I assume you have a pair of them and will use the other one as a receiver somewhere? Keep in mind that the baud rate that you configure for the Xbee’s UART communication is totally separate from the actual transmit rate of the modules. You’re only changing the speed at which the Xbee communicates with external UART devices. It doesn’t matter what speed you select, as long as the radio and the device are both using the same one.

[Shannon Hicks]

Do you only get that “extra junk” (as you described it) on the serial monitor when the Xbee is attached? It looks to me like you’ve got the Xbee radio on the same serial port as the board communication (the Arduino’s hardware serial port, which is pins 0 and 1), right? The Arduino board is talking to the PC at 57600 baud, but the Xbee has a default speed of 9600. So unless you changed that by programming the Xbee separately (using either the X-CTU program or a terminal and AT commands) then you’re going to get a mis-match between the 2 devices. But more importantly, you can’t have the Xbee on the same hardware serial port as the computer. That’s why I like the Mayfly, it has 2 hardware serial ports. The Mayfly talks to the PC serial monitor on the first one, and the Mayfly talks to the Xbee module on the second one.

If you’re using an Arduino Mega board (it has 3 hardware serial ports) or some of the other newer Arduino boards or derivatives, they sometimes have 2 hardware serial ports. But if you’re using the Uno, then you’ve got to implement a separate software serial port for the processor to talk to the Xbee module so that you can still print stuff to the screen. Otherwise, your Xbee module is going to try to transmit everything that you sketch is printing to the serial monitor and you’ll see random stuff on the serial monitor that’s coming from and going to the Xbee.

If you’re not familiar with Xbee’s and using software serial ports, you’ll need to find some examples of how to set that up.

[Shannon Hicks]

What kind of distance are you trying to cover with your radios? There are a variety of Xbee options that will work for short distances (several hundred meters), but there are also models for transmitting over a kilometer or more. There are different models for different regions of the world because of frequency regulations and other issues, so I can’t point you directly to a specific model, but I’ve had good luck with the 900MHz USA version of the Pro radios and a small external antenna.

For cellular options, we’ve had really good success with using SODAQ’s GPRSbee (https://shop.sodaq.com/en/gprsbee.html). All you have to do is add a SIM card and plug the GPRSBee into the Mayfly. We’ve also successfully used WifiBee modules with the Mayfly.

SODAQ also sells a LoRaBee (https://shop.sodaq.com/en/lorabee-rn2483.html) module, but I have not used it yet and can’t offer any advice on that, but I think it should work fine with the Mayfly as well.

[Shannon Hicks]

Most 16×2 LCD displays require 5v, but there are some that’ll work at 3.3v if you shop around. You could also use a 5v display with the Mayfly because you can use the 5v boost circuit to power it, but remember that you’ll have to do some logic-level shifting on the data pins. You could accomplish that by putting one of these inline between the Mayfly and the 5v display: https://www.sparkfun.com/products/12009

But I really prefer to use one of these OLED displays: https://www.amazon.com/Grove-128×64-Board-Arduino-Raspberry/dp/B01D5GLDJ2

It uses the same SSD1306 library as the Adafruit display you posted, but it’s got twice as many pixels since it’s 128×64 instead of 128×32, and it’s cheaper. And the big advantage is that it doesn’t require the separate RST pin like what’s on the Adafruit version, so instead of 5 pins (PWR, GND, SDA, SCL, and RST), it only requires 4 pins, so it has a standard Grove connector on the display board. All you have to do is connect the display directly to the I2C port on the Mayfly using a Grove cable (not included with the display when you buy it from SwitchDoc Labs on Amazon), load a sketch, and the Mayfly prints right on the display. I can post a sample sketch if you’d like.

[Shannon Hicks]

If you’re trying to use a Zigbee module and a microSD card with an Arduino board, you could buy a bee adapter shield and a memory card shield and stack them all together. If you’re logging data over time, you’ll also want a real-time-clock module to be able to timestamp the data on the memory card. But instead of trying to get 4 separate boards to work together, that’s why we created the Mayfly board. It has the Bee socket, memory card socket, real time clock, and several other handy features that make it super simple to do everything you’re looking for all with one board.

[Shannon Hicks]

No, you’ll never need an external supply even if you’re using dozens of 5TM soil moisture sensors. The reason is that the code I posted above will only power one sensor at a time. All of the other sensors are basically sleeping and using virtually no power until they are “woken up” one at a time by the call to their SDI12 address. One 5TM sensor only draws 10mA during measurement, which is only for a fraction of a second. So with all of the sensors connected to the 5V pin of the Arduino and essentially sleeping until they’re called individually for that fraction of a second, you’ll never run the risk of drawing too much current.

Now, if you switch to a different type of sensor, that is something to be cautious about, but it’s not a problem for the 5TM. And yes, connecting the external supply’s ground to the Arduino ground could allow you to power the sensors with the external supply, but it’s totally unnecessary in this case.

The hardest thing about hooking up multiple sensors to one Arduino is connecting all of the wires to one pin. In you case, 6 red sensor wires need to get connected to the digital signal pin, 6 white wires get connected to 5V, and 6 bare wires go to ground. You’ll either have to get creative with a protoboard or breadboard or wirenuts or something similar.

[Author]

Posts