www.st.com

[Francesco Virlinzi]

Hi all

Have a look @

https://www.st.com/resource/en/application_presentation/teseo-3-quick-testing-guide.pdf

it's an easy way to test the connection to the Teseo III server based Assisted GNSS without special equipment and/or tool.

[EHuse]

My PC is 64 bit. But the value is in an unsigned int, which I did a sizeof on and it does show as 4 bytes/32 bits.

Oh well, it is working now with mask.

[EHuse]

When I issue a cold start ($PSTMCOLD) to the device, it seems that I must wait around 30 seconds before I send $PSTEPHEM commands to it. Is I send them earlier, I get an OK response but the if I dump the ephemeris, it does not seem to have stored the data.

[EHuse]

Another question, there are options to program realtime Ephemeris, Almanac data, and the "synthetic" data. Is it necessary to program all of them from the server data.

Right now, I'm just programming the real time Ephemeris data ($PSTEPHEM) and it doesn't seem to help that much in getting lower time to fix.

[Francesco Virlinzi]

Ciao

There should be some issue in the parser and the '$PSTEPHEM' commands raised are not acquired by Teseo (which remains with an empty almanc/epemeris data-base).

The 30 seconds you see is the standard TTFF from COLD the data you receives after 30 seconds have been just downloaded from satellites.

For sure you have the antenna connected.. If you unplug the antenna... after 30 seconds you will have still an empty database.

Regards

Francesco

[Francesco Virlinzi]

Ciao

> Is it necessary to program all of them from the server data.

No it isn't necessary.

> Right now, I'm just programming the real time Ephemeris data ($PSTEPHEM) and it doesn't seem to help that much in getting lower time to fix.

I think the data injected have been rejected.

Regards

Francesco

[Francesco Virlinzi]

FYI: the ephemeris and almanac data injection have to be anticipated by an PSTMINITTIME.

Generally the NMEA script should be like:

$PSTMINTTIME...

$PSTMALAMANC...

..

$PSTMALAMANC...

$PSTMEPHEM

..

$PSTMEPHEM

Did you add the PSTMINITTIME?

Ciao

Francesco

[EHuse]

Hey again,

I have verified that the PSTEPHEM commands do respond with $PSTMEPHEMOK*4B. I also do a ${PSTDUMPEPHEM) to verify that all 31 GPS satellites have been programmed. So I'm fairly sure that the data is being programmed into the chip okay.

I also had the device get a lock without any preprogrammed ephemeris data and dumped the ephemeris data from the chip. Then I generated the ephemeris data from the server and compared the 2. Many data lines were identical and all of them were similar. I assume the ones that changed were just due to the ephemeris data being updated on the server before the chip got it.

So I think I'm programming the ephemeris data okay but it doesn't seem to help much with time to fix.

Warm starts are very quick for time to fix. Also doing a cold start without erasing the ephemeris data ($PSTCOLD,0xC) is quite quick.

So I'm at a loss on what to do next. I don't understand why programming the ephemeris data isn't really helping on a cold start.

I could try adding the GLONASS satellites to the server data but the difference in endianess means I pretty much have to redo all the bit fields in the message. It's a lot of work to port the messages to a different platform.

[EHuse]

So comparing the "predictive data" vs the real time data? Is one better than the other?

If I use just program the Real Time ephemeris and almanac data, that should be enough to get a very fast fix, right?

[EHuse]

Okay, it is possible that my testing setup is causing issues. My problem now is that I cannot find a good test environment. It seems that time of day has far more impact on my time to fix than anything else.

Right now I have a good view of the sky and TTF is usually less than 3 minutes from a complete cold boot that deletes both ephemeris and almanac data. Which if this were true for our device all the time then I would not even need the assisted GPS.

Could the predictive ephemeris data be speeding up time to fix, even if all of the RT ephemeris and Almanac data are erased?

Why are there 2 methods on the chip for AGPS? Is there a reason to choose one method over the other?

[Francesco Virlinzi]

Ciao

Mike will be in contact with you to understand where the issue is.

>Why are there 2 methods on the chip for AGPS? >

> Is there a reason to choose one method over the other?

There isn't a method better that an other. Which method you select depends on the final application capability.

• RT-AGNSS has a better TTFF but it needs continuously internet connection;
• P-AGNSS has ah higher TTFF but it needs just ~8K each 2 weeks...

therefore "better" depends on the final application.

Regards

Francesco