MC8705 GPS $PSTIS,*61?

IoT Modules MC/EM Series
1

Hi all,
We’ve been using an MC8705 card in some custom hardware and have been experiencing extended gaps between GGA messages on the NMEA port. Sometimes up to 9 Minutes. We initiate the tracking session using the AT command port by sending AT!GPSTRACK=1,30,10,1000,1. We’ve experienced this problem in multiple parts of Australia, Our development offices are in an industrial area in Newcastle and the production environment is in the QLD sugar cane growing region.

During these gaps the only message that we receive on the NMEA port is the “$PSTIS,*61” message. I can’t seem to find any information on what this message is or what it means. Can anyone out there help me with this?

I’d also love to hear if anyone has experienced similar problems when using the MC8705 on a low powered platform.

Thanks in advance.

2

Hi,

$PSTIS is the GPS session start indication.

Seems like it is not able to get location fix properly and thus repeating with a new session.

Does issue improved if you set larger and value?
As 30sec and 10 meters accuracy is not easy to achieve…

Thx

3

Hi,

Thanks for getting back to me.

We will try increasing the time to get a fix and/or the accuracy in the coming days to see if that works and get back to you. Unfortunately this might not be an option for our production environment. 30 Second fix time and 10 Meter accuracy is pushing the limits for the safety system we’re creating already.

My understanding was that if a fix could not be achieved to the accuracy within the time limit that a less accurate one would be returned, so with the aforementioned settings we should have a message from the NMEA port at most every 31 seconds. Is that correct?

I’ve noticed that there is a more recent version of the firmware supported by Telstra (Our Australian Carrier). Our current version is : T1_0_1_1AP R309 CNSZXL00000015 2011/01/21 18:28:30. The release notes don’t say anything about improved GPS support in the new versions. That aside do you know if there any chance that the new version would help?

Do you know if it’s normal to be getting a $PSTIS message regularly between fixes. Both when they’re happening regularly and when they’re not.
When its working we get messages such as this: ($PSTIS messages come through at 1 second intervals just like the $GPGGA message)

$PSTIS,*61
$GPGSV,4,1,16,28,52,284,43,09,52,206,42,05,15,254,39,08,54,199,38*78
$GPGSV,4,2,16,10,18,307,37,26,14,219,29,11,16,075,29,01,00,054,*7E
$GPGSV,4,3,16,03,13,137,,07,58,133,,13,42,028,,17,08,347,*76
$GPGSV,4,4,16,19,31,120,,23,10,029,,27,04,143,,30,,,*48
$GPGGA,045113.0,3253.315442,S,15143.079287,E,1,06,3.4,24.5,M,26.0,M,,*76
$GPVTG,329.4,T,324.4,M,0.0,N,0.0,K,A*2E
$GPRMC,045113.0,A,3253.315442,S,15143.079287,E,0.0,329.4,301013,5.0,E,A*10
$GPGSA,A,3,05,08,09,10,26,28,,,,,,,4.5,3.4,3.0*3C
$PSTIS,*61
$GPGSV,4,1,16,28,53,281,44,09,53,205,44,08,54,196,40,05,15,255,40*70
$GPGSV,4,2,16,10,17,309,39,26,15,219,31,11,16,075,29,01,00,054,*79
$GPGSV,4,3,16,03,13,137,,07,57,130,,13,40,028,,17,08,347,*78
$GPGSV,4,4,16,19,31,120,,23,10,029,,27,04,143,,30,,,*48
$GPGGA,045114.0,3253.315443,S,15143.079289,E,1,06,3.4,24.5,M,26.0,M,,*7E
$GPVTG,329.4,T,324.4,M,0.0,N,0.0,K,A*2E
$GPRMC,045114.0,A,3253.315443,S,15143.079289,E,0.0,329.4,301013,5.0,E,A*18
$GPGSA,A,3,05,08,09,10,26,28,,,,,,,4.5,3.4,3.0*3C
$PSTIS,*6

when it fails we get: ($PSTIS messages drop back to 30 second intervals and no $GPGGA messages are returned)

$GPGGA,175930.2,3253.318211,S,15143.086903,E,1,06,4.5,23.7,M,26.0,M,,*76
$GPVTG,0.0,T,355.0,M,0.0,N,0.0,K,A*20
$GPRMC,175930.2,A,3253.318211,S,15143.086903,E,0.0,0.0,011113,5.0,E,A*1C
$GPGSA,A,3,03,06,14,16,22,27,,,,,,,6.2,4.5,4.3*32
$PSTIS,*61
$PSTIS,*61
$PSTIS,*61
$PSTIS,*61
$PSTIS,*61
$GPGSV,4,1,16,06,47,264,45,27,45,248,43,03,31,241,42,22,62,224,40*76
$GPGSV,4,2,16,19,16,220,39,14,41,345,36,16,04,289,31,15,15,136,*7C
$GPGSV,4,3,16,18,52,143,,21,48,075,,24,16,097,,29,,,*48
$GPGSV,4,4,16,26,,,,25,,,,05,,,,12,,,*7B
$GPGGA,180152.6,,,,,0,,,,,,,,*71
4

I found this article useful to differentiate between accuracy and precision: http://gpsworld.com/gnss-systemalgorithms-methodsinnovation-accuracy-versus-precision-9889/ and I have been convinced that there is a difference. I have been comparing various GPS modules and units and have seen some with high precision, but questionable accuracy (it has a good fix on our location, but wanders like crazy, my desk is always moving) and another whose precision is a bit less (it shows me at someone else’s desk), but is accurate (unless I move it, it returns the same value consistently).

We have been fighting to get consistently good numbers of satellites and accurate fixes on moving targets such that we can truly rely on the data for reporting and positioning and continue to work to try to get it to work to our satisfaction.

On a hot or repeating fix, the data can come in repeatedly. This is how we normally use our device since we are on vehicle 12V and don’t have to worry about power consumption. When we do that, we don’t get the PSTIS message. However, when we specifically request a fix by command, we do get the PSTIS command, yet it is my belief that you wait for your reply or the timeout before requesting a fix again. Unless the unit is continuously integrating, which I believe it isn’t when you are manually requesting fixes (power consumption again), then it can take a while to integrate and get a fix even if it has already determined time and location prior to the current request.

I have also noticed that units that have a good fix and lots of satellites early in the day don’t necessarily have the same later in the day. Some drop below the thresholds I have set for receiving reliable data. They usually come back, some don’t. I had to set those thresholds because we had units supposedly working with 3 satellites that were showing hundreds of kilometres away! I find the HEPE numbers don’t necessarily reflect reality either, though they factor into my acceptance formula. I had to back off the HEPE requirement and make it larger because my 10m number was causing too many fixes to be rejected.

Even just watching the constellation data and S/N numbers, it has been educational for me to see just how dynamic the entire situation is on all kinds of GPS units and in particular how the number of used satellites drops off during constellation changes and then comes back. It certainly explains a lot about why we have faced so much of a challenge. This is why for high-accuracy GPS, DGPS is often used, WAAS/EGNOS etc. for one level of improvement and local, strategically survey-placed units for truly high-accuracy, high-precision work.

Yes, in all of this, I have become a NMEA interpreter and AT command watcher. I even took the NMEA association library, did some fixes to their library and wrote a NMEA information display program to see what was going on in real time, especially when comparing different modules we have on hand.

I hope that his helps some rather than confusing the situation.

5

Thanks for the reply @pdbuick.

Our problem isn’t to do with the precision or the accuracy of the fix. They have both been proved accurate by our testing. The problem that we’re facing is the periods of time where the MC8705 card stops reporting a fix. During these periods, which have at times exceeded 10 minutes, the only information we receive over the NMEA port is the $PSTIS messages.
We are not initiating a reconnect during this time, we are however polling the AT port to get 3G information, there is no problem with this polling during these timeouts. Eventually the card resumes logging NMEA sentences without any prompting from us or our software.
The problem occurs running our software or running light weight monitoring software that we wrote.
There appears to be no correlation with time of day.
We have run two of the same cards side by side and the times of the drop outs do not correlate.
The problem occurs if the unit is moving or stationary.
The problem occurs under WIndows XP, Windows 7 and Windows Embedded Standard 7.
The only correlation appears to be with using the MC8705 on a particular low powered rugged hardware.

6

It sounds to me like it is trying to integrate, fails and then restarts. Eventually it gets enough satellites to provide a fix and begin tracking. I haven’t worked a huge amount with an 8705 specifically, but I believe I have one on my desk at work for evaluation.

Do you have access to a spectrum analyser? After reading some articles on interference with GPS signals in embedded systems, we were considering noise from the memory and CPU as a problem in our system and still are.

We haven’t been able to measure the system, but one day I observed the satellite display on my Garmin unit while turning on and off our device about 3 feet away and there was a definite correlation between powering it on and seeing the satellite signals almost disappear on the Garmin, then unplugging and seeing them jump back up again. I did probably 20 - 30 “trials”. Unfortunately a couple of weeks later when I tried to demonstrate it to another staffer, I was unable to duplicate the effect.

Is it possible to somehow isolate/insulate the module using jury-rigged shielding to try to reduce or eliminate interference and see if that makes a difference?

7

Hi,

We’ve run some tests using a higher minimum accuracy parameter and received the same results. We were running two tests side by side on similar hardware and with the antennas about 2 m apart. In these tests we define a “Gap” of a period of time in excess of 31 seconds where we do not get a valid GGA message.
The tests were:
Test set one, starting 11:00 (Newcastle Australia Time) finishing about 17:50
Hardware 1 AT!GPSFIX=1,30,100,1000,1 - 1 Gap0 between fixes of 39 seconds.
Hardware 2 AT!GPSFIX=1,30,50,1000,1 - 22 Gaps between fixes of up to 6 minutes and 16 seconds

Test set two, starting at 17:50 and finishing at 09:00 the next day.
Hardware 1 AT!GPSFIX=1,30,100,1000,1 - 0 Gaps between fixes. Maximum time between fixes 11 seconds.
Hardware 2 AT!GPSFIX=1,30,2000,1000,1 - 48 Gaps between fixes of up to 10 Minutes and 2 seconds

What I see in those tests is that there is not a correlation between the extent of the fix.

We have started running a test on Hardware 2 that is using the maximum value for the accuracy parameter (4294967280). We decided to run this after reading the CnS protocol document, which appears to have more information on what appear to be essentially the same commands. In this document it states that providing the value of 0xFFFFFFF0 to the accuracy parameter is “accuracy disabled”.

In the CnS document it also states that the accuracy requirement is

Is this actually the expected behaviour? Our above testing seems to indicate that when there is difficulty getting a fix no message is returned.

8

Following up on the previous post. I’ve checked our NMEA sentence logs for the test using AT!GPSFIX=1,30,4294967280,1000,1. This test had 15 gaps between GPGGA messages greater than 31 seconds. The test has been running from 09:45 to 14:30 Newcastle Australia time.

9

I couldn’t help but notice that it was hardware 2 having the problem each time.

The other comment I have is that we run ours in continuous mode and just “integrate” the NMEA data. We did it with our own code first, but I later tested using the NMEA library available for free from them. (I had one bug fix which I haven’t been able to submit to them.)

Granted, ours are deprecated 89xx, but the 8705 worked as a drop-in replacement with the same configuration etc. We generally speaking don’t have a problem with our fixes most days on most devices. I may have adjusted the maxtime, maxdist and fixrate parameters on the units in the field. Perhaps playing with those would improve our “lock ratio” as well.

at!gpsautostart?
enable: 1
fixtype: 1
maxtime: 30 seconds
maxdist: 300 meters
fixrate: 1 seconds

at!gpsposmode?

MASK: 0x0000007F

10

To be honest, I don’t have chance to run high accuracy test myself… but from your result, it seems like hardware related, whereas Hardware 1 seems to do better in both test?
Any difference between the two hardware? antenna, etc?

Normally, we expect tracking mode (AT!GPSTRACK) to perform better, e.g. require smaller sensitivity as per PTS… but all depends on the sky condition…

In additional, do you use AGPS or XTRA feature?

Also, do you have chance to talk with your FAE from distributor or Sierra?