Yes thats the expected output.
May I know if you tested it indoor or outdoor?
And did it take awhile to get those messages or?
It was tested indoors. The GPS gets a lock within a few minutes at worst. If the GPS does not get a lock, usually indicated by an LED flashing at 1Hz, then of course you do not get any data
Have you checked the GPS baud rate using u-center ?
I'm having similiar issues of the data not being reported properly.
I thought at first it was my baud rate and it being too fast??
I was using 115,200 but now changed it to 19,200.
I also downloaded the u-blox software and the baud rate is set to 9,600.
For fix mode though it says no fix.
I was also supplying power via the 3.3 volt pin of the Nano 33 IoT, but then I just switched to a separate power supply for the gps and I still get the same results.
I can't figure out why I am getting several ,,,,, characters without numbers between them.
Here is what I am getting on my serial output values, the coordinates are incomplete:
$GPGGA,061947.00,,,,,0,00,99.99,,,,,,*6B
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,3,1,11,03,17,175,,04,62,097,,07,50,291,,08,22,127,*77
$GPGSV,3,2,11,09,71,341,,16,33,045,,20,05,322,,22,02,167,*71
$GPGSV,3,3,11,26,04,041,,27,24,094,,30,18,267,*4B
$GPGLL,,,,,061947.00,V,N*47
$GPRMC,061948.00,V,,,,,,,090821,,,N*7D
$GPVTG,,,,,,,,,N*30
I'm using almost the same code:
//Nano 33 IOT serial pins, rx = 23, tx = 22 (Serial1)
static const uint32_t SerialMonitorBaud = 19200;
static const uint32_t GPSBaud = 9600;
void setup()
{
Serial.begin(SerialMonitorBaud);
Serial1.begin(GPSBaud);
}
void loop()
{
if (Serial1.available())
{
Serial.write(Serial1.read());
}
}
/*
NMEA Message Structure
To understand the NMEA message structure, let’s examine the popular $GPGGA message. This particular message was output from an RTK GPS receiver:
$GPGGA,181908.00,3404.7041778,N,07044.3966270,
W,4,13,1.00,495.144,M,29.200,M,0.10,0000*40
All NMEA messages start with the $ character, and each data field is separated by a comma.
GP represent that it is a GPS position (GL would denote GLONASS).
181908.00 is the time stamp: UTC time in hours, minutes and seconds.
3404.7041778 is the latitude in the DDMM.MMMMM format. Decimal places are variable.
N denotes north latitude.
07044.3966270 is the longitude in the DDDMM.MMMMM format. Decimal places are variable.
W denotes west longitude.
4 denotes the Quality Indicator:
1 = Uncorrected coordinate
2 = Differentially correct coordinate (e.g., WAAS, DGPS)
4 = RTK Fix coordinate (centimeter precision)
5 = RTK Float (decimeter precision.
13 denotes number of satellites used in the coordinate.
1.0 denotes the HDOP (horizontal dilution of precision).
495.144 denotes altitude of the antenna.
M denotes units of altitude (eg. Meters or Feet)
29.200 denotes the geoidal separation (subtract this from the altitude of the antenna to arrive at the Height Above Ellipsoid (HAE).
M denotes the units used by the geoidal separation.
1.0 denotes the age of the correction (if any).
0000 denotes the correction station ID (if any).
*40 denotes the checksum.
The $GPGGA is a basic GPS NMEA message. There are alternative and companion NMEA messages that provide similar or additional information.
Here are a couple of popular NMEA messages similar to the $GPGGA message with GPS coordinates in them (these can possibly be used as an alternative to the $GPGGA message):
$GPGLL, $GPRMC
In addition to NMEA messages that contain a GPS coordinate, several companion NMEA messages offer additional information besides the GPS coordinate. Following are some of the common ones:
$GPGSA – Detailed GPS DOP and detailed satellite tracking information (eg. individual satellite numbers). $GNGSA for GNSS receivers.
$GPGSV – Detailed GPS satellite information such as azimuth and elevation of each satellite being tracked. $GNGSV for GNSS receivers.
$GPVTG – Speed over ground and tracking offset.
$GPGST – Estimated horizontal and vertical precision. $GNGST for GNSS receivers.
*/
The GPS is reporting that all the signals it receiving from satellites are extremly weak so it cannot decode a location.
You do have the GPS outdoors with a good view of the sky ?
I am indoors next to a window, next to a pc. I just moved it close to the edge of the window, but still no luck.
I tried to move it away from any potential electrical interference (wireless keyboard/mouse/receiver, plug and play ssd).
I also tried two different modules but same model number NEO 6M but same results.
I will try to get it closer to an outside environment.
Thats likley the reason for it not working then, take it outdoors.
I hadn't really used these NEO-6M units in a long time, so I'm wondering if the button battery for the backup configuration and EEPROM needed recharging, so they had to perhaps do a cold start. Although on u-blox sight it says this is only 27 seconds.
I recall being able to get a signal indoors a while back, but it seems I was using the Arduino Uno at the time and it did get a signal indoors.
I decided to try it out on both the UNO and Nano 33 IoT.
It seems after I left them connected for about 20 minutes or so they both got signals.
However, I had raised the Nano 33 IoT close to the ceiling right above blinds and it got a signal.
The UNO is actually still at my desk and gets a signal just fine, I get a good readout and the light is blinking on the module.
I brought the Nano 33 IoT closer to the window frame and the frame is open to outdoor air now and slightly higher vertical level than the Arduino UNO, but it lost its signal and the light is no longer blinking.
It's interesting, why is it giving me issues on the Nano 33 IoT and not the Arduino Uno?
Could the Nano 33 IoT Wifi antenna be causing interference issues?
In terms of setup, I have the Arduino Uno on a plastic base plate and the NEO 6M is connected on a small breadboard,
and the Arduino Nano IoT 33 and its corresponding NEO 6m unit is connected to a large bread board.
Both of them are being powered via PC usb port going to the respective USB ports of the Arduinos.
What voltage is the GPS running on when connected to the Nano 33 ?
I realized I had it powered via the Vin pin of the Nano 33 at was getting a 4.66 V output.
I've connected it via 3V3 pin now and it's getting 3.2V.
On the Uno it's connected via the 3.3V pin and it's getting ~3.1V.
I tried replicating the same results as before by raising the Nano 33 IoT with the GPS module close to top side of window with the window open and still didn't get a signal. Weird.
Uno serial output ( I have replaced coordinates with x's):
It seems I have a connection to 7 satellites.
$GPGGA,060543.00,xxxx.47923,N,xxxxx.11956,W,2,07,2.56,190.2,M,-32.6,M,,*6D
$GPGSA,A,3,03,04,07,27,16,08,26,,,,,,3.09,2.56,1.73*02
$GPGSV,4,1,15,03,22,176,19,04,65,087,22,06,01,268,,07,48,285,15*70
$GPGSV,4,2,15,08,19,131,19,09,66,336,,11,00,296,,16,37,047,22*72
$GPGSV,4,3,15,20,02,324,,22,06,168,,26,08,041,13,27,22,099,17*7E
$GPGSV,4,4,15,30,15,263,,44,51,178,28,51,49,161,*42
$GPGLL,xxxx.47923,N,xxxxx.11956,W,060543.00,A,D*78
$GPRMC,060544.00,A,xxxx.47858,N,xxxxx.12020,W,0.702,353.45,100821,,,D*75
$GPVTG,353.45,T,,M,0.702,N,1.301,K,D*3A
Higher speed processors do seem to cause more wideband interferance and this can reduce GPS sensitivity.
In my view its not at all productive to question why in certain positions 'indoors' a GPS gets a fix eventually and maybe does not get one in a slightly different position.
If you want to compare GPS performance, then take them outside and put them in the same location, I have a long serial lead (20m) that allows me to do just that. I can then view the GPGSV senetences and see how the GPS is actually performing.
In the printout you showed us all bar one (num 44) of the 15 satellites in view are reporting very weak signals, its a surprise its getting a fix at all.
GPS do not need the battery, unless you do want hot fix capability whereby the GPS can get a fix in a couple of seconds from power up. However if the GPS has been off for 2-4 hours it will go back to cold fixing, so 45 seconds or so.
I tried searching for this, isn't wideband interference relevant to the WiFi module on the Nano IoT 33. Unless maybe I'm not understanding it properly.
I tried separating the GPS module on a separate breadboard than the Nano 33 IoT but I still get the same issue.
I don't have a laptop right now or a long serial cable so I will try to figure out a way of taking the modules outside. All I know is that the module works with the Uno indoors and that is a nice to have feature.
Faster processors clock at higher speeds and will affect RF devices more.
Got it. Thanks. Is there any way to isolate that interference?
Screening and distance, but first measure it to see if its a problem.
Measuring the cold fix times is a simple way to compare overall GPS performance;
I have been trying to connect my Arduino Nano 33 BLE with my NEO 6M GPS module and I get the same/similar problem.
The Nano33 BLE Pinout is like this:
So my connections looks like this:
My code is:
void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(115200);
while(!Serial);
Serial.println("I get serial");
Serial.println();
// Start the software serial port at the GPS's default baud
Serial1.begin(9600);
// while(!Serial1);
//Serial1.println("i also get serial1");
// Serial1.println();
}
void loop()
{
// Displays information when new sentence is available.
while (Serial1.available())
Serial.println("1 2 3");
Serial.write(Serial1.read());
}
And I get this output:
I thought I had a faulty GPS board so I got another one, but both boards gets me the same results.
I am not really familiar on how to use u-center, but when I connect my COM2 I get No fix on the right:
And when I press record I get these:
Are both boards faulty? Why do I get no result at all?
Any help would be appreciated!
P.S.
When I measure the voltage on the VCC and GND pin I get 3.23V
P.S.2
I tried all the codes given above that been said to work for Nano 33 Iot but got no results.
I also found a library for NEO 6M GPS: NEO-6M_GPS - Arduino Reference but when I try to use it, I get the message that it is not compatible with mbed nano architecture.
The code that you posted is incomplete but note th following
Serial ports on the Arduino Nano 33 IoT
The USB connector of the board is directly connected to the USB host pins of the SAMD21. This routing enables you to use the Arduino Nano 33 IoT as a client USB peripheral (acting as a mouse or a keyboard connected to the computer) or as a USB host device so that devices like a mouse, keyboard, or an Android phone can be connected to the Arduino Nano 33 IoT. This port can also be used as a virtual serial port using the Serial object in the Arduino programming language. The RX0 and TX1 pins are a second serial port available as Serial1.
So, using the Tx and Rx pins to communicate with the GPS at an appropriate baud rate you should read data from Serial1 and when a byte becomes available, print it to Serial to view it on the Serial monitor
Yeah I had forgotten the loop code and I edited and added that.
I tried to read the data from Serial1 but I only get this ?????????? output. Can you check again on my code now that it is complete?
That looks like the baud rate is wrong. Try 4800
