HL7800 GPS/Cellular time sharing

Hi,
We are looking into time sharing between GPS and cellular and what kind of performance we can have when switching the RF resources between GPS and 4G.

Looking through the Product technical specification for HL7800 it mentions time to first fix for hot and cold starts. For hot start, it says the typical value is 2s. Let’s say we were to switch between GPS and 4G a few times every minute, and that we had acquired a fix and GPS position previously, would the hot start then be applicable, i.e. it would take ~2s to get a fix for the GPS?

Are there any similar delays related to switching back to 4G as well (for instance if it is possible the connection to the base station was lost after having been in GPS mode for a few seconds)?

Do you have any tips on how we can test this performance? Do you possibly have some sort of bash script or C program available to download that shows how to do this time sharing efficiently?

Best Regards
Jesper

Hi @jesper.persson,
I believe that 2s is theoretical info. The accurary will base on the actual conditions
You can refer to GNSS tool for the accuracy timer for each mode. The guide is posted here


Actually, we don’t have delays in switching back 4G but you can try to test your usecases by this tool for GNSS performance. From the output, you can calculate for your product
Please share any concerns you have and help us tick solution if the post is helpful
Thanks

@jesper.persson,

Its a bit of complicated question, switching the unit RF off and GNSS on takes a couple of seconds so that should not be an issue. The biggest problem you will have is getting and maintaining a fix using the GNSS, it takes time to download the ephemeris data from the satellites, without which the unit cannot calculate a fix.

If the unit has all of the ephemeris then yes the 2 seconds is possible once the GNSS is up, but if you are not allowing the unit to get the new ephemeris as they become invalid then it will gradually stop getting hot fixes and the 2 seconds will extend out to 10-20-30 seconds…

Regards

Matt

Hi @Vianney ,
That tool looks interesting but unfortunately I don’t have access to a Windows computer currently where I can test this.

Best Regards
Jesper

Hi @mlw,
I thought it would be a much bigger issue than it turned out to be. After some manual testing I realized what I was asking about is already taken care of by the HL7800 module. I thought we would have to bring down the interface to get GPS to work and vice versa, but it seems GPS starts running every time the network is not busy which is great!
But I will keep what you said in mind during the next weeks to see if it becomes an issue when hot starts are not available.

Best Regards
Jesper

Hi,

I’m troubleshooting why we do not get GNSS reports on the devices (same as Jesper). I don’t get GNSS even if I do bring the cellular interface down. It seems to be working sometimes as Jesper managed to get it working once.

I was trying to troubleshoot with some AT commands, here are my results:
AT
OK

AT+GNSSNMEA?
ERROR

AT+GNSSLOC?
+GNSSLOC:
FIX NOT AVAILABLE
OK

AT+GNSSNMEA?
ERROR

This seemed very odd to me. I cant even ask the parameter for the NMEA sentences without getting an error.

I can set the parameter:
AT+GNSSNMEA=1,1000
OK

But querying it afterwards doesn’t work:
AT+GNSSNMEA?
ERROR

And if I do
AT+GNSSNMEA=4 (output NMEA sentences to current interface)
CONNECT
the console just stops working.

Could this be an indication that we are doing something else wrong? I cant understand what it could be or what I should try to see what is wrong.

Best regards,
Gustav

@gustav.sohtell

What firmware are you running? It has been operational for quite sometime so should work but just so I know what to test against.

Regards

Matt

Hi @mlw,

Thanks for the reply.

4.4.6.0 probably. Could that be right?

Best regards,
Gustav

@gustav.sohtell

Yes 4.4.6 is the firmware version, I am running that and see the issue. I think it is actually something that needs to be fixed. You will need to push it back into your commercial channel to get a proper ticket rasied for this so the dev team can look at it.

Regards

Matt

Thanks Matt,

Interesting. I’m just testing arbitrary things to figure out how it works. It does sound strange that I managed to find a bug.
I don’t really know who to contact so I don’t think that will happen, but thanks anyway!

Do you have any other guesses of what I could do to try and get some GNSS data while also keeping a TCP connection up (but idle)?

@gustav.sohtell

It might not be a problem it might be my test method.

Re the follow up question, assuming you are in command mode then you can see when the unit has got a fix with the +GNSSEV unsolicted reposnes and then when the unit has a 2D/3D fix you can query it with at+gnssloc?

Regards

Matt

I’m not at the device right now unfortunately. The problem I have is that I’m not getting any GPS fix it seems like because it is not outputting anything. If it does it is with 0 satellites in the fix… which seems to be an old fix being retransmitted. But thanks for the reply!

Good afternoon @gustav.sohtell ,

Your findings seems odd, but is for certain worth investigating. Just as a high level process, the following should be the steps (assuming you’re starting from a cellular online state):

  1. AT+CFUN=0 (to bring down the cellular path in order for the positioning subsystem to use it)
  2. AT+GNSSSTART=0
  3. Look for URC +GNSSEV: 3,2 (2D fix) or +GNSSEV: 3,3 (3D fix)
  4. AT+GNSSLOC? to get location info
  5. AT+GNSSSTOP (+GNSSEV: 2,1 will confirm the GNSS subsystem has stopped)
  6. AT+CFUN=1,0 (to bring the cellular side back online)
  7. Look for URC +CEREG: 1 or +CEREG: 5 if you have it enabled, or alternatively query AT+CEREG? to confirm you’re attached to the LTE network.

I’ve reached out to you on the last existing email thread we’ve got to address any other questions you have, and to dig into more details of what you’ve found per your post earlier on.

Regards,
Tyrone

Good morning,

I figured I’d run a test using a sample Python script following the above steps. Plots are below. For reference:

  1. The module used is quite old HW (DV2.3)
  2. My test location is not optimal (indoors, ground floor of double storey building, large window south facing, Melbourne AU)




Basic other statistic was my network attach took on average 1.693 sec (From issuing AT+CFUN=1,0) across the 2423 samples. (RSRP around -93 dBm)

Regards,
Tyrone

Hi all,

Just an update on the above. I ran a brief test again with the difference being that I move my rig to open sky also uploaded the TTFF via TCP to get an idea of what is achievable.

Regards,
Tyrone

1 Like