LC76G entering backup mode

IoT Modules GNSS Module
1

Hi,

We are using LC76G module in the project and have some strange variations in TTFF times after overnight sleep in backup mode. The EASY mode should be enabled by default, so overnight sleep shouldn’t be a problem.

The document LC26G&LC76G&LC86G_Series_Low_Power_Mode_Application_Note says in the chapter 2.1.2. Testing Procedures that “The module returns $PAIR001,650,0*38 when it enters the Backup mode.”.

However the document LC26G(AB)&LC76G&LC86G_Series_GNSS_Protocol_Specification says in the chapter 2.3.46. Packet Type: 650 PAIR_LOW_POWER_ENTRY_RTC_MODE that “If successful, the module will be set to Backup mode and be prevented from receiving any commands”. It doesn’t say anything of receiving the ACK OK message.

And indeed we can see that usually we don’t get the ACK OK message at all and sometimes we get it.

Module sends the 010 PAIR_REQUEST_AIDING message for both time and location during startup, which I think means that it hasn’t got the stored position information or running RTC available. We do feed the both information to the module but still got the bad TTFF.

Question is: should the ACK OK really always be received to $PAIR650 command and if yes, for how long should we wait for it before shutting down the VCC?
The documents don’t state for how long does it take to run down the module’s systems and store the statuses in the worst case.

Additionally I’d like to refer to two a bit contradictory entries in Quectel forum:
In L76 backup mode support says that ephemeris data is valid for 2 hours and that fix rate can be other than 1Hz.
In L76 - How to use EASY Technology? support says that ephemeris data is valid for 3 days - if powered up enough time - and that NMEA output frequency should be 1Hz.

Regards, Jukka

2

Hi JukkaTLa,

I check version LC76GABNR12A01S and LC76GABNR01A03S on EVB, commands：
$PAIR650,1*24

$PAIR650,10*14

and $PAIR650,0*25 all have correct ACK within 1 second before entering backup mode. Attached logs FYR.
Forums_LC76G_enter_backup.zip (7.6 KB)

Best regards.

3

Thanx for the response.

So there must be some other reason for us not always getting the responses from the module, maybe some HW-related thing. Must investigate this further. We maybe should add retransmissions for the $PAIR650 command in case that ack is not received.

However it would be good to add into the documentation some suggested time limit for waiting for the responses.

Rgrds, Jukka

4

Hi Jukka,

About ephmeris data validity.
The longest validity of EASY data is 3 day. EASY is a prediction of satellite orbit. It’s kind of like almanac It can help module roughly know where the satellites are.

Ephemeris data which store in module RAM memory have 2 hours validity. These ephemeris data are automatically stored when module keep fixing.They record where the satellites exactly are, and module can calculate the position of satellites after reboot.

Best regards.

5

Thank you again for the clarification.

So it is almanac versus ephemeris data, should have noticed the difference in wording in those two support cases I attached. My mistake.

BR, Jukka