Git Product home page Git Product logo

Comments (21)

RobMeades avatar RobMeades commented on July 19, 2024

Hi, thanks for posting and sorry you're having trouble with this. Could you let us know what the return value from uNetworkInterfaceUp() for GNSS is?

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

Hello,
it is -10 (U_ERROR_COMMON_DEVICE_ERROR)

TX_GNSS is sending data-position correctly and Timepulse is giving pulse every second

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

Thanks; I'm not seeing the ubxlib AT log output in the logs you pasted in above, it should be on by default, pushed out over the same stream as you get the U_CELL_PWR: powering on, module is already on prints.

AT communications with the module must be happening or you wouldn't get as far as Opened cellular device with return code 0, and you don't seem to be switching it off, so I'm puzzled at to why it is not visible. During the uDeviceOpen() call it should appear on the log stream something like this (taken from one of our LENA-R8 test runs):

U_CELL_PWR: powering on.
U_AT_CLIENT_0-1: possible URC data readable 1, already buffered 0.
[00]U_AT_CLIENT_0-1: URC checking done.
AT
U_AT_CLIENT_0-1: AT error -10.
AT
U_AT_CLIENT_0-1: AT error -10.
AT
U_AT_CLIENT_0-1: AT error -10.
AT
U_AT_CLIENT_0-1: AT error -10.
AT
U_AT_CLIENT_0-1: timeout.
U_AT_CLIENT_0-1: AT error -10.
U_AT_CLIENT_0-1: AT error -10.
U_AT_CLIENT_0-1: stop tag not found.
AT
U_AT_CLIENT_0-1: AT error -10.
AT
OK
U_CELL_PWR: powering on, module is alive.
ATE0
OK
AT+CMEE=2
OK
AT+UDCONF=1,0
OK
ATI9
02.00,A01.40
OK
AT&C1
OK
AT&D0
OK
AT&K3
OK

Since LENA-R8 does not support access to the internal GNSS device via CMUX, so ubxlib will be talking to it via the AT+UGUBX AT commands and so I'd like to see what those are doing.

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

Here you is my actual logs output

*** Booting nRF Connect SDK v3.5.99-ncs1 ***
U_PORT_BOARD_CFG: using CELLULAR device "cfg-device-cellular" from the device tree, module-type 8 on UART 2, uart-baud-rate 115200 with pin-enable-power -1 (0xffffffff), pin-pwr-on 38 (0x26), pin-vint 39 (0x27), pin-dtr-power-saving -1 (0xffffffff).
U_CELL: initialising with enable power pin not connected, PWR_ON pin 38 (0x26) (and is toggled from 1 to 0) and VInt pin 39 (0x27) (and is 1 when module is on).
U_CELL_PWR: powering on.
AT
AT
AT
AT
AT

+UUSTATUS: READY
AT
AT

OK
ATE0

OK
AT+CMEE=2

OK
AT+UDCONF=1,0

OK
ATI9

02.00,A01.40

OK
AT&C1

OK
AT&D0

OK
AT&K0

OK
AT+UPSV=4,1300

OK
AT+CPSMS?

+CPSMS: 0,,,"10100100","00100100"

OK
AT+UGPRF?

+UGPRF:2,0,""

OK
AT+CFUN=4

OK
U_PORT_BOARD_CFG: using GNSS network configuration associated with CELLULAR device "cfg-device-cellular" from the device tree, GNSS module-type 3, device-pin-pwr -1, device-pin-data-ready -1.
AT+CMUX=0,0,,128

OK
ATE0

OK
AT+CMEE=2

OK
[00:00:08.056,915] main: Opened cellular device with return code 0.

[00:00:08.056,945] main: Bringing up GNSS...

U_GNSS: initialising with ENABLE_POWER pin not connected, transport type AT.
AT

OK
ATI

LENA-R8001M10-00C-00

OK
AT+UGIND=1

OK
AT+UGPS?

+UGPS: 0,0,0

OK
ATI

LENA-R8001M10-00C-00

OK
AT+UGPS=1,15,127

+CME ERROR: Operation not supported
AT

OK
AT+UGPS=1,15,127

+CME ERROR: Operation not supported
AT

OK
AT+UGPS=1,15,127

+CME ERROR: Operation not supported
U_CELL_PWR: powering off with AT command.
AT

OK
AT+UPSV=0

OK
AT+CPWROFF

+CPOF: MS OFF

OK
[00:00:46.116,516] main: Unable to bring up GNSS -10!

[00:00:48.530,273] main: Done.

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

Ah, that's better, thanks. The issue is this:

AT+UGPS=1,15,127
+CME ERROR: Operation not supported

The last parameter to AT+UGPS tells the cellular module which GNSS system types to enable in the built-in GNSS device. ubxlib asks for all of them and most of our modules simply set the ones they can and ignore ones they can't (sending a +UGIND URC to say what it has done). For some reason LENA-R8 doesn't do this and instead rejects the entire command and doesn't switch GNSS on.

To make this work for you, you will need to define U_CELL_LOC_GNSS_SYSTEM_TYPES when building ubxlib and set it to something that LENA-R8 is happy with, maybe just 1 (GPS) for now, to get it working.

I will make a note to find a more organised way to make LENA-R8 happy.

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

Hi Rob,
By modifing U_CELL_LOC_GNSS_SYSTEM_TYPES no changes happen on AT command, it sends still 127 , I had to change U_GNSS_PWR_SYSTEM_TYPES to get it to send 1 instead of 127

it still not working but has now a different error

+UUSTATUS: READY

OK
ATE0

OK
AT+CMEE=2

OK
AT+UDCONF=1,0

OK
ATI9

OK
AT&C1

02.00,A01.40

OK
AT&D0

OK
AT&K0

OK
AT+UPSV=4,1300

OK
AT+CPSMS?

OK
AT+UGPRF?

+CPSMS: 0,,,"10100100","00100100"

OK
AT+CFUN=4

+UGPRF:2,0,""

OK
U_PORT_BOARD_CFG: using GNSS network configuration associated with CELLULAR device "cfg-device-cellular" from the device tree, GNSS module-type 3, device-pin-pwr -1, device-pin-data-ready -1.

OK
AT+CMUX=0,0,,128

OK
ATE0

OK
AT+CMEE=2

OK
[00:00:12.508,911] main: Opened cellular device with return code 0.

[00:00:12.508,972] main: Bringing up GNSS...

U_GNSS: initialising with ENABLE_POWER pin not connected, transport type AT.
AT

OK
ATI

LENA-R8001M10-00C-00

OK
AT+UGIND=1

OK
AT+UGPS?

+UGPS: 0,0,0

OK
ATI

LENA-R8001M10-00C-00

OK
AT+UGPS=1,15,1

OK
AT+UGUBX="B5620A0400000E34"
U_GNSS: sent UBX command b5 62 0a 04 00 00 0e 34.

+UGUBX: "no message"

OK
U_GNSS_PWR: could not identify the module type.
U_CELL_PWR: powering off with AT command.
AT+UPSV=0

OK
AT+CPWROFF

+CPOF: MS OFF

OK
[00:00:19.555,480] main: Unable to bring up GNSS -24!

[00:00:21.917,327] main: Done.

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

Ah, sorry for misdirecting you.

U_GNSS: sent UBX command b5 62 0a 04 00 00 0e 34.
+UGUBX: "no message"
OK

ubxlib is sending the UBX command 0x0a 0x04, UBX-MON-VER, to find out the module type, which the GNSS device really is supposed to respond to, no message indicating that the cellular module has not got a response from it. Hmph.

You could try changing U_GNSS_MODULE_TYPE_ANY in your cfg-network-gnss-inside to be U_GNSS_MODULE_TYPE_M10; ubxlib will then not ask the GNSS device what type it is and move on to the next thing, we could see if it responds to that?

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

aah oke indeed this error message is no more displayed but now get still no location fix

U_GNSS: initializing with ENABLE_POWER pin not connected, transport type AT.
AT

OK
ATI

LENA-R8001M10-00C-00

OK
AT+UGIND=1

OK
AT+UGPS?

+UGPS: 0,0,0

OK
ATI

LENA-R8001M10-00C-00

OK
AT+UGPS=1,15,1

OK
AT+UGUBX="B562010700000819"
U_GNSS: sent UBX command b5 62 01 07 00 00 08 19.

+UGUBX: "no message"

OK
AT+UGPS=0

+UUGIND: 0,1

OK
U_CELL_PWR: powering off with AT command.
AT+UPSV=0

OK
AT+CPWROFF

+CPOF: MS OFF

OK
[00:00:18.420,166] main: Unable to get a location fix! [error = -11]

[00:00:18.420,196] main: Taking down GNSS...

[00:00:21.336,761] main: Done.

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

OK, so now the GNSS chip is not responding to the UBX command 0x01 0x07, UBX-NAV-PVT, the command which retrieves the position fix from it. Eh?

Can you give me some idea of the time intervals between the commands/responses? Compiling ubxlib with U_AT_CLIENT_PRINT_WITH_TIMESTAMP is an easy way to do that. Just wondering if LENA-R8 needs extra time for the GNSS device to power on or some such? In the meantime I will enquire internally with the people who know LENA-R8.

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

actually when I run it in debug mode then it gets the location fixed but when I run it in normal mode, it is not able to get the location fixed. it seems as u said , that needs some interval after powering gnss modem on.
so I added some delay before calling uLocationGet and then it starts to work

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

Interesting: my internal contact confirms that the procedure is correct. How much delay do you think seems to be required?

BTW, what HW are you using? Apparently pin 99 of the module needs to be supplied with 1.8V for the GNSS device to be powered, but I guess that is being supplied in your case?

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

for time-delay I just started with 5 sec , I didn't have chance to fine-tune it yet. But I hope to fix it without delay.
for the hardware I use the evk-8 of ublox (https://www.u-blox.com/en/product/evk-r8) I just connect this board to external mcu (nrf5340 dk) using Tx, Rx.

Here is the output logs without delay

U_PORT_BOARD_CFG: using GNSS network configuration associated with CELLULAR device "cfg-device-cellular" from the device tree, GNSS module-type 2, device-pin-pwr -1, device-pin-data-ready -1.
0000/01/01 00:00:11.764: AT+CMUX=0,0,,128
0000/01/01 00:00:11.820:
0000/01/01 00:00:11.822: OK
0000/01/01 00:00:12.460: ATE0
0000/01/01 00:00:12.514:
0000/01/01 00:00:12.516: OK
0000/01/01 00:00:12.540: AT+CMEE=2
0000/01/01 00:00:12.595:
0000/01/01 00:00:12.598: OK
[00:00:12.254,730] main: Opened cellular device with return code 0.

[00:00:12.254,760] main: Bringing up GNSS...

U_GNSS: initialising with ENABLE_POWER pin not connected, transport type AT.
0000/01/01 00:00:17.720: AT
0000/01/01 00:00:17.773:
0000/01/01 00:00:17.775: OK
0000/01/01 00:00:17.778: ATI
0000/01/01 00:00:17.832:
0000/01/01 00:00:17.834: LENA-R8001M10-00C-00
0000/01/01 00:00:17.838:
0000/01/01 00:00:17.841: OK
0000/01/01 00:00:17.865: AT+UGIND=1
0000/01/01 00:00:17.919:
0000/01/01 00:00:17.921: OK
0000/01/01 00:00:17.945: AT+UGPS?
0000/01/01 00:00:17.999:
0000/01/01 00:00:18.001: +UGPS: 0,0,0
0000/01/01 00:00:18.004:
0000/01/01 00:00:18.007: OK
0000/01/01 00:00:18.030: ATI
0000/01/01 00:00:18.083:
0000/01/01 00:00:18.086: LENA-R8001M10-00C-00
0000/01/01 00:00:18.090:
0000/01/01 00:00:18.092: OK
0000/01/01 00:00:18.596: AT+UGPS=1,15,1
0000/01/01 00:00:18.651:
0000/01/01 00:00:18.653: OK
0000/01/01 00:00:18.677: AT+UGUBX="B562010700000819"
U_GNSS: sent UBX command b5 62 01 07 00 00 08 19.
0000/01/01 00:00:18.729:
0000/01/01 00:00:18.731: +UGUBX: "no message"
0000/01/01 00:00:18.735:
0000/01/01 00:00:18.738: OK
0000/01/01 00:00:19.241: AT+UGPS=0
0000/01/01 00:00:19.255:
0000/01/01 00:00:19.257: +UUGIND: 0,1
0000/01/01 00:00:19.291:
0000/01/01 00:00:19.294: OK
U_CELL_PWR: powering off with AT command.
0000/01/01 00:00:19.401: AT+UPSV=0
0000/01/01 00:00:19.455:
0000/01/01 00:00:19.457: OK
0000/01/01 00:00:19.481: AT+CPWROFF
0000/01/01 00:00:19.555:
0000/01/01 00:00:19.558: +CPOF: MS OFF
0000/01/01 00:00:19.561:
0000/01/01 00:00:19.564: OK
[00:00:19.260,833] main: Unable to get a location fix -11

[00:00:19.260,864] main: Taking down GNSS...

[00:00:22.196,899] main: Done.

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

another question: is it possible to run the gnss module without need to cell-module, since the gnss module has its own power supply? in case not , what is the function of gnss-uart (tx_gnss, rx_gnss) ?

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

is it possible to run the gnss module without need to cell-module, since the gnss module has its own power supply?

From the integration manual, section 1.5.3.4:

The GNSS system integrated in the LENA-R8001M10 module can be operated fully independently from the cellular system integrated in the same module, but, as shown in Figure 2, the two systems are internally interconnected by dedicated I2C interface, allowing access to the GNSS system directly via the cellular system, which relays control messages to the GNSS system.

image

So I guess that's a "yes".

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

On your original question, I have pushed to a preview branch a proposed fix for the LENA-R8 system types and the LENA-R8 GNSS-power-on-delay LENA-R8 issues: would it be possible for you to try it?

If so, please:

(a) put the module type back to U_GNSS_MODULE_TYPE_ANY in your cfg-network-gnss-inside, leaving your override of the GNSS system types in place, and see if the GNSS device is now powered-up and recognised correctly,
(b) as a second step, also try removing your override of the GNSS system types, see if the revised setting in the new code fixes it.

Should either (a) or (b) fail, please post an AT log from power-on here and I'll get on it.

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

Hi Rob,

option (a)

U_PORT_BOARD_CFG: using CELLULAR device "cfg-device-cellular" from the device tree, module-type 8 on UART 2, uart-baud-rate 115200 with pin-enable-power -1 (0xffffffff), pin-pwr-on 38 (0x26), pin-vint 39 (0x27), pin-dtr-power-saving -1 (0xffffffff).
U_CELL: initialising with enable power pin not connected, PWR_ON pin 38 (0x26) (and is toggled from 1 to 0) and VInt pin 39 (0x27) (and is 1 when module is on).
0000/01/01 00:00:00.139: AT
0000/01/01 00:00:00.283: AT
0000/01/01 00:00:00.620: AT
0000/01/01 00:00:00.976: AT
0000/01/01 00:00:01.313: AT
0000/01/01 00:00:02.023:
0000/01/01 00:00:02.025: +UUSTATUS: READY
0000/01/01 00:00:04.333: AT
0000/01/01 00:00:04.386:
0000/01/01 00:00:04.388: OK
U_CELL_PWR: powering on, module is already on.
0000/01/01 00:00:04.416: ATE0
0000/01/01 00:00:04.469:
0000/01/01 00:00:04.472: OK
0000/01/01 00:00:04.505: AT+CMEE=2
0000/01/01 00:00:04.559:
0000/01/01 00:00:04.562: OK
0000/01/01 00:00:04.586: AT+UDCONF=1,0
0000/01/01 00:00:04.640:
0000/01/01 00:00:04.643: OK
0000/01/01 00:00:04.676: ATI9
0000/01/01 00:00:04.729:
0000/01/01 00:00:04.732: 02.00,A01.40
0000/01/01 00:00:04.735:
0000/01/01 00:00:04.738: OK
0000/01/01 00:00:04.761: AT&C1
0000/01/01 00:00:04.815:
0000/01/01 00:00:04.817: OK
0000/01/01 00:00:04.851: AT&D0
0000/01/01 00:00:04.904:
0000/01/01 00:00:04.907: OK
0000/01/01 00:00:04.930: AT&K0
0000/01/01 00:00:05.226:
0000/01/01 00:00:05.228: OK
0000/01/01 00:00:05.263: AT+UPSV=4,1300
0000/01/01 00:00:05.317:
0000/01/01 00:00:05.320: OK
0000/01/01 00:00:05.353: AT+UGPRF?
0000/01/01 00:00:05.407:
0000/01/01 00:00:05.410: +UGPRF:2,0,""
0000/01/01 00:00:05.413:
0000/01/01 00:00:05.416: OK
0000/01/01 00:00:05.439: AT+CFUN=4
0000/01/01 00:00:05.493:
0000/01/01 00:00:05.496: OK
U_PORT_BOARD_CFG: using GNSS network configuration associated with CELLULAR device "cfg-device-cellular" from the device tree, GNSS module-type 3, device-pin-pwr -1, device-pin-data-ready -1.
0000/01/01 00:00:05.529: AT+CMUX=0,0,,128
0000/01/01 00:00:05.584:
0000/01/01 00:00:05.586: OK
[00:00:05.759,033] main: Opened cellular device wit0000/01/01 00:00:06.504: ATE0h retur
n code 0.

[00:00:05.759,063] main: Bringing up GNSS...

0000/01/01 00:00:06.558:
0000/01/01 00:00:06.561: OK
0000/01/01 00:00:06.585: AT+CMEE=2
0000/01/01 00:00:06.640:
0000/01/01 00:00:06.643: OK
U_GNSS: initialising with ENABLE_POWER pin not connected, transport type AT.
0000/01/01 00:00:06.764: ATI
0000/01/01 00:00:06.818:
0000/01/01 00:00:06.820: LENA-R8001M10-00C-00
0000/01/01 00:00:06.824:
0000/01/01 00:00:06.827: OK
0000/01/01 00:00:06.850: AT+UGIND=1
0000/01/01 00:00:06.905:
0000/01/01 00:00:06.907: OK
0000/01/01 00:00:06.941: AT+UGPS?
0000/01/01 00:00:06.995:
0000/01/01 00:00:06.997: +UGPS: 0,0,0
0000/01/01 00:00:07.000:
0000/01/01 00:00:07.003: OK
0000/01/01 00:00:07.036: ATI
0000/01/01 00:00:07.090:
0000/01/01 00:00:07.092: LENA-R8001M10-00C-00
0000/01/01 00:00:07.096:
0000/01/01 00:00:07.099: OK
0000/01/01 00:00:07.122: AT+UGPS=1,15,1
0000/01/01 00:00:07.177:
0000/01/01 00:00:07.180: OK
0000/01/01 00:00:07.683: AT+UGUBX="B5620A0400000E34"
U_GNSS: sent command b5 62 0a 04 00 00 0e 34.
0000/01/01 00:00:07.846:
0000/01/01 00:00:07.848: +UGUBX: "B5620A04A000524F4D2053504720352E31302028376232303265290000000000000000003030304130303030000046575645523D53504720352E31300000000000000000000000000000000050524F545645523D33342E313000000000000000000000000000000000000/01/01 00:00:07.890: 0004750533B474C4F3B47414C3B424453000000000000000000000000000000534241533B515A5353000000000000000000000000000000000000000000F714"
0000/01/01 00:00:07.904:
0000/01/01 00:00:07.906: OK
0000/01/01 00:00:07.909:
0000/01/01 00:00:07.911: +UUGIND: 0,1
U_GNSS: decoded UBX response 0x0a 0x04: 52 4f 4d 20 53 50 47 20 35 2e 31 30 20 28 37 62 32 30 32 65 29 00 00 00 00 00 00 00 00 00 30 30 30 41 30 30 30 30 00 00 46 57 56 45 52 3d 53 50 47 20 35 2e 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 52 4f 54 56 45 52 3d 33 34 2e 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47 50 53 3b 47 4c 4f 3b 47 41 4c 3b 42 44 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 42 41 53 3b 51 5a 53 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 160 byte(s)].
U_GNSS_PWR: identified module type: 2
0000/01/01 00:00:08.030: AT+UGUBX="B562010700000819"
U_GNSS: sent command b5 62 01 07 00 00 08 19.
0000/01/01 00:00:08.353:
0000/01/01 00:00:08.356: +UGUBX: "B56205010200068A98C1"
0000/01/01 00:00:08.361:
0000/01/01 00:00:08.363: OK
0000/01/01 00:00:08.366:
0000/01/01 00:00:08.368: +UUGIND: 1,9
0000/01/01 00:00:08.372:
0000/01/01 00:00:08.374: +UUGIND: 8,9
0000/01/01 00:00:08.378:
0000/01/01 00:00:08.380: +UUGIND: 2,2
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
0000/01/01 00:00:08.892: AT+UGPS?
0000/01/01 00:00:08.946:
0000/01/01 00:00:08.949: +UGPS: 1,15,1
0000/01/01 00:00:08.952:
0000/01/01 00:00:08.955: OK
0000/01/01 00:00:08.978: AT+UGPS=0
0000/01/01 00:00:09.032:
0000/01/01 00:00:09.035: OK
U_CELL_PWR: powering off with AT command.
0000/01/01 00:00:09.142: AT+UPSV=0
0000/01/01 00:00:09.196:
0000/01/01 00:00:09.199: OK
0000/01/01 00:00:09.233: AT+CPWROFF
0000/01/01 00:00:09.307:
0000/01/01 00:00:09.309: +CPOF: MS OFF
0000/01/01 00:00:09.313:
0000/01/01 00:00:09.315: OK
[00:00:08.651,977] main: Unable to get a location fix -10

[00:00:08.652,038] main: Taking down GNSS...

option b:
U_PORT_BOARD_CFG: using CELLULAR device "cfg-device-cellular" from the device tree, module-type 8 on UART 2, uart-baud-rate 115200 with pin-enable-power -1 (0xffffffff), pin-pwr-on 38 (0x26), pin-vint 39 (0x27), pin-dtr-power-saving -1 (0xffffffff).
U_CELL: initialising with enable power pin not connected, PWR_ON pin 38 (0x26) (and is toggled from 1 to 0) and VInt pin 39 (0x27) (and is 1 when module is on).
0000/01/01 00:00:00.139: AT
0000/01/01 00:00:00.284: AT
0000/01/01 00:00:00.630: AT
0000/01/01 00:00:00.977: AT
0000/01/01 00:00:01.323: AT
0000/01/01 00:00:04.337: AT
0000/01/01 00:00:04.451: AT
0000/01/01 00:00:04.797: AT
0000/01/01 00:00:05.134: AT
0000/01/01 00:00:05.491: AT
0000/01/01 00:00:08.504: AT
0000/01/01 00:00:08.608: AT
0000/01/01 00:00:08.965: AT
0000/01/01 00:00:09.311: AT
0000/01/01 00:00:09.658: AT
0000/01/01 00:00:09.943: [ff]0000/01/01 00:00:12.757: AT
0000/01/01 00:00:12.901: AT
0000/01/01 00:00:13.248: AT
0000/01/01 00:00:13.493:
0000/01/01 00:00:13.496: +UUSTATUS: READY
0000/01/01 00:00:13.499:
0000/01/01 00:00:13.502: OK
U_CELL_PWR: powering on, module is already on.
0000/01/01 00:00:13.531:
0000/01/01 00:00:13.533: OK
0000/01/01 00:00:13.648: ATE0
0000/01/01 00:00:13.701:
0000/01/01 00:00:13.704: OK
0000/01/01 00:00:13.737: AT+CMEE=2
0000/01/01 00:00:13.791:
0000/01/01 00:00:13.794: OK
0000/01/01 00:00:13.818: AT+UDCONF=1,0
0000/01/01 00:00:13.872:
0000/01/01 00:00:13.874: OK
0000/01/01 00:00:13.908: ATI9
0000/01/01 00:00:13.961:
0000/01/01 00:00:13.964: 02.00,A01.40
0000/01/01 00:00:13.967:
0000/01/01 00:00:13.970: OK
0000/01/01 00:00:13.993: AT&C1
0000/01/01 00:00:14.047:
0000/01/01 00:00:14.049: OK
0000/01/01 00:00:14.083: AT&D0
0000/01/01 00:00:14.136:
0000/01/01 00:00:14.139: OK
0000/01/01 00:00:14.172: AT&K0
0000/01/01 00:00:14.387:
0000/01/01 00:00:14.390: OK
0000/01/01 00:00:14.414: AT+UPSV=4,1300
0000/01/01 00:00:14.468:
0000/01/01 00:00:14.471: OK
0000/01/01 00:00:14.494: AT+UGPRF?
0000/01/01 00:00:14.548:
0000/01/01 00:00:14.551: +UGPRF:2,0,""
0000/01/01 00:00:14.554:
0000/01/01 00:00:14.557: OK
0000/01/01 00:00:14.580: AT+CFUN=4
0000/01/01 00:00:14.634:
0000/01/01 00:00:14.637: OK
U_PORT_BOARD_CFG: using GNSS network configuration associated with CELLULAR device "cfg-device-cellular" from the device tree, GNSS module-type 3, device-pin-pwr -1, device-pin-data-ready -1.
0000/01/01 00:00:14.670: AT+CMUX=0,0,,128
0000/01/01 00:00:14.725:
0000/01/01 00:00:14.728: OK
[00:00:15.034,088] main: Opened cellular device with0000/01/01 00:00:15.645: ATE0 return
code 0.

[00:00:15.034,118] main: Bringing up GNSS...

0000/01/01 00:00:15.699:
0000/01/01 00:00:15.702: OK
0000/01/01 00:00:15.736: AT+CMEE=2
0000/01/01 00:00:15.791:
0000/01/01 00:00:15.794: OK
U_GNSS: initialising with ENABLE_POWER pin not connected, transport type AT.
0000/01/01 00:00:15.915: ATI
0000/01/01 00:00:15.969:
0000/01/01 00:00:15.971: LENA-R8001M10-00C-00
0000/01/01 00:00:15.975:
0000/01/01 00:00:15.978: OK
0000/01/01 00:00:16.012: AT+UGIND=1
0000/01/01 00:00:16.066:
0000/01/01 00:00:16.068: OK
0000/01/01 00:00:16.102: AT+UGPS?
0000/01/01 00:00:16.156:
0000/01/01 00:00:16.158: +UGPS: 0,0,0
0000/01/01 00:00:16.162:
0000/01/01 00:00:16.164: OK
0000/01/01 00:00:16.198: ATI
0000/01/01 00:00:16.251:
0000/01/01 00:00:16.253: LENA-R8001M10-00C-00
0000/01/01 00:00:16.258:
0000/01/01 00:00:16.260: OK
0000/01/01 00:00:16.294: AT+UGPS=1,15,127
0000/01/01 00:00:16.349:
0000/01/01 00:00:16.352: +CME ERROR: Operation not supported
0000/01/01 00:00:26.858: AT
0000/01/01 00:00:26.911:
0000/01/01 00:00:26.913: OK
0000/01/01 00:00:26.917: AT+UGPS=1,15,127
0000/01/01 00:00:26.972:
0000/01/01 00:00:26.975: +CME ERROR: Operation not supported
0000/01/01 00:00:37.481: AT
0000/01/01 00:00:37.534:
0000/01/01 00:00:37.536: OK
0000/01/01 00:00:37.540: AT+UGPS=1,15,127
0000/01/01 00:00:37.595:
0000/01/01 00:00:37.598: +CME ERROR: Operation not supported
U_CELL_PWR: powering off with AT command.
0000/01/01 00:00:48.208: AT
0000/01/01 00:00:48.261:
0000/01/01 00:00:48.263: OK
0000/01/01 00:00:48.267: AT+UPSV=0
0000/01/01 00:00:48.321:
0000/01/01 00:00:48.323: OK
0000/01/01 00:00:48.357: AT+CPWROFF
0000/01/01 00:00:48.431:
0000/01/01 00:00:48.434: +CPOF: MS OFF
0000/01/01 00:00:48.437:
0000/01/01 00:00:48.440: OK
[00:00:48.497,955] main: Unable to bring up GNSS -10!

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

Well, that is annoyingly inconclusive. In (a) the problem didn't occur in the first place: the module was responsive and was correctly identified immediately:

0000/01/01 00:00:07.683: AT+UGUBX="B5620A0400000E34"
U_GNSS: sent command b5 62 0a 04 00 00 0e 34.
0000/01/01 00:00:07.846:
0000/01/01 00:00:07.848: +UGUBX: "B5620A04A000524F4D2053504720352E31302028376232303265290000000000000000003030304130303030000046575645523D53504720352E31300000000000000000000000000000000050524F545645523D33342E313000000000000000000000000000000000000/01/01 00:00:07.890: 0004750533B474C4F3B47414C3B424453000000000000000000000000000000534241533B515A5353000000000000000000000000000000000000000000F714"
0000/01/01 00:00:07.904:
0000/01/01 00:00:07.906: OK
0000/01/01 00:00:07.909:
0000/01/01 00:00:07.911: +UUGIND: 0,1
U_GNSS: decoded UBX response 0x0a 0x04: 52 4f 4d 20 53 50 47 20 35 2e 31 30 20 28 37 62 32 30 32 65 29 00 00 00 00 00 00 00 00 00 30 30 30 41 30 30 30 30 00 00 46 57 56 45 52 3d 53 50 47 20 35 2e 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 52 4f 54 56 45 52 3d 33 34 2e 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47 50 53 3b 47 4c 4f 3b 47 41 4c 3b 42 44 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 42 41 53 3b 51 5a 53 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 160 byte(s)].
U_GNSS_PWR: identified module type: 2

The issue, instead, is that the UPOS entity within the cellular module is itself ALSO talking to the GNSS device, at the same time as you are talking to the GNSS device over the AT interface. ubxlib sends the UBX-NAV-PVT location request:

0000/01/01 00:00:08.030: AT+UGUBX="B562010700000819"

...but the answer it gets back is:

 0000/01/01 00:00:08.356: +UGUBX: "B56205010200068A98C1"

...which is an Ack for a UBX-CFG-VALSET (0x06 0x8A) command that we never sent; definitely not the response to the uLocationGet() command. This problem does not occur when the CMUX/tunneled method of talking to the internal GNSS chip is used but LENA-R8 does not support that, the only way is the "ping-pong"-style AT+UGUBX AT command and the cellular module has no way of keeping track of which entity asked which thing, it just blindly sends the UBX command and returns, as a response, the very next thing it gets from the GNSS device. There is nothing ubxlib can do to mitigate this.

Unfortunately, the UPOS entity within the cellular module will always talk to the internal GNSS module at start of day, there is no way to stop it. It is possible to minimise the time for which this might occur by setting the assistance types to none (i.e. override U_GNSS_AIDING_TYPES to zero) and then calling uLocationGet() in a loop until you do receive a location, or give up.

On (b), the change I thought I had made appears not to have done anything, the GNSS system types are still being requested as 127 when I was expecting to see 295; I will investigate what is going on there and update the preview branch when I have a better answer.

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

I have updated the preview branch to:

  1. rebase it on 7590200 (the fix for #242),
  2. modify the fix for setting the GNSS system types in the AT+UGPS command so that it works for LENA-R8: I was puzzled as to why you had to change U_GNSS_PWR_SYSTEM_TYPES instead of U_CELL_LOC_GNSS_SYSTEM_TYPES; this was because the mechanism for setting cellular-module-specific GNSS system types only worked for cellular modules that supported CMUX-access to the built-in GNSS chip, it did not work for the LENA-R8xxxM10 case, which is the only cellular module where the old AT+UGUBX mechanism is the sole way to access the built-in GNSS chip.

To summarise:

  • with the revised preview branch the built-in GNSS module of LENA-R8xxxM10 should, I hope, now always switch on: if you have time please give it a try,
  • the issue seen in the "option (a)" log you pasted above is, unfortunately, not something that ubxlib can do anything about: it can be minimised by setting the assistance types to none (i.e. override U_GNSS_AIDING_TYPES to zero) and by calling uLocationGet() in a loop until you do receive a location (or give up trying).

from ubxlib.

mos216 avatar mos216 commented on July 19, 2024

Hi Rob,
Many thanks for the update now it works indeed without need to set U_GNSS_PWR_SYSTEM_TYPE externally. only the issue as you described still with getting the location fixed, it still more time than expected. My intend finally is not to use GNSS as part of CELL device but as an independent GNSS device to satisfy our application requirement. I will give it try as independent gnss module and come back to you in case there are issues

from ubxlib.

RobMeades avatar RobMeades commented on July 19, 2024

I will give it try as independent gnss module and come back to you in case there are issues

That makes sense: you should be able to just use it with uDeviceOpen() as a UART-connected GNSS device and it should work. Let us know if it does not for any reason. Will close this issue now.

from ubxlib.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.