Author Topic: oscilloscope probing a GPS connected to an FTDI programmer  (Read 2854 times)

0 Members and 1 Guest are viewing this topic.

Offline sbsivertsen@gmail.comTopic starter

  • Newbie
  • Posts: 3
  • Country: no
oscilloscope probing a GPS connected to an FTDI programmer
« on: November 04, 2018, 03:19:41 pm »
Hi,

I have an GPS that I'm note sure if it works and wants to see there any signals present. The GPS is connected to an FTDI programmer.

Is it safe to probe the signal pins with an oscilloscope or do I risk a ground loop since the FTDI is connected to my computer's USB and the computer is connected to mains ground, same as the oscilloscope?

Regards
Stig Sivertsen
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #1 on: November 05, 2018, 01:54:30 am »
I wouldn't hesitate to do this. (Not saying it is safe, just that I would put a scope on this without a second thought).

If you are concerned, use a laptop and unplug the mains, so the laptop and module are floating.

Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #2 on: November 05, 2018, 02:54:32 am »
Go for it, thats an interesting thing to do if the software you use is the right software. I may be able to steer you to some interesting software for that. Just ground the grounds together so you arent using two grounds by mistake. And its always smart to not run power from other sources. A bit of advice, a great many perfectly fine GPSs will take some experimentation with serial port settings and software resets, to start after they have been off for a while. You should start it up with the manufacturers own configuration program if possible. Once everything is set properly, the GPS connected to an antenna, it still may appear dead while it sits there trying to get a fix. You may see absolutely nothing or you may see a banner with the manufacturers name and the software revision and then an endless stream of NMEA sentences all populated with zeros. Just be patient. The default for NMEA is 4800 baud N81, I would start there.

make sure an antenna is connected and you have some kind of sky view for it. It will need a minimum of 13 uninterrupted minutes under the most ideal conditions from a cold start and typically much more before it successfully has downloaded the ephemeris data.

I cant count how many times, Ive been certain a GPS is dead when it surprises me. Suddenly you'll notice a signal, then a bit later it becomes possible for it to get another one and then another and then suddenly many more may suddenly pop in. Poof, its now working.
« Last Edit: November 05, 2018, 03:15:34 am by cdev »
"What the large print giveth, the small print taketh away."
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #3 on: November 05, 2018, 04:23:40 am »
Also, although NMEA sentences over RS232/serial is the default protocol for most GPS modules it is not uncommon for them to be configured to use vendor specific protocols and over other interfaces (e.g. I2C or SPI). Just because RS232 is quiet it doesn't mean that the module is not functional.

Sometimes modules can be configured to fewer messages - for example for some uses position might not be important, only time. These settings can be held in the module's flash and persist over restart making the module seem "dead" until a good fix is acquired.

As a rule of thumb current standard "time for first fix" for a cold start on a multi-channel module ideal conditions is around 30 seconds from signal acquisition of the first four space vehicles - this usually works out to be well under a minute with good visibility of the sky. The "wait 15 minutes" time is for the full Almanac to be downloaded, which allows for a faster startup based on assumptions about receiver's location and the current time.

So turn it on and get a cup of coffee. if it doesn't start working after getting a cup of coffee, then go to lunch. If it still isn't working, then plug the antenna in  ;)
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #4 on: November 05, 2018, 08:31:54 pm »
If its really a cold start, i.e. the hardware does not have any data in it as to where it is, and no ephemeris data, which is typical if its been off and completely away from power for a while, it will almost always need at least that 13 or so minutes, unless it has access to a network connection and can download it via the net. (thats the norm for cell phone GPSs but not others).

Unless you pre-load it with an ephemeris file you have lying around.

There is another model which is used too, where the cell phone handset is a dumb GPS receiver and all the processing is done elsewhere. Then it can wake up any time, download some data and send it to the mother ship, practically using no battery and not even lighting up or anything. Then it can get its fix more accurately too using DGPS. GPSs can be set to do this at regular intervals.

This kind of post-processing model can be used to keep track of where a cell phone is even when its officially 'turned off'.

"What the large print giveth, the small print taketh away."
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #5 on: November 05, 2018, 09:37:27 pm »
If its really a cold start, i.e. the hardware does not have any data in it as to where it is, and no ephemeris data, which is typical if its been off and completely away from power for a while, it will almost always need at least that 13 or so minutes, unless it has access to a network connection and can download it via the net. (thats the norm for cell phone GPSs but not others).

I am trying to resolve what you say with:

- the knowledge I acquired building a software GPS receiver (that without any prior knowledge requires at least 4 Space Vehicles to be tracked for 35 seconds to get a location fix), just from raw 1-bit ADC data.

- specs for common GPS module (e.g. The UBLOX NEO-7 at https://www.u-blox.com/sites/default/files/products/documents/NEO-7_DataSheet_%28UBX-13003830%29.pdf) that state cold start performance is 30 seconds,

- specs for another common module Skytraq VENUS634FLPx at https://www.sparkfun.com/datasheets/GPS/Modules/Skytraq-Venus634FLPx_DS_v051.pdf it also states 30 seconds.

- specs for GARMIN GPS 16x at http://static.garmin.com/pumac/GPS_16x_tech_specs.pdf say 45 seconds

- Testing I found on the interweb at https://www.skydelsolutions.com/en/resources/app-notes/app-note-gnss-basic-tests-ttff/

Can you convince me otherwise?
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #6 on: November 05, 2018, 09:53:38 pm »
I don't know, but I suspect that for some reason, the used definitions of what that means now must be different! As i said higher up in the post, there are several different models of "GPS" Two that can acquire a fix for somebody that can deliver a fix sooner are AGPS and post-processing on another machine. Neither is available to most people 'in the middle of nowhere' say, if they are on a boat, without net access. Then they are either going to leave the GPS on all the time (always a good idea since they take almost no electricity) or wait that time after its turned on, unless by some fluke, they already have the data.

(Edit- the absolute minimum time to download both ephemeris and almanac is stated to be 12.5 minutes for example, below:

https://en.wikipedia.org/wiki/Time_to_first_fix )


Hamster, there is definitely some definitional misunderstanding as to what means what.

I'd like to see more info if you have it.
« Last Edit: November 05, 2018, 11:39:50 pm by cdev »
"What the large print giveth, the small print taketh away."
 

Offline ruffy91

  • Regular Contributor
  • *
  • Posts: 240
  • Country: ch
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #7 on: November 05, 2018, 10:47:51 pm »
You don't need the almanac anymore. Modern gps receivers have enough channels and discriminators to search for all the satellites at the same time.
You only need the ephemeris for a fix which correlates to the ~30s mentioned for TTFF.
 

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #8 on: November 05, 2018, 11:40:40 pm »
ruffy91, do you have a link that explains this?
"What the large print giveth, the small print taketh away."
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #9 on: November 06, 2018, 12:24:19 am »
I don't know, but I suspect that for some reason, the used definitions of what that means now must be different! As i said higher up in the post, there are several different models of "GPS" Two that can acquire a fix for somebody that can deliver a fix sooner are AGPS and post-processing on another machine. Neither is available to most people 'in the middle of nowhere' say, if they are on a boat, without net access. Then they are either going to leave the GPS on all the time (always a good idea since they take almost no electricity) or wait that time after its turned on, unless by some fluke, they already have the data.

(Edit- the absolute minimum time to download both ephemeris and almanac is stated to be 12.5 minutes for example, below:

https://en.wikipedia.org/wiki/Time_to_first_fix )


Hamster, there is definitely some definitional misunderstanding as to what means what.

I'd like to see more info if you have it.
This only holds for GPS, not other GNSS systems....

To acquire a space vehicle's data, you have to look for each of the 30 or so space vehicle's random number across about 10kHz of bandwidth, at 2048 different phase alignments. Doing this requires up to 2 million attempts to perform an exhaustive search for all space vehicles. This is why a cold start used to take so long....

Once the receiver has acquired the signal, it starts tracking the space vehicle. This gives it access to the 50 bits per second of BPSK data being transmitted.

This data is formed into NAV message frames, - there are five different 300-bit subframes, each taking 6 seconds to transmit.
- Subframe one has the timing correction for the transmitting space vehicle
- Subframe two and three has the precise orbital information
- Subframe four and five have the pages of the almanac. (IIR there is 25 pages in the almanac).

Once you have subframes one, two and three you can calculate the position of a given space vehicle at a given time (within a time window around the transmission time) - you don't really need the Almanac information in subframe four or five to get a location fix.

This is because the orbit information in the Almanac have less precision and are only approximate. However, if the receiver knows approximately when and where you are, you can work out which space vehicles you can see in the sky, and it might also be able to calculate the doppler shift. It can then prioritize these optimize the search to try and find these signals first, speeding up the time to first fix - however it still needs to get the detailed orbital information from the current NAV messages to give a fix.

The upshot is the data in the Almanac speeds up only acquisition of the space vehicles, but doesn't really feed into the tracking or positioning (except for a few correction values that can improve accuracy).

GPS receiver hardware has advanced to the point where the almanac is of little use. For practical purposes you can search for all signals on all channels at once, so the time to first fix with and without the almanac is approximately the same.

As an example. one way to do this is to take the FFT of 2ms of data, then convolve that against the precomputed FFTs of the space vehicle's random signature. This gives you very good information of the power levels, signal phase and doppler shift for all space vehicle in that 2ms of data, allowing you to acquire the space vehicles very, very quickly, with only 2ms of data.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: oscilloscope probing a GPS connected to an FTDI programmer
« Reply #10 on: November 06, 2018, 12:59:58 am »
So, you're saying that newer GPSs that are available today, which aren't attached to a cell phone or packet modem or similar, can acquire a fix really quickly without any additional basic contextual data?

By searching the entire solution space faster? Thats very cool.

Even if it has NO idea of what hemisphere its in or what date it is or anything?

Can you give me an example of a chipset that does this?
« Last Edit: November 06, 2018, 02:30:27 am by cdev »
"What the large print giveth, the small print taketh away."
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf