Using both analog and digital UART pins with RF transmitter and Xbee on arduino

I'm mostly a beginner to using microcontrollers, so I'm not sure if this might work.

I am using an arduino uno to send two different streams of data wirelessly via UART using an Xbee. One set of data is a void loop of just sending text, and the other is gps data. I also have an RF transmitter/receiver module to work with. My trouble is sending data that seems to need multiplexing in order to function from what I gather, however, I am limited in time and what components to use. My thought was to use both analog and digital functions of the arduino to perform both tasks separately, but don't know how to go about that. Any thoughts or guidance to the right direction would be appreciated.

Thanks

slicknessessity: My thought was to use both analog and digital functions of the arduino to perform both tasks separately

I am not sure what this means.

Please explain further.

The arduino uno has digital pins and analog pins. My initial thought was to use both the digital pins and analog, but keeping everything in digital just makes more sense (didn't occur to me until later).

I guess I'm trying to find a loop hole around multiplexing without the need of some chip to do it. If all else, would I need to use my RF transmitter/receiver in junction with my xbee in order to send separate UART data wirelessly?

The XBee library and the RadioHead library have specific pins that they use.

The digitals pins D14-D19 are also also analog pins A0 to A5. Xbee can be used with software serial so that the hardware serial can be preserved for debugging via serial monitor.

Which other RF module are you referring to? nfr24l01? SPI is used to talk to that. Something else? 433 MHz modules can be used also, default is D11/D12 for those.

I do have a 433 MHz modules to use along with my 2 xbees talking to each other.

If I do the multiplexing option, is it possible to make it work without some chip to do it? I'm only sending 2 different streams of data to one xbee.

Well, you have Serial to talk to the PC, you newsoft serial to talk to the xbee, you have radiohead/virtual wire to talk over the 433 MHz module, and you have SPI to talk to the nrf24l01 module. No external muxing needed.

I wonder if you realy mean "multiplexing" which is sending two or more signals over the same link and separating them after they are received.

Or do you mean doing two (or more) tasks at the same time - for example gathering GPS data and sending data via XBee.

If you really mean multiple tasks have a look at the demo Several Things at a Time

...R

Robin2:
I wonder if you realy mean “multiplexing” which is sending two or more signals over the same link and separating them after they are received.

Or do you mean doing two (or more) tasks at the same time - for example gathering GPS data and sending data via XBee.

If you really mean multiple tasks have a look at the demo Several Things at a Time

…R

It is the prior to what you said, multiplexing to send 2 signals over the same xbee. I want to send gps data and a simple message over a UART xbee. Having multiple different broadcasting modules on one board looks messy to me, so I’m highly considering to go the multiplexing route in stead of using both xbee and a 433MHz module, but what worries me is the code to make it happen. I’m not sure what to get either since it’s my first time doing something like this.

Thanks

slicknessessity: It is the prior to what you said, multiplexing to send 2 signals over the same xbee. I want to send gps data and a simple message over a UART xbee.

That is a useful clarification.

But I don't understand the problem. Can't you adopt one of two strategies {A} Send each type of message in turn - a GPS message this time, another message next time, then another GPS message etc etc

{B} Send a composite message - the equivalent of

Serial.print("G ");  // G indicates a GPS message
Serial.print(gpsMessage);
Serial.print(" O "); // O indicates other type of message
Serial.println(otherMessage);

...R

Robin2: That is a useful clarification.

But I don't understand the problem. Can't you adopt one of two strategies {A} Send each type of message in turn - a GPS message this time, another message next time, then another GPS message etc etc

{B} Send a composite message - the equivalent of

Serial.print("G ");  // G indicates a GPS message
Serial.print(gpsMessage);
Serial.print(" O "); // O indicates other type of message
Serial.println(otherMessage);

...R

The gps module I have is a GP-20U7. The RX pin is covered over with rosin. My feeling is that it was purposely done so for a reason. It would make sense since it's just a module made to send coordinates. I don't know how different it is to program it so I'd rather not tamper with it unless it's fairly simple to do.

Sorry in advanced if I might be misunderstanding something. I've never done method "B" before. Is that a way to capture gps data along with making another message, and dictate when to send them on the arduino itself?

slicknessessity: The gps module I have is a GP-20U7. The RX pin is covered over with rosin.

You are unlikely to be trying to write to the GPS so why would you need access to its Rx pin. I don't understand what may be in your mind?

Sorry in advanced if I might be misunderstanding something. I've never done method "B" before. Is that a way to capture gps data along with making another message, and dictate when to send them on the arduino itself?

I had assumed you have already captured the GPS data and I was illustrating how it might be sent onwards to something else. Same goes for method "A".

Perhaps it is I who have misunderstood.

...R

Robin2: I had assumed you have already captured the GPS data and I was illustrating how it might be sent onwards to something else. Same goes for method "A".

Perhaps it is I who have misunderstood.

...R

The idea behind it is that the gps will be moving consistently, so consistent coordinates is what I'm looking for.

Robin2: You are unlikely to be trying to write to the GPS so why would you need access to its Rx pin. I don't understand what may be in your mind?

The idea is to send a continuous stream of gps data and sending a continuous message (like an SOS). The gps I have does just that over UART. It does so every second via hex code to which I need to translate to coordinates (which is another thing I'm looking in on how to do). Maybe by adjusting the interval of when the gps sends in the data, I can tell the arduino to send in text every other interval perhaps? I just worry that if ever the timing is off somewhere in between, the signals would clash. Maybe there's an easier way to have constant gps positioning data and a looped message work over one xbee?

slicknessessity:
The idea is to send a continuous stream of gps data and sending a continuous message (like an SOS).

I am struggling to interpret what you are saying.

There is no such thing as a continuous stream of GPS data. There can only be a series of positions sent at intervals. The intervals may be small, but they will be there. Unless you are in jet airplane the gps position is not going to change much from one second to the next - probably not even within 10 seconds.

It seems to me it should be sufficient for your Arduino program to take a GPS reading once per second and send that onwards to wherever you want to send it. Indeed if it was my project I would be asking myself why it is necessary to update the position more often than twice per minute.

Perhaps you can describe in plain language the series of steps that you want your program to take - without any reference to how it might be coded. The sort of thing I think you are trying to achieve is

repeat forever at 1 second intervals
    read GPS position
    send GPS position
    send other message

…R

Robin2: I am struggling to interpret what you are saying.

There is no such thing as a continuous stream of GPS data. There can only be a series of positions sent at intervals. The intervals may be small, but they will be there.

I guess I should have worded it better. It is as you say, a series of positions at set intervals.

Robin2: Perhaps you can describe in plain language the series of steps that you want your program to take - without any reference to how it might be coded. The sort of thing I think you are trying to achieve is

repeat forever at 1 second intervals
    read GPS position
    send GPS position
    send other message

...R

What I'm looking for is as you say in the code. I'm pretty much the new kid on the block in regards to reading and sending data using an xbee and gps module, so I apologies for any confusion. My confusion is that I was told to use multiplexing in order for that to work. Any suggestions pointing at the right direction would be much appreciated.

Thanks

If my description is correct just forget about multiplexing. Sometimes the work is used very loosely and I suspect that was the case here.

Start by writing a short program to take data from your GPS and display it on the Serial Monitor. When you have that working (or if you can't get it to work) post your code here and we can take it from there.

...R

I found an old gps library and tweaked it to work for my application, now it works like a dream. When I add code to send a message at a certain delayed interval, it doesn’t seem to like it:

 /*
 Example code for connecting a Parallax GPS module to the Arduino
 Igor Gonzalez Martin. 05-04-2007
 igor.gonzalez.martin@gmail.com
 English translation by djmatic 19-05-2007
 Listen for the $GPRMC string and extract the GPS location data from this.
 Display the result in the Arduino's serial monitor.
 */ 
 #include <string.h>
 #include <ctype.h>
 int ledPin = 13;                  // LED test pin
 int rxPin = 0;                    // RX PIN 
 int txPin = 1;                    // TX TX
 int byteGPS=-1;
 char linea[300] = "";
 char comandoGPR[7] = "$GPRMC";
 int cont=0;
 int bien=0;
 int conta=0;
 int indices[13];
 void setup() {
   pinMode(ledPin, OUTPUT);       // Initialize LED pin
   pinMode(rxPin, INPUT);
   pinMode(txPin, OUTPUT);
   Serial.begin(9600);
   for (int i=0;i<300;i++){       // Initialize a buffer for received data
     linea[i]=' ';
   }   
 }
 void loop() {
   serial.println("Hello world");
   delay(500);

   digitalWrite(ledPin, HIGH);
   byteGPS=Serial.read();         // Read a byte of the serial port
   if (byteGPS == -1) {           // See if the port is empty yet
     delay(100); 
   } else {
     // note: there is a potential buffer overflow here!
     linea[conta]=byteGPS;        // If there is serial port data, it is put in the buffer
     conta++;                      
     Serial.write(byteGPS); 
     if (byteGPS==13){            // If the received byte is = to 13, end of transmission
       // note: the actual end of transmission is <CR><LF> (i.e. 0x13 0x10)
       digitalWrite(ledPin, LOW); 
       cont=0;
       bien=0;
       // The following for loop starts at 1, because this code is clowny and the first byte is the <LF> (0x10) from the previous transmission.
       for (int i=1;i<7;i++){     // Verifies if the received command starts with $GPR
         if (linea[i]==comandoGPR[i-1]){
           bien++;
         }
       }
       if(bien==6){               // If yes, continue and process the data
         for (int i=0;i<300;i++){
           if (linea[i]==','){    // check for the position of the  "," separator
             // note: again, there is a potential buffer overflow here!
             indices[cont]=i;
             cont++;
           }
           if (linea[i]=='*'){    // ... and the "*"
             indices[12]=i;
             cont++;
           }
         }
         Serial.println("");      // ... and write to the serial port
         Serial.println("");
         Serial.println("---------------");
         for (int i=0;i<12;i++){
           switch(i){
             case 0 :Serial.print("Time in UTC (HhMmSs): ");break;
             case 1 :Serial.print("Status (A=OK,V=KO): ");break;
             case 2 :Serial.print("Latitude: ");break;
             case 3 :Serial.print("Direction (N/S): ");break;
             case 4 :Serial.print("Longitude: ");break;
             case 5 :Serial.print("Direction (E/W): ");break;
             case 6 :Serial.print("Velocity in knots: ");break;
             case 7 :Serial.print("Heading in degrees: ");break;
             case 8 :Serial.print("Date UTC (DdMmAa): ");break;
             case 9 :Serial.print("Magnetic degrees: ");break;
             case 10 :Serial.print("(E/W): ");break;
             case 11 :Serial.print("Mode: ");break;
             case 12 :Serial.print("Checksum: ");break;
           }
           for (int j=indices[i];j<(indices[i+1]-1);j++){
             Serial.print(linea[j+1]); 
           }
           Serial.println("");
         }
         Serial.println("---------------");
       }
       conta=0;                    // Reset the buffer
       for (int i=0;i<300;i++){    //  
         linea[i]=' ';             
       }                 
     }
   }
 }

I am trying to see if I can change the intervals of when the arduino sends data to get the timing for sending a message over TX. I’ve been trying to put in a delay to see it work, but doesn’t seem to work. I don’t know if I’m doing it write. I’d appreciate any help

I can’t make sense of the code in Reply #16. What is it supposed to be doing?

It looks as if it is both trying to read GPS messages using Serial and also using Serial to send messages to the Serial Monitor. If so that is a hopeless mess.

What Arduino are you using?

If you have a Mega use Serial1 for the GPS.
If you have an Uno use SoftwareSerial to create an extra seial port for the GPS.

In either case use the second example in Serial Input Basics to receive the data reliably without any need for delay() or buffer overflows.

…R

I've been searching for reliable libraries and stumbled on this one: http://playground.arduino.cc/Tutorials/GPS

I was looking for a method to clean up the raw data from the gps and transmit it to be readable.

I want to send gps data and a message to the xbee, so I thought stuffing it out the same tx port using serial would work, but I guess I didn't understand the concept behind the serial command. This code seems nice since it translates the gps data into something more readable whenever the $GPRMC string comes by. The code itself isn't as clean as many others and I feel it could be simplified, but I'm not skilled enough to edit something like that, so I made some small changes just to make it work.

I have an uno. So, would using SoftwareSerial for the gps be as simple as replacing it in the code and get rid of the buffer overflow? And by that, I can send messages using serial?

I'm confused.

Is the link in Reply #18 the source of the code in Reply #16 or is it something new that you have stumbled on?

Trying to use a Serial port for two sources is like playing the Stones and the Grand National commentary through the same loudspeaker at the same time.

Try using SoftwareSerial for the GPS and see what happens.

...R