LC79HAL problem with EPO for BDS

I’m trying to download Host EPO data and send it to LC79HAL.
I have a download function that downloads the file for each constellation, parses it, and sends it to the module.
Then I query the module to see if it uses the downloaded data or not (ie the process is successful or not)
I did the process for GPS, GPS+GLONASS, and Galileo files and the module acknowledged it.
But when the process runs for BDS, although the module sends ACK for every SV data it receives, in the end when I query it($PAIR470,3), it returns this: $PAIR470,3,0,0,0,0,0,0,0,0,03A which states the unsuccessful of sending EPO file to the module.
I’ve verified the process with QGNSS this way:
(unfortunately, it doesn’t support LC79HAL AGNSS download, but as the processor is the same as LC76G, I chose the latter one.) I connected a module using a serial port, logged the AGNSS data that QGNSS sends, and matched it to my function’s output. It is completely matched.
BTW, I use these links for the BDS EPO file:
http://wepodownload.mediatek.com/QBD2.DAT
My module version:
‘PQTMVER’, ‘MODULE_LC79HALNR01A02S’, ‘2022/09/27’, '17:02:51
77’
‘PQTMVER’, ‘SUB_V02*3A’
‘PAIR021’, ‘AG3335M_V2.4.0.AG3335.QT01_20220927’
I’ve written the function based on this datasheet:
“L89 R2.0&LC02H&LC29H&LC79H Series AGNSS Application Note”, Version: 1.1, Date: 2023-06-29

Does anybody know how to send it correctly?

Hi Dezdeepblue,

Did you test with Host EPO? Or Flash EPO?

If you test with Host EPO, you should wait for the module get fixed. After you query by PAIR470, it will reply like:
$PAIR470,3,0,0,0,0,0,2292,468000,2292,489600*33

And please pay attention PAIR470 queries EPO data of specific constellation. You need to input the system ID that you want to check.
image

Best regards.

Hi Raphael
Thank you for your reply.
As I said, I am testing Host EPO and I have read the related documents.
I’m not sure if I should wait for the module to get fixed and then query by PAIR470.
I already see the reply for query of EPO data of GPS, GLONASS, and Galileo right after I send the Host EPO file:
$PAIR470,0,0,0,0,0,0,2292,543600,2292,565200*39
$PAIR470,1,0,0,0,0,0,2292,543600,2292,565200*38
$PAIR470,2,0,0,0,0,0,2292,543600,2292,565200*3B
but for BDS it replies this:
$PAIR470,3,0,0,0,0,0,0,0,0,0*3A
which means it doesn’t acknowledge BDS Host EPO file.

BTW, although it doesn’t make sense to me, I queried again the EPO after the module acquired the fix, and surprisingly it acknowledges the BDS Host EPO:
$PAIR470,3,0,0,0,0,0,2292,536400,2292,558000*36

It doesn’t make sense to query Host BDS EPO after the fix, as the module requests BDS aiding periodically before. It does it even after I send the BDS Host EPO (before the fix, and when the query command replies this: $PAIR470,3,0,0,0,0,0,0,0,0,0*3A).
I’m still looking for a mistake, as in first place I’m sending the Host EPO file to aid the module to get the fix faster. It is useless if I should wait for the fix and then send the Host EPO file, right?

Hi @Raphael-Q
What else do you think may cause the module not to acknowledge BDS Host EPO and acknowledge others?
I am sending EPO file sections one by one and receiving ACK for each one. But after all BDS EPO frames are sent, if I query the module for BDS EPO data, it sends this: $PAIR470,3,0,0,0,0,0,0,0,0,0*3A
It even asks for BDS EPO data either every minute.
If you know anything else I should check please let me know

thank you in advance

Hi Dezdeepblue,

In Host EPO, only when EPO data is being used, PAIR470 will reply an available message. That means the EPO data is being used for positioning.

Best regards.