Hello!
Is it possible to connect a GPS (LS20032) which runs at 57600, and some other sensors such as temperature which run at 9600, to a SINGLE arduino uno? I will also be retrieving this data from the gps and sensors, and sending it to my laptop through a single port.
Thanks in advance!
Search for "NewSoftSerial".
You can't have a different baud rate for transmit and receive on the hardware. However a mega gives you more serial ports.
You can't have a different baud rate for transmit and receive on the hardware.
Not at the same time, but it is possible to switch serial speed during runtime as the sample sketch below shows. (usefullness is another point)
That said, I must also say it is definitely not recommended.
void setup() {}
void loop()
{
Serial.begin(115200);
Serial.println("hello");
delay(1000);
Serial.begin(9600);
Serial.println("goodbye");
delay(1000);
}
Making multispeed over one serial line foolproof is not allways possible. A scheme that could work is implementing a CTS (Clear to Send) hardware handshake for the device to be read. The Arduino is then able to set the right baudrate and allows the device to send its bytes until the CTS flag is disabled again. This way it is even possible to have multiple sending serial devices on one serial port. But be aware for every device you need an additional CTS line @ the arduino, and more important, the device should support a CTS handshake. But if we need an extra line to create a solution we better use it for NewSoftSerial (NSS) as proposed earlier, because that would create - one port = one device = one speed , which is much easier to understand in terms of design and code.
Multispeed for TX line is even more difficult and depends on the receiving devices to ignore received data at wrong speed completely.
In short multiplexing/multispeed is far from trivial and as said earlier not recommended.
Note that NSS allows you to define the TX pin or the RX pin as -1, so you can create a Serial-IN or Serial-OUT only.
For my application multispeed does look like a nice way to go about it. As for the not recommended part, does it cause any damage to the arduino and/or sensors/gps?
I am probably looking at sending and receiving data about once every 2 sec, for no more than 10min.
As for the not recommended part, does it cause any damage to the arduino and/or sensors/gps?
No, the problem is "How do you detect the bit rate if it's changing from one transmission to another?"
The only real way is to do some low-level timing of the bits over several bytes or a known sync byte at the start of every transmission. Not rocket science but I think you'd want a good reason to do it.
Rob
if the device is the receiving part and it gets pulses at a baudrate it doesn't understand it might interpret them still as a command, causing the device to behave unpredictable.
e.g. a device expecting a byte at 9600 baud that receives one byte at 4800 can see this bitstream as 2 bytes due to the factor 2 in timing. To see this effect write a small sketch that prints the alphabet at 9600 baud in loop() and put your IDE com monitor in the wrong baudrate.
I do not expect multispeed will harm devices, never heard such horror story, but that is no guarantee of course. I can imagine that if you put too many devices in parallel on the serial bus the voltage become unreliable, and parallel pull ups may draw too much current . Have some experience with a serial LCD attached to the hardware serial and while uploading the LCD got inversed. Had to switch off/wait/on to restore normal working.
Most important point is that the Arduino is in control, set baudrate A for device A, requests output, receives output, set baudrate B for device B, requests output, receives output etc.
Note that devices sending output automatically (or worse continuously!!) will give a 99.9% (or more) chance of interference. So this kind of multiplexing will only work for devices sending information upon request.
Nevertheless, very interested in your experiences, let us know.
I am still working on the project and have a few other issues before trying this out..
Will update on results as soon as possible.
Ok I got some result. The gps and pressure sensor are both working, however the data is mixed between the two:
188.93,990.75
$188.93,990.75
G189.43,990.69
P189.43,990.69
G188.67,990.78
G190.11,990.61
A189.86,990.64
,190.11,990.61
1188.93,990.75
9189.18,990.72
0189.43,990.69
5188.93,990.75
The first entry on each line is from gps, followed by altitude and pressure from the sensor (see the attachment).
I think playing around with the code should fix this, but not sure how to go about it. I tried delaying, rearranging, creating new functions, etc.. but nothing has solved the problem. Here is part of the code:
void setup()
{
Wire.begin();
bmp085Calibration();
}
void loop()
{
Serial.begin(57600);
{
if (Serial.available()) {
Serial.print(Serial.read(), BYTE);
}
}
{
temperature = bmp085GetTemperature(bmp085ReadUT());
pressure = bmp085GetPressure(bmp085ReadUP());
temperature = temperature *0.1;
pressure = pressure / 100;
altitude = ((1-pow(pressure/1013.25,0.190284))*145366.45)*0.3048;
Serial.print(altitude);
Serial.print(",");
Serial.print(pressure);
Serial.println();
delay(100);
}
}
Also is there any problem if the sensor communicates at 57600? Instead of alternating bauds, I thought of sticking to one speed.
It looks like you have a more or less valid GPS sentence, it's just spread over 20 lines 
But where are the dual baud rates? Is this still the deal? What's is "bmp085"?
Can you post all the code?
Rob
if (Serial.available()) {
Serial.print(Serial.read(), BYTE);
}
The above code of yours says I am going to repeat everything received on RX back onto transmit TX of the Serial and USB port. "It would be like a little kid repeating everything you said".
Are you trying to run everything though 1 serial port? Such as terminal 0 and 1? You need to communicate with GPS using NewSoftwareSerial on terminal 2 and 3 and then retransmit that info. onto Serial 0 an 1.
I hope I described the issue well enough,
Mark
Graynomad:
It looks like you have a more or less valid GPS sentence, it's just spread over 20 linesBut where are the dual baud rates? Is this still the deal? What's is "bmp085"?
Can you post all the code?
Rob
bmp085 is my pressure sensor, the rest of the code is irrelevant since it calibrates that sensor. The problem I am having is what I described earlier, maybe I'll get an mega to solve the problem. The uno is becoming limited as my project grows.
cyclegadget:
if (Serial.available()) {
Serial.print(Serial.read(), BYTE);
}
The above code of yours says I am going to repeat everything received on RX back onto transmit TX of the Serial and USB port. "It would be like a little kid repeating everything you said". Are you trying to run everything though 1 serial port? Such as terminal 0 and 1? You need to communicate with GPS using NewSoftwareSerial on terminal 2 and 3 and then retransmit that info. onto Serial 0 an 1. I hope I described the issue well enough, Mark
I used that code just for fast result. I would like to run everything on a single port, the sensors don't seem to mind communicating at 57600, while the gps strictly needs to communicate at that speed. If I can only separate the gps data from the sensor data... The problem is that the gps data is being read in bytes and not as a whole chunk (while the sensor data is read as a chunk). So I keep having a single gps byte followed by a chunk of sensor data, and the whole process repeating.
I believe I tried new soft serial without much success, I shall give that another try, but the way things are going I might as well get the arduino mega and save myself the time and effort.
I get it, you have two devices transmitting to the Arduino on the same line. However one (the sensor) transmits a lot more frequently than the other (the GPS).
If that data stream you posted is repeatable all you have to do is split the two, the first character of each "packet" is a GPS char, split that into an array then deal with the rest. When your GPS array has a full sentence handle that as well. This should be fairly simple to do however at some point the two devices will clash (transmit at the same time) and you will get garbage and that has to be dealt with.
However it would be a lot easier to just use two inputs, NSS should solve the problem.
Rob