I’d be deliriously happy if it turned out to be caused by something dumb.
As I explained in an earlier post, I have recently noticed that in connecting the antenna via the tiny IPEX connection it is easy to inadvertently short the two conductors. If the board has a power LED the LED goes out. If it doesn’t have a power LED you get no indication that a short has occurred.
So it’s possible I’ve damaged either receiver or antenna this way. The short wire I used broke off an antenna. The inner & outer conductors don’t touch.
Thanks for the circuit diagram. It’s reassuring to know there is some degree of short circuit protection. I wondered if there were any polyfuses installed and it might come good in time. But it’s been a while now and still not working. I’ve just had it outside for two hours and no improvement.
This is my boxed up project. It’s a speedometer that has been working reliably for over 12 months. Being boxed up keeps it protected.
Recently I had the board out and connected to my phone thru a TTL/USB converter and an OTG cable to my phone app. Now it no longer produces sat data. Maybe the phone did something to it. I did use a data cable that had the GPS RX pin connected to the converter. My app doesn’t send anything to the GPS, but there is a serial initialising step and maybe that does. Clutching at straws too.
I noticed this quote from a help file that I created for a GPS app many years ago. I must have sourced it from somewhere at the time but I can’t remember where: “(Generally, GPS receivers include all satellites with a calculated altitude greater than zero, even if they can’t currently receive data from the satellite)”.
So the occasional satellite report that you are seeing could be that whatever old ephemeris data the device is using calculates that a satellite should be above the horizon. It doesn’t necessarily indicate that the device received any transmission from that satellite.
That agrees with what is normally shown in the skyview. It shows more sats than are being used. They are coloured red. You can follow them and see them come into use.
Sorry for the delayed response, we’ve been flat-out in support, and I lost track of this thread.
When I tested them, I was using a USB-to-serial converter, and IC test clips to clip into the holes on a breakout board. I tested a few modules, and was able to get a fix on them after a few minutes.
I’ll have a read of this thread in my own time and try to dig deeper into this issue.
An important consideration is that a GPS isn’t a workbench tool but is only useful when it is able to be taken mobile.
I’ll have a new one soon. I’ll first prove it with the simplest setup. Then it needs to be assembled into a mobile package. If it stops working at some stage I hope I will get some clue as to what I did wrong.
Hi John and all others
I just had another thought regarding this ongoing problem of multiple device failures.
I don’t know how many have failed but I assume it is more than one or two.
The failures seem to be similar. The unit works for a time then stops. Seemingly in a similar fashion.
Everything has been pointing to something happening repeatedly, An environment problem or something you (John) are doing which is being repeated.
I note the Blurb particularly mentions unit damage if the RX pin is exposed to 5V. You have said you know about this and have taken precautions but it is possible it could have happened.
I don’t remember anything said about the TX pin. If 5V on the RX pin can cause damage could it be that 5V on the TX pin could also cause similar damage. Now if this TX pin is driving a 5V logic device I think it would be feasible that the receiving device uses pull up resistors to 5V or in the case of Arduino use the (INPUT_PULLUP) statement which would be the same thing.
I don’t know what the actual situation is but I think it may be something worth thinking about. There is something obviously wrong as I don’t think multiple failures out of the thousands in use globally is an accident or co-incidence.
Cheers Bob
I’m content with the notion that I’m the common factor and it’s something I’ve being doing. I would just love to know what that something is.
I don’t believe I’m the only GPS tinkerer who has this problem. On the Arduino forum it is common for people to say they have setup a GPS module following the tutorials, installed the sketch and get no sat data or no fix. I think many give it all away or purchase another unit that they do get to work.
I have four modules that no longer produce sat data.
I don’t think I’ve come across any advice re protecting the TX pin. There are a few ways to get the data from the TX pin to a computer or phone - direct into an Arduino with or without a sketch, TTL/USB converter, HT-05 Bluetooth, OTG cable to a phone.
At any rate, the boards all generate legible NMEA sentences that are correctly transmitted to the PC or phone. They just aren’t populated.
Thanks for making the effort to help. I’ll have a new one next week and we might get some clues (or not).
Hi John
Terribly frustrating, I can relate to it in some ways.
I just thought that would it be possible that 5V on the wrong pin might damage some part of the receiver without adversely affecting the transmission of data to PC or whatever. Don’t really know.
Tip. When you get your new unit and are setting it up it will be a big help to DOCUMENT EVERYTHING including the time and date. It is a bit of a hassle but may be invaluable later.
Then again it may work and keep on working. I don’t know whether this would be a good or bad thing. You would be left wondering what the hell you did differently.
Cheers Bob
Yeah, I think that is something that could have occurred. Messing around with these modules involves much handling. You don’t use them indoors. They have to be outdoors to get reception and then to be useful it has to travel. It is easy to plug things in the wrong way round if not careful. I’m thinking about how to prevent that. I’ll be boxing this one up before powering up.
Okay, I’ll keep notes. It’s tempting to deliberately mistreat a working unit systematically to see what can cause failure. Like does shorting the antenna connection has an effect? But I don’t want to waste any more.
Yes it is isn’t it. But, if any failure has been caused by cumulative damage ie; damage that accumulates over some time, you may never be able to find out for sure. Just take notes and if you are successful and your set up proves reliable go over your notes and see if you can spot something you did differently.
Best of luck with this
Cheers Bob
John,
I just came across this thread. I’d be going right back to basics. Put it in a good location, use u-center to look at the NMEA sentences and in particular GPGSV to see how many satellites it’s seeing. If it sees some give it a good 30 minutes to see what happens. If it had to get a new almanac that can take some time.
Also, I’m not familiar with u-center enough to say how, but try to reset the GPS to factory settings, one of your applications may be configuring it for only a limited set of output messages.
Hi David. Thanks for the interest & those suggestions.
I’ve established that a poor view of the sky is not the problem.
I’m getting the six sentences: RMC,GGA,GLL,GSV,GSA & GSV on all units. These sentences will provide all positional data, if & when sats are received.
I monitor GSV to see what sats are being received.
I allow for 20-30 mins for each test I do. That’s more than enuf time for the unit to build the almanac and obtain the ephemeris for each detected sat.
I’ve used u-center to reset a unit to the default configuration. I can see that this works (I play around with the update rate & see it goes back to default of 1Hz). No improvement in performance. I don’t understand all the terms in the CFG options.
The best performance I’ve seen from any of my units is holding on to one sat long enuf to report the date & time.
My test setup for when I get a new unit and can compare its performance with that of a non-working one side by side. I have two instances of u-center running. Each is being fed from one of the GPS units by selecting the corresponding COM port:
Breadboard holding the two GPS units. Each is wired to a TTL/USB converter. The right converter is plugged directly into a USB port (COM 6). The other is connected by cable to another USB port (COM 5). I think this is the nearest I can get to an identical setup for two units:
Hi John.
Before you connect your new unit check what the TX pin is doing just in case. I know it is clutching at straws but you need to cover all bases and try to leave no unknowns.
I note you are using TTL/USB converters. If the TTL is 5V then this pin could be pulled up to this voltage. If the output from this pin is 3.3V logic it might be possible this 5V finds its way to the receiver and does some damage. Better be sure than fry another GPS unit. If this is the case you would be better off using a logic level converter on this line.
Your comparison set up is the way to go. You seem to have plenty of duds so why not use them.
Cheers Bob
Bob,
Do you mean the TX pin on the converter? I’m not wiring them to the GPS units. I don’t need to send anything from u-center to the GPS. That’ll be one variable excluded. I’m willing to use it on my dud units, but not on the new one which I shud have tomorrow.
I tried a logic level converter but it didn’t seem to work properly or I don’t understand it. I’ll come back to you on that.
The TTL/USB converters come with a jumper to connect its 5v pin to its 3.3v pin. I’ve removed that. Do you know what its purpose is?
No, I am not familiar with the details. It might be to change the pull up voltage. One way to find out, with nothing connected measure the voltage on the TTL/USB converter pin with the jumper in and out. See if you can measure the signal voltage on the GPS pin (an oscilloscope would be useful here) or somehow find out. Any pull up on the TTL/USB converter unit should match that (5V or 3.3V).
Cheers Bob
