This is a placeholder topic for “Adafruit Ultimate GPS FeatherWing” comments.
Give your Feather a sense of place, with an Ultimate GPS FeatherWing. In 2013 we designed the Ultimate GPS module to satisfy all your GPS desires - and now we have…
Read moreHi,
Bought this feather to build the logger as described in the project here. (https://core-electronics.com.au/projects/vehicle-gps-logger-and-speedometer/).
Very well documented project!! Project broken up, with explanations and testable modules for the separate functionalities: gps, sd-card.
But:
I get no gps-fix. I have the antenna connected, and have it lying outside.
Can I ask for suggestions on how to debug?
Hardware wise: checking the soldering I would assume.
Is it possible to see if anything is received/read from satellites? Position, date time?
Any suggestions welcome.
Does this mean that you have the example code working up to the point where it displays the GPS data, but that the data des not give the correct information? That means you got past the “Display OK!” part and started reading the GPS data. You should get a speed of zero. If that works then I presume that you are getting to the “No GPS Fix” message.
The likelihood is that the soldering is OK, otherwise there would have been an error prior to this point. However a careful examination of the soldering with a magnifying glass is always a useful first step.
Have you run any of the library examples (eg DumpBasic, or Parsing), and what was the result?
You can use the code that you have at the point of the “No GPS Fix” message and add some code to print any of the GPS data, using the library examples as a guide.
Or you can simply remove the halt that has been inserted at the message and go ahead and display the data that was received. But note that the code was written assuming that the message was properly received, so there could be errors trying to process the message (and the error messages may not be helpful).
// while(true) is halting code. A while() loop operates for as long as its
// contents within the parentheses are true. As in this case it is
// declared as always true, the loop does not stop, effective halting the
// code here.
// while(true);
Hi Jeff,
Thanks for picking this up.
Matthew has created a few scripts to test functionality (GPS and SD, and possibly more, but this is where I started.
At first I took the full script, at the end of the project page, without the comments. That did not work at first look, so I followed his explanations and got stuck already at the first, the GPS.
In the project it is the first text box (code) in the project:
I copied that in an arduino script, validated (warning about unused variable ‘c’, line 43, but could ignore because it is ‘just’ a warning in testcode). Got no errors.
Then uploaded to the featherwing, also no error, but also no GPS-data,
Modified the script a bit to find clues:
**Serial.println(“Check: Received?”);
**Serial.println(GPS.newNMEAreceived());
**Serial.println(“Check: Parsed?”);
**Serial.println(GPS.parse(GPS.lastNMEA()));
**if(GPS.newNMEAreceived()) if(!GPS.parse(GPS.lastNMEA())) return;
This results in:
…
Check: Received?
0
Check: Parsed?
0
- No GPS Fix-
/ No GPS Fix|
| No GPS Fix|
\ No GPS Fix|
Check: Received?
0
Check: Parsed?
0
Check: Received?
…
Seeing that GPS-read does not return any usefull information, my question is:
-can I do deeper debugging?
-is there a best way to solder. In the end, to me it seems only 2 pins are used, from datalogger (where the micro usb supplies power) to screen to gps. If I was too careless with soldering to cause connetions between pins, or not soldering the 2 important pins (on each board), would that cause issues? I am going to use a multimeter to see if I connected pins…
Any suggestions welcome, and i will check the sd-card functionality and display.
BTW, I am not totally new to Arduino etc and soldering, but especially this deeper level and hardware related stuff is challenging.
Regards,
Ton
It might or might not help, but this is what I did.
Load the example sketch ‘Hardware Serial Parsing’.
Turn echo on:
// Set GPSECHO to 'false' to turn off echoing the GPS data to the Serial console
// Set to 'true' if you want to debug and listen to the raw GPS sentences
#define GPSECHO true
Adjust the baud rate for the GPS device. This is probably required because I have changed the default of my particular device, and should not be required if the default from the factory really is 9600.
// 9600 NMEA is the default baud rate for Adafruit MTK GPS's- some use 4800
GPS.begin(115200);
Open the serial monitor window and upload the sketch. This was the result:
Adafruit GPS library basic parsing test!
PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,028
PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,028
$PMTK220,10005Q-⸮0531
$PMTK220,10005Q-⸮0531
The echoed line tells me that the GPS device is working and talking to the MCU at the Serial1 port with the correct baud rate. If you get nothing then there is likely a problem in the soldering. If you get garbage (eg ⸮Q-⸮14,0,1b, ,0,0,0,0,0, b⸮b⸮b⸮R⸮⸮h0P)⸮⸮b⸮⸮⸮⸮R⸮25 ⸮Q-⸮14,0,1b tA ⸮⸮⸮R⸮⸮j tA ⸮⸮⸮R⸮⸮j) then the baud rate is wrong - try something other than the default. Once you get that message then you know you have communication and the problem is either that the GPS is not being initialized correctly or it is not receiving a signal.
Note that this test was with equipment somewhat different than yours, but it should still be valid. I will try to find some parts more similar to your setup and repeat this tomorrow.
Hi Ton,
Let us know how you go with Jeff’s excellent suggestions. We can set one of these up on the bench if you continue to have trouble.
Hi James, Jeff,
Thanks for jumping in. Will try the suggestions. Had to search for the GPS_HardwareSerial_Parsing script, and found it.
I like the initial project very much as it explains the full picture, and has the (clean) code for that, but it also helps with understanding and checking the components for gps, display and sd card.
When I have this running, my plan is/was to modify it to be able to use in a car, unplug every x days or trips from the car, then go to home wireless and upload. There are probably different ways to accomplish that (pi-zeroW with GPS head, or perhaps wireless on this feather triplet).
To be honest, I am afraid that I have my soldering not OK, and was trying to find if there is a way to find out if I had made short circuits in the used pins, or in the unused pins. I soldered the 3 boards on to the tripler.
I will let you know.
Ton
Hi Ton,
You can always upload a photo of your soldering to this forum thread if you want a second opinion on whether a joint looks alright or is a bit borderline.
Let us know once you’ve tested Jeff’s suggestions.
I have tried the parsing example with a UNO and two different ESP dev boards, and two different GPS modules, and there were only two things that caused a problem. One was the wrong baud rate, which can be detected from the sort of strange character strings that I mentioned above, and is easily fixed.
The other was one of the ESP boards that seemed unable to provide enough power for the GPS module, so I ran a separate supply for the module.
Other than that, getting a sensible display on the console was quite straightforward. So even though I can’t exactly replicate your setup, a hardware issue is looking most likely.
Hi Tron
I will be perfectly honest with you here.
Regarding soldering. I am a bit lost and find it hard to understand why some jump in at the deep end with this task without reading something on the subject and having some practice.
It is is far more important than it looks. Poor or absolutely useless solder joints are the cause of so much frustration. If a problem does not show up now it probably will at some time in the near future. It really is one of the important things you need to do as not everything is “plug and play” or solder free.
As far as introducing shorts between pins. Very easy to do and can cause catastrophic problems, even destroying a board. You have the cost of replacement and also the inconvenience of waiting for said replacement. Also what else has been damaged.
My humble advice for what it is worth… Study some printed material. Get a bit of old board or purchase some proto board and have plenty of practice. There is plenty of info and pics around to help identify a good and bad joint. A very common fault with newcomers is TOO MUCH solder.
Cheers Bob
Thanks for the advice. But it does not sound humble to me
I have read printed, but practice is different.
And I have soldered before. And with success.
Thanks anyway for the honest comments.
Hi Tron
You have to be 100% sure so you can eliminate this from the cause of any problems with certainty.
And THAT will only happen with practice.
Cheers Bob
Hi Brob,
Something wrong with your keyboard i am afraid.
Even experienced solderers will make errors.
Hi Ton
From now on I will leave my keyboard alone. Good luck.
Cheers Bob
Hi James/Jeff/Trent,
Thanks very much for the feedback. (some people can reply in constructive ways!)
I did a few things (had to find time…).
Took the feathers from the tripler and put them on a breadboard (see the pics).
I just used the 2 pins on each board that were connected via the tripler (pin 2 and 4 that are connected through the board).
With a multimeter checked if any adjoining pins were connected (no) on all 3 boards.
I used the ‘Hardware Serial Parsing’. Had this result:
Time: 00:00:00.000 Date: 0/0/200 Fix: 0 quality: 0
When I connect to usb a white led (right next to usb connector flashes). When I reset on the board the red light flashes.
When connected the red led on the gps board flashes slowly (the polling I assume).
Even the display is not reacting to anything (the display came with headers soldered).
I am a bit out of options. I hope you can suggest.
I assume that the battery cell on the gps is not strictly required as date and time would come from gps signal.
Can you confirm that my analysis on the pins is correct?
All feedback is welcome. It is very much appreciated. Then I can continue with my journey on Arduino etc. My arduino version is 1.8.5. But I get no messages or warnings.
Regards,
Ton
Hey Ton,
It may be worth looking at a couple of things.
First thing would be to ensure the antenna is properly connected and has clear unobstructed view of the sky.
I will mention that the soldering of the pins may be causing issues, if there is not a solid connection in those solder joints, it will cause issues, might be worth ensuring that a solid connection has been made with the pins as I can see in those photos that there may be some problem pins.
Last thing is to include some print functions in the code, so that you can se where the code is getting up to and ultimately failing, this will help narrow down what the issue is.
Cheers,
Blayden
I can’t see from those images how the GPS data is connected. There should be two connections for the UART near the bottom right of the module. Similarly, the display should have two connections for the I2C. Can you post a diagram of exactly how you have it wired?
/Edit
And looking at the project page there seems to be a few important steps missing between 3 and 4!
It appears that both the project page and the Particle page it is based on don’t mention the wiring for data.
To test just the GPS, using logging to the console to confirm, connect Tx/Rx on the GPS to Rx/Tx on the Feather.
Then, to test the display, add a connection SCL to SCL and SDA to SDA between the feather and the display.
That should make a difference.
Edit/
Hi Jeff, You nailed it.
Display working now.
I get messaging about GPS: initialised, not stable etc.
Pin wiring was the missing point, and still is a bit for tx rx on the logger and the gps.
For that I need to do searching.
And potentially the antenna, but as I am on a 6th floor with clear view. It should not be an issue.
Antenna connected to a Pi-Zero has reception. So probably wiring.
Thank you very very much.
(will now see how it works on the tripler.).
Ton
Latest news: GPS-fix working!! With the GPS_HardwareSerial_Parsing script.
It need to find satellites…
Great,
Now putting it together.
Quite a learning up to now.
Thanks for supporting, suggesting.
Thanks for letting us know that you got it working. That last step is quite important, and it’s odd that it should be missing from the project description.
You did mention that you were connecting two wires, but I assumed that was in addition to power and ground. I usually know better than to assume 
And you can get our latest projects and tips straight away by following us on:
