Splitting Uno serial to pass data from XBEE to PC

I have foolishly bought 2 arduino unos for my research project without first realising that they only have 1 serial port each, which XBEE wireless modules can't share with the PC. I need one Uno to receive a radio signal from the XBEE module (the content of the signal is irrelevant), perform a calculation, then forward it onto the PC so I can see the number appear on a terminal monitor.

Can I get a quick solution to this situation by changing the pins on the XBEE shield so the receiver points at the XBEE and the transmit at the PC?

If I can't, how easy would it be to make my own serial port by feeding data down one of the GPOI pins and feed that into a 5v-serial converter, which goes to a serial-USB converter?

More info on the project: Eventually what I need is one module to emit an ultrasound pulse and a radio pulse at the same time. The other module starts a timer upon receiving the radio pulse, then stops it upon receiving the ultrasound pulse. I then need the second, receiving module forwards the time figure to to PC, where it can be logged and stored. If a second radio pulse is received before an ultrasound signal is received, the receiving modules tells the PC "0". The transmitter spaces pulses far enough apart that an ultrasound pulse would have to travel 100m to arrive after a second radio pulse, which should be far enough to make sure the signal dies given so far I can only get the ultrasound signal to last 3.5m. The ultrasound side of the modules are a circuit I've made myself. Most of this isn't up for alteration; I've been given a design for a positioning system by my supervisor and a tast to test the range of the ultrasound. It's the implementation and experiment I'm concerned with here.

Start by telling us which "XBee shield" - provide a link!

Mark

PS the arduinos do not/cannot receive radio from the XBee or anything else!

M

I think it's the same gear this guy uses.

http://www.jeremyblum.com/2011/02/27/arduino-tutorial-9-wireless-communication/

I'll have to check the exact model tomorrow.

Edit: Modestly confident this is what I was given.

http://uk.farnell.com/arduino/a000021/zigbee-mod-xbee-with-out-rf-mod/dp/1848697

Oh I may as well throw these up too.

Arduino Uno - A000066

http://uk.farnell.com/arduino/a000066/eval-atmega328p-8bit-uno-rv3/dp/2075382

XBee RF module - XB24-AWI-001

http://uk.farnell.com/digi-international/xb24-awi-001/rf-module-txrx-xbee-wire-ant/dp/1337912

Couple of thoughts ...

It should be possible to use the Rx pin to listen to one device and the Tx pin to transmit to the other device as long as both devices operate at the same baud rate.

You can use the SoftwareSerial library to add an extra serial port to the Uno.

...R

For future reference, there was no problem. A copy of everything to/from the XBEE is sent to the serial monitor anyway, so I could program as though sending to the XBEE also sent to the PC and had the transmitter ignore the reciever's messages.

Now I have another problem (probably shouldn't start a new topic for this).

How do I access interrupts on the arduino UNO? I'm receiving 40kHz pulses that last 4us each. Can interrupts trigger off this? If not then I'll have to put an integrator in the circuit to lengthen the pulses.

Less important, I'd like to replace the polling code with a proper hardware timer. The docs are a little fuzzy on how to set this up.

  int i = 0;
  while (digitalRead(ultrasound) == HIGH) {
     i++;
     if (i == 0) {
       break;
     }
  }

Interrupts should easily detect 4uSec pulses and that's probably the only way to detect such short pulses. Go slowly. Interrupt code is very difficult to debug. Keep the interrupt service routine (ISR) as short as possible - 2 or 3 lines of code if at all possible.

Why do you want to replace polling "with a proper hardware timer". That sounds like polling isn't respectable. Polling is a perfectly good way to collect data. Why make things difficult for yourself.

It would be very helpful to your cause if you give us a description of your project, including the hardware you are using.

...R

Wait loop/polling vs harware timer ss a good habbit thing for me. It’s how I did similar things when I used HCS08 chips.

I appriciate the difficulty that comes with interrupts and how to mitigate their problems. They do seems to be my best option here.

I already gave a project description in the OP. It’s a local positioning system that uses syncronised radio and ultrasound pulses. If it helps, I can paste the code that I had working this afternoon. It mostly worked, but the reciever wasn’t fast enough to pick up 4us bursts from it’s ultrasonic reciever circuit.

==========Rx==================

const int ultrasound = 12;

void setup() {
  Serial.begin(9600);
  pinMode(ultrasound, INPUT);
}

void loop() {
  while (Serial.available() == 0);
  char temp = Serial.read();
  Serial.write(temp);
  int i = 0;
  while (digitalRead(ultrasound) == HIGH) {
     i++;
     if (i == 0) {
       break;
     }
  }
  Serial.print(i);
  Serial.print('\n');
}

============Tx================

const int ultrasound = 13;

void setup() {
  Serial.begin(9600);
  pinMode(ultrasound, OUTPUT);
}

void loop() {
  for (char i = 'A'; i < 'D'; i++) {
    digitalWrite(ultrasound, LOW);
    delay(200);
    Serial.print(i);
    digitalWrite(ultrasound, HIGH);
    delay(50);
  }
}

How do you receive the radio pulse that starts the timer?

Writing a short ISR to stop the timer or to save its current value should be simple and shouldn't have any impact on the rest of the code.

How much time to you expect between the radio pulse and ultrasound pulse (to save me getting out my calculator)?

...R

All the radio is done with the XBEE modules. I send a character to serial-out on one arduino and raise pin 13. When the other finds that character in it’s serial-in, I start a timer on that arduino and stop it when it’s pin 12 falls. With the speed of sound being around 300-400 m/s, that’s a delay between the 2 of about 3.3 ms/m to 2.5 ms/m. I need to test the quality of this measurement (accuracy, reliability, resolution, linearity, etc) and it’s maximum operating range, and test how these change under a few conditions like different temperature room, heat gun between the 2, etc.

If the interval between the radio and sound signals is about 2000 microsecs (usecs) I would be inclined to try polling with a fast loop - assuming nothing else needs to be done while waiting for the sound signal. If you use PINx (direct port manipulation) it will be much faster than digitalRead().

I think this will read pin12 which is bit 4 of Port B - if not it is very close. And I may have the logic inverted.

// when radio signal is received
unsigned long endMicros = 0;
unsigned long startMicros = micros();
waitForSound();

// other stuff

void waitForSound() {
   byte inVal = 0;
   while (inVal == 0) {
       inVal = PINB & 0b00010000;
   }
   endMicros = micros();
}

That loop should only involve a few machine instructions and (I think) take 1 or 2 usecs which should give accuracy better than 0.5%

...R

Xbee radio is not raw rf pulses. There should be considerable delay from sending text into serial port to rf encoded pulses put in the air way, then receiving rf pulses and decoding the rf message to spitting it out serial port that makes your timing completely off. Have one xbee point destination to itself and find out the delay yourself.