[Shannon Hicks]

I am still awaiting the shipment of the latest order from the manufacturer. They had a 3-week holiday last month that put their production almost a month behind schedule. I also had do to an extra round of prototype testing in January because we’ve added and changed a few things on the new v0.5 board. Once I get the new boards, I thoroughly test and program each one, then box them up as either bare boards or kits, and ship them to Amazon for fulfillment, which will hopefully be later in February. Amazon is our only distributor right now, but we are still investigating other options for international sales.

[Shannon Hicks]

Just do the software fix as suggested above and leave the clock interrupt on A7, then you won’t have to worry about doing any wiring changes. I added the D10 interrupt option on version 0.4 and higher because I thought it might come in handy for people who had interrupt library complications. But it works just fine if you simply use the modified libraries instead.

I’m still waiting for the shipment of boards from the manufacturer, but hope to have them and the protoshields on Amazon by the end of the month.

[Shannon Hicks]

The error you’re getting is because the SoftwareSerial library uses an interrupt method that conflicts with the SODAQ_PcInt library. In order to use those 2 libraries together, you have to use the modified versions of the libraries we posted in our Github repo, along with modifying the library names in your sketch in 3 places. Plus you’ll need to change the pins for your Atlas sensors to use 10 and 11 instead of 6 and 7. This is because the SoftwareSerialMod library ignores interrupts on the port that includes all of the analog pins (where the DS3231 interrupt is on A7) and it ignores pins D0-D7. This allows people to use the SDI12_Mod library to look at SDI12 sensors on pin D6 or D7.

So download all of the libraries from our repo: https://github.com/EnviroDIY/Libraries/tree/master and be sure to follow the instructions on that page about how to download the .zip file from the tree and not use the green “clone or download” button.

Once you have the libraries installed, restart you IDE and then modify the top section of your code to point to the new library filenames and update the pin numbers. It’ll look like this:

Arduino

#include <Wire.h> #include <avr/sleep.h> #include <avr/wdt.h> #include <SPI.h> #include <SD.h> #include <SoftwareSerialMod.h> #include <RTCTimer.h> #include <Sodaq_DS3231.h> #include <Sodaq_PcInt_Mod.h> RTCTimer timer; #define rx 11 //D11 to Tx on EZO (white on Grove conn) #define tx 10 //D10 to Rx on EZO (yellow on Grove conn) SoftwareSerialMod myserial(rx, tx); //define how the soft serial port is going to work. String dataRec = ""; String sensorstring = "EZO data"; //a string to hold the data from the EZO product

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <Wire.h> #include <avr/sleep.h> #include <avr/wdt.h> #include <SPI.h> #include <SD.h> #include <SoftwareSerialMod.h>     #include <RTCTimer.h> #include <Sodaq_DS3231.h> #include <Sodaq_PcInt_Mod.h>   RTCTimer timer;   #define rx 11                 //D11 to Tx on EZO (white on Grove conn) #define tx 10                 //D10 to Rx on EZO (yellow on Grove conn) SoftwareSerialMod myserial(rx, tx);   //define how the soft serial port is going to work. String dataRec = ""; String sensorstring = "EZO data";            //a string to hold the data from the EZO product

I compiled your code with the above changes and get no errors.

Or if all of this is too complicated, and you have Mayfly board v0.4, you can simply cut the trace on the back of the board on JP1 to change the clock interrupt from A7 to D10, so you can use the board’s third hardware interrupt pin to wake it up instead of using the PcInt pin change library. Then you can remove all reference to the PCInt library from your sketch, change the wakeup pin from A7 to 10, and then use the regular SoftwareSerial library, and putting your sensors back on D6-7. Another user brought this issue up recently: http://envirodiy.org/topic/low-power-project/

[Shannon Hicks]

First you have to download the Arduino library for the SSD1306 by following the link on the Amazon listing to the manufacturer’s site which will then let you get to their own product listing: http://store.switchdoc.com/grove-128×64-i2c-oled-board-for-arduino-and-raspberry-pi/
On that page there’s a link to their library on Github:
https://github.com/switchdoclabs/SDL_Arduino_SSD1306
Install that library and run the example sketch that comes with it. Simply connect the OLED display to the I2C port of the Mayfly and the demo text and graphics will be displayed on the screen.

[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.

[Author]

Posts