Data syncing

Hey guys,

I would appreciate some input on the particulars of this idea.

Here is what I'm trying to accomplish:

I have two dataloggers that I would like to send a periodic, synchronized 5v or 3.3v signal to. The dataloggers will be physically isolated but not more than 20ft apart. I would also like to send a separate, single pulse signal to both units that would be triggered by a handheld remote. The remote must also be at least 300ft away from both loggers.

I'm pretty sure I will need to put the xbee's in API mode since there will be three, although i'm not sure yet what this means. One thing that is important is that the signal going to the two loggers be almost perfectly synchronized. So im thinking that the arduinos at the dataloggers should transmit and receive between each other for the periodic signal and they both should receive from the handheld unit for the intermittent pulse. A few milliseconds lag time between units is ok.

Here is what I have in mind:

I was planning on buying 3 Uno's (to allow for future expansion), 3 xbee pro XSC's (for maximum range), and three xbee shields, project boxes, buttons, power supplies etc.

Let me know if you see any major flaws in this idea or improvements without making it too complicated.

Also, could you direct me to a project that has some simple commands like this sent wirelessly?

Thanks,
tony

I'm pretty sure I will need to put the xbee's in API mode since there will be three

That would depend on whether you need one way communication or two way, and how responsive the communication needs to be.

In AT mode, the sender could broadcast a message that all units would receive at (nearly) the same time. The actual sending of the message might be delayed, until it was clear that no messages are being sent.

So im thinking that the arduinos at the dataloggers should transmit and receive between each other for the periodic signal and they both should receive from the handheld unit for the intermittent pulse.

Why do the loggers need to talk to each other? If they are going to, what is the third unit bringing to the party? One logger could simply send the signal when it is time for both loggers to do something. Whatever that something is.

3 xbee pro XSC's (for maximum range),

Up to 15 mile units to transmit 300 feet? OK.

Let me know if you see any major flaws in this idea or improvements without making it too complicated.

You haven't said what the idea is, other than to send "signals" from something you don't have yet to something else you don't have yet.

Also, could you direct me to a project that has some simple commands like this sent wirelessly?

"Simple commands" and a single pulse are two different things. While you are buying stuff, though, Rob Faludi's book "Building Wireless Sensor Networks" would be a good investment.

Why do the loggers need to talk to each other? If they are going to, what is the third unit bringing to the party? One logger could simply send the signal when it is time for both loggers to do something. Whatever that something is.

Right, the 3rd unit does not need to transmit. The handheld needs to transmit only, the first logger needs to transmit and receive and the second logger needs to receive only. I'd like it this way because i want the periodic signal to continue even if the handheld is out of range. If I can do this in AT that's fine.

Up to 15 mile units to transmit 300 feet? OK.

Yes, 15 miles LOS, which is almost never the case. The one logger will be housed in a metal box and I don't need the higher data rate of the 2.4GHz modules so why wouldnt I order the one with the best range?

You haven't said what the idea is, other than to send "signals" from something you don't have yet to something else you don't have yet.

I'm not sure exactly what more information youre looking for. I stated my goals, the equipment I plan to use to accomplish those goals. Do I need to have the equipment in my hand before I seek "PROJECT GUIDANCE"?

Anyway, I do appreciate the input, and I will try to get the book on the ipad.

When you say "nearly the same time" how close do you need the arrival time to be? I ask as I was trying to set up a similar setup using XBee's and the synching was not good enough, it was off by +/- 1-5 ms and I needed about .1 ms resolution. The timing difference adds up from things like the serial interface lag on both sides among other things.

I am now redesigning the system with GPS modules at each units that output a pulse per second that each GPS will receive at very close to the same time, I think the differences are on the order of nanoseconds. The PPS will trigger an interrupt and the MCU will reset the system timer and record a time stamp, then when an event happens the remote units will send back the number of timer counts and the last time stamp.

Not all GPS modules output a PPS so if yo are going this route make sure the GPS modules you buy do output a PPS.

wade

My constraints are not that critical, 200ms delay is fine. I will be logging about 60 analog signals along with these sync signals from the arduinos. I will use the arduino signal to visually align all of the data from the two dataloggers once it has been graphed.

so why wouldnt I order the one with the best range?

Higher power consumption is the tradeoff. As long as you aren't running of a battery, there is no problem.

Right, the 3rd unit does not need to transmit. The handheld needs to transmit only, the first logger needs to transmit and receive and the second logger needs to receive only.

So, Series 2 (mesh models) seem more appropriate than point to point (Series 1) models.

Make the 1st logger a coordinator, and the other one an end device or router. The handheld unit will be an end device or router, too.

Do I need to have the equipment in my hand before I seek "PROJECT GUIDANCE"?

No, but to answer the question you posed, we need a bit more information. The XBees appear to be only a small part of the whole picture.

For instance, what is it the handheld device is going to cause to happen? All we know is that it is supposed to "send a signal" to some loggers. What that signal is supposed to cause to happen is a mystery. Why the Arduinos wouldn't do whatever logging was needed, all the time, is not clear.

I will be logging about 60 analog signals along with these sync signals from the arduinos.

Might I inquire how you will use an Arduino with 6 analog pins to read 60 analog signals?

I will use the arduino signal to visually align all of the data from the two dataloggers once it has been graphed.

Why not just timestamp the data as it is logged, and use that to perform the alignment?

I'm just asking questions, since you are now revealing more about the overall project.

When I press a button on the handheld unit I want it to wirelessly communicate a signal to the other two units at the loggers. This signal will cause the two units at the loggers to send a 5v pulse to the dataloggers. The dataloggers, not the arduinos, will be recording the 60 channels of data, including the sync pulses from the arduinos.

Hey guys, I am just waiting for the xbee sheilds, should be here thursday. I have the code ready for all three arduinos, I was hoping someone could take a quick look. I'm not too sure about serial communication parts.

Can you take a look at this code and see if I'm on the right track for making these three units communicate with each other? Thanks.

Here is what I have for the handheld unit:

/*
Pin 2 is connected to switch terminal and one end of resistor
other end of resistor is connected to ground
other switch terminal is connected to 5v 
Pin 12 is for transmit indicator LED
*/

const int buttonPin = 2;     // the number of the pushbutton pin
const int ledPin =  12;      // the number of the LED pin

// variables will change:
int buttonState = 0;         // variable for reading the pushbutton status
int tim = 0;

void setup() {			//Arduino initial setup

  // initialize the LED pin as an output:
  pinMode(ledPin, OUTPUT);      
  // initialize the pushbutton pin as an input:
  pinMode(buttonPin, INPUT);    
  
  Serial.begin(9600);		//set baud rate on Arduino to 9600

}

void loop() {			//loop program

  // read the state of the pushbutton value:
  buttonState = digitalRead(buttonPin);

  // check if the pushbutton is pressed.
  // if it is, the buttonState is HIGH:L
  if (buttonState == HIGH) {     
    // turn LED on:    
    digitalWrite(ledPin, HIGH);  
    Serial.print("H");		//Send the character H
    tim = 1;
  } 
  else if (tim == 1) { 
    // turn LED off:
    digitalWrite(ledPin, LOW); 
    Serial.print("L");		//Send the character H
    tim = 0;
   }
}

Here is what I have for the first receiving unit:

// set pin numbers:
const int LEDBlink =  13;      // the number of the LED pin

// Variables will change:
int ledState = LOW;             // ledState used to set the LED
long previousMillis = 0;        // will store last time LED was updated

// the follow variables is a long because the time, measured in miliseconds,
// will quickly become a bigger number than can be stored in an int.
long interval = 2000;           // interval at which to blink (milliseconds)
long interval2 = 100;           // interval at which to blink (milliseconds)

int LEDButton = 11; 			// Assign Pin 11 for Button LED
void setup() {				//Arduino initial setup  

  Serial.begin(9600);			//Set baud rate for Arduino to 9600
 
 pinMode(LEDBlink, OUTPUT);     // set the digital pin as output:
 pinMode(LEDButton, OUTPUT);	// Make Digital  Pin 11 as Output Pin

}

void loop() {			// loop program
  if (Serial.available()) {	//If there is data in the Serial Line
    int dataByte = Serial.read(); //save data into integer variable dataByte
    Serial.print(dataByte, BYTE); //Print to screen the variable received
          if(dataByte == 'H'){		//if the variable is the character H
             digitalWrite(LEDButton, HIGH);	//then Button LED pin is ON
            }
            else if(dataByte == 'L') {	// if the variable is the character L
              digitalWrite(LEDButton, LOW);	// then Button LED pin is off        
    }
  }
  unsigned long currentMillis = millis();
 
  if(currentMillis - previousMillis > interval) {
    // save the last time you blinked the LED 
    previousMillis = currentMillis;   

    // if the LED is off turn it on and vice-versa:
    if (ledState == LOW){
      ledState = HIGH;
      Serial.print("N");  //sends N to other arduino    
    }   
    else {
      ledState = LOW;
      Serial.print("F");  //sends F to other arduino
    }
    // set the LED with the ledState of the variable:
    digitalWrite(LEDBlink, ledState);
    
  }
    else if(currentMillis - previousMillis > interval2) {
    // save the last time you blinked the LED 
    if (ledState == HIGH){
      ledState = LOW;
      Serial.print("F");  //sends F to other arduino
    digitalWrite(LEDBlink, ledState);
    previousMillis = currentMillis;  }       
    }
}

Here is what I have for the second receiving unit:

int LEDBlink = 11; 			// Assign Pin 11 for Sync LED
int LEDButton = 9;			// Assign Pin 9 for Button LED

void setup() {				//Arduino initial setup  

  Serial.begin(9600);			//Set baud rate for Arduino to 9600
 
 pinMode(LEDBlink, OUTPUT);     // set the digital pin as output:
 pinMode(LEDButton, OUTPUT);     // set the digital pin as output:
}

void loop() {			// loop program
  if (Serial.available()) {	//If there is data in the Serial Line
    int dataByte = Serial.read(); //save data into integer variable dataByte
    Serial.print(dataByte, BYTE); //Print to screen the variable received

          if(dataByte == 'N'){		//if the variable is the character N
             digitalWrite(LEDBlink, HIGH);	//then Sync LED pin is ON
            }

            else if(dataByte == 'F') {	// if the variable is the character F
              digitalWrite(LEDBlink, LOW);	// then Sync LED pin is off   
            }

          if(dataByte == 'H'){		//if the variable is the character H
             digitalWrite(LEDButton, HIGH);	//then Button LED pin is ON
            }

            else if(dataByte == 'L') {	// if the variable is the character L
              digitalWrite(LEDButton, LOW);	// then Button LED pin is off        
            }
  }
}

Ok, all the hardware is here and the code is installed but i'm having issues. The LED's are very erratic and i'm not sure why.

I will summarize what I'm trying to accomplish and how I tried to do that.

Basically I want to press a button on the first arduino and have arduinos 2 & 3 wirelessly receive that and have each one power an LED when the button is depressed.
I also want arduinos 2 & 3 to each power a separate LED that should flash at some periodic rate. .1 second on, 1 second off, or whatever time settings I choose.

So here's how I tried to do it:

The first arduino/xbee simply sends out an "H" or "L" and powers an LED depending on the position of the switch on pin 2.

The second arduino/xbee receives the "H" or "L" and powers another LED accordingly. It also uses a modified version of the "Blink without delay" example to run the periodic flashing. I have attached a Serial.print ("N") or "F" to the state of the periodic LED.

The third arduino/xbee receives either the "N" or "F" or "H" or "L" and powers LED's accordingly.

I know this is simple but I can't seem to get it to work.

Any help would be greatly appreciated.

I know this is simple but I can't seem to get it to work.

Do you know if you are having hardware or software issues?

How is the switch wired to the handheld unit?

How are the XBees configured?

You've described what you want to have happen, but not what really does happen. It's hard to guess where the problem is, knowing only half the story.

I would start by doing some simple link-time tests, send a character to a unit
and have it respond back, and measure the loop time. The deal with XBees [at
least the 2.4 Ghz units] is that they use packet transmissions, and they send those
packets embedded in the zigbee protocol wrapper. They also do some band checking,
with fallback, before doing a transmission. You need to know how long that all takes.

Secondly, it doesn't sound like you need Faludi's book, but you should realize the
schematics are all wrong. He is interfacing a 3.3V device [XBee] directly to a 5V
Arduino, although he does mention using 3.3V power to the XBee.

Another problem is that you probably need to configure all 3 XBee nodes to broadcast
mode, as opposed to one address to another, which only allows 2 nodes. The remote
broadcasts the sync to both other nodes, and then the 2nd node can broadcast
to the 3rd node.

I would set up an address in "software" for each device, so they can filter messages
meant for them individually. Any way you go, you will have a problem that #2 may be
transmitting to #3 when the sync signal comes in. Personally, I would use handshakes
[Ack response by receiver] on all transmissions.

Also, for 300' range, you're probably best going to the 900-Mhz units, as the 2.4Ghz
XBee-Pro reliable range is only around 300 feet for general use.

PPS output from a GPS is cool! Works well and easily for measuring times. You can almost measure the speed of light since it is accurate to within nanoseconds. It's cheap. With a few GPS units you can send the data slow, later, instead.

Do you know if you are having hardware or software issues?

How is the switch wired to the handheld unit?

How are the XBees configured?

Software. The first problem is there is a delay when I close the switch on the handheld unit. When I close the switch the corresponding LED's on the other 2 arduinos light up as much as a second later. The next problem is with the periodic signal. The third arduino will flash the periodic LED pretty rapidly (maybe 30Hz or so) but this flashing starts and stops somewhat in time with the 1 second interval prescribed in the "blink without delay" code.

The switch is a normally open single pole momentary switch. I have pin 2 connected to a 10k resistor which is connected to ground. The switch has 5v+ to one side, the other side also goes to pin 2.

I bought the xbee pro 900 XSC for the extended range. When I read the modem using the X-CTU software, it indicates that it is the XBP09-XSC and the function set is the xbee-pro xsc 9600. I see no other function set available that would allow me to designate whether it is a router or coordinator.

I'll make sure my xbee shield is providing the correct voltage to the xbee. I'll look into addressing the messages but i'm not sure how to do that yet.
Thanks for the GPS idea, but I'm already invested in this direction. If I cant get it to work I may try it.

The Xbee shield "should" be designed correctly. It's only Faludi's book that's screwed up.
How on earth can someone make such a basic error in a published book?

In regards the delay, check the default parameter settings in the Xbee. It may be waiting
for a complete packet in the queue [eg, 100 bytes] before transmitting, etc.

The Xbee shield "should" be designed correctly. It's only Faludi's book that's screwed up.

Please explain what you think the book says, and why you think it is screwed up.

How on earth can someone make such a basic error in a published book?

People make mistakes. It happens.

It's even possible, however unlikely, that you are the one that made the mistake.

In regards the delay, check the default parameter settings in the Xbee. It may be waiting
for a complete packet in the queue [eg, 100 bytes] before transmitting, etc.

Also, know that broadcast mode (specific send to address) is orders of magnitude slower than direct transmission.

You haven't defined how the XBees are configured, but, it sounds like you are sending messages in broadcast mode. That is going to be slow, because the XBees need to coordinate a quiet time for the broadcast to occur. Sending a direct message twice, to the tow different receivers is going to be orders of magnitude faster.

Just a caution for those looking at using the PPS to sync remote data things, not all GPS modules or GPS shields provide PPS output so look at the docs carefully. I am using Maestro GPS 1035 and 2035 modules about $20 and $18 from Mouser they work great and the price can't be beat. The 1035 and 2035 are surface mount units and need to either go on a breakout board of a shield to use them with Arduinos, they skillet reflow very nicely but you will need to fab a board first.

wade

It's even possible, however unlikely, that you are the one that made the mistake.

See post #10 in this thread.

The Rx and TX pins on the XBee are 5V tolerant. Powering the XBee from 3.3V, and connecting it to 5V TX is fine.

Connecting 5V to other pins on the XBee is not, because only the RX and TX pins are 5V tolerant.

OK, I'll bite. Show me on the documentation where it says 5V tolerant.

http://ftp1.digi.com/support/documentation/90000982_H.pdf

The Rx and TX pins on the XBee are 5V tolerant. Powering the XBee from 3.3V, and connecting it to 5V TX is fine.

Connecting 5V to other pins on the XBee is not, because only the RX and TX pins are 5V tolerant.

OK, I'll bite. Show me on the documentation where it says 5V tolerant.

http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-series1-module#docs

http://ftp1.digi.com/support/documentation/90000982_H.pdf

Since you didn't answer the question, I will. The datasheets for series 1 and 2 XBee say nothing about
Din pins being 5V tolerant. These are the modules Faludi talks about in his book. Not only that, but the
very first schematic in Faludi's book, fig 1-10, is wrong. He has Rx and Tx wired backwards.

On some of the "newer" XBee modules, the Din pin is 5V tolerant. So we have a pretty poor situation
here, some are and some are not 5V tolerant. You have to be very careful what you're doing, how you're
hooking them up, and how you're mixing and matching.