Having purchased a cheap Ublox GPS, I wired it up to a TTL RS232<->USB convertor, downloaded U-Center from Ublox and observed incoming packets at (the power up default) of 9600 Baud. As I wanted to add this to an Arduino uno (Adafruit Metro actually) and keep the Arduino's sole hardware UART for the convenience of using the Arduino IDE and the USB monitor, it was important that the GPS baud rate was low enough to use the "SoftSerial" library to allow a software UART to read data reliably.
My USB-TTL-RS232 modules were 15 years old, but the data sheet is at RS Stock No.:429-278
Wiring 3 wires up and using tera-term saw data coming out at 9600 baud. Downloading U-Center from ublox ( at
https://www.u-blox.com/en/product/u-center allowed further experimentation, I did not update firmware or alter the GPS configuration, if it works, don't fix it...
Actually at a later date I may try and increase the update rate and a future application may want the 1pps output signal to be increased if possible. (for a GPS disciplined oscillator)
One feature of the U-center software is a deviation map, shown below, by the way it took many many minutes to get a cold start, but the U-Center software did show more and more satellites coming into view and their status changing from blue to green (I assume that's a good thing) I will test warm start tomorrow!
Anyway, the Arduino code I used was simply the Software Serial example with one print line commented out. Here it is, I wired the GPS TX pin to pin 10 on the Arduino and the RX pin to pin 11 (although it is not used here)
/*
Software serial multiple serial test
Receives from the hardware serial, sends to software serial.
Receives from software serial, sends to hardware serial.
The circuit:
* RX is digital pin 10 (connect to TX of other device)
* TX is digital pin 11 (connect to RX of other device)
*/
#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX
void setup() {
// Open serial communications and wait for port to open:
Serial.begin(9600);
while (!Serial) {;}
mySerial.begin(9600);
}//--end setup--//
void loop() { // run over and over
if (mySerial.available()) {
Serial.write(mySerial.read());
}
if (Serial.available()) {
mySerial.write(Serial.read());
}
}//--end loop--//
////////////////////////
Here is the output from the arduino IDE serial monitor
The code above just passed the GPS data to the USB serial port of the PC.
Running a terminal emulator such as TeraTerm will show the data if set to
correct BAUD rate.
The next arduino program only outputs lines that contain RMC data. It also
strips the first few characters and some characters at the end that carry
un-needed data. This makes it easier to use the RFM69 radio transceivers.
As these have a packet limit of 60 bytes.
////////////////////////////////////////////////////////////////
// File: GPS_Read_RMC_9600_SoftwareSerial.ino by Ian McCrum
// Version: 2.1
//
// Reads part of an RMC line from a GPS wired to pins 10 and 11
// using a SoftwareSerial routine. It transmits it to the PC
// using a hardware UART to USB
//
///////////////////////////////////////////////////////////////
#include <SoftwareSerial.h>
SoftwareSerial SSer(10, 11); // RX, TX
char buf[80];
///////////////////////////////////////////////////////////////
void setup() {
// Open serial communications and wait for port to open:
Serial.begin(9600);while (!Serial) {;}// wait for USB UART
SSer.begin(9600); // Software Serial Port, keep baud rate low
}/////////////////////////////////////////////////////////////
void loop() { // run over and over
int b,i;
do{
if (SSer.available())b=SSer.readBytesUntil('\n',buf,sizeof(buf)-1);
}while(buf[3]!='R'||buf[4]!='M'||buf[5]!='C');
if(b>7){// check b-7 not pointing into random memory!
for( i=0;i<b-7;i++)buf[i]=buf[i+7];// move array left
if(b>52){
buf[52]='\0';
}else{
buf[0]='\0'; // make it into a shortened string
}
Serial.println(buf);
}//-- fi --//
}//--end loop--///////////////////////////////////////////////
The GPS Unit does not transmit a course if the unit is standing still
Hence the two adjacent commas below. Very occasionally you get a course
reading, three digits, a decimal point and two decimal places.
Typical output:
Time:Status:Lat:N/S:Long:W/E:Speed:Course:Date
The Status is 'A' for Active and 'V' for invalid
The date is not sent if there is a course sent.(see below)
(for Location 54 degrees, 22.77761 N, 5 degrees, 32.82895 W)
064437.00,A,5422.77761,N,00532.82895,W,0.400,,080426
064438.00,A,5422.77759,N,00532.82892,W,0.027,,080426
064439.00,A,5422.77750,N,00532.82878,W,0.243,,080426
064440.00,A,5422.77747,N,00532.82879,W,0.016,,080426
So the speed is rarely zero, highlighting GPS variance (error)
And the need for additional sensors for dead reckoning such as
accelerometers, gyros and magnetometers (9 Axis, i.e 3D)
These are sometimes called IMU Inertial Management Units.
I did see (last night) a reading showing a course, it was:
215710.00,A,5422.77773,N,00532.83225,W,1.009,335.24,
No comments:
Post a Comment