Assistance Requested for Configuring ubxlib for LEAN_R8 on Linux

[IssamSayyaf]

Hello,

I hope this message finds you well.

I am reaching out to seek your guidance on configuring the ubxlib library for use with the LEAN_R8 device on a Linux operating system. I have successfully cloned the repository and identified the specific components I need within the UBXLIB_FEATURES section of the linux.cmake file.

Following this, I executed the cmake command to configure the build environment and subsequently ran the test program, which performed as expected. However, my primary objective is to ensure that the compiled library is fully compatible with the LEAN_R8 device, which connects via USB and communicates using the Point-to-Point Protocol (PPP).

Could you please advise on the steps necessary to instruct the cmake build system to target the LEAN_R8 device specifically? My aim is to ensure seamless communication over USB with PPP protocol support.
and if there are any examples of this.

I appreciate your time and look forward to your expert advice.

[RobMeades]

Hi there, and thanks for posting. The problem you'll have is that we don't currently have a PPP-level integration into Linux with LENA-R8, only with ESP-IDF [plus Zephyr with some provisos] and with SARA-R5 or SARA-R422.

That said, I can take a look at how difficult it would be to do a PPP-level integration with Linux; I know that on Windows it would involve signed drivers, which would be difficult, but with Linux we should be able to use pppd. I will also need to check on the status of PPP with LENA-R8. Will get back to you.

[IssamSayyaf]

Okay, thank you very much, I am looking forward to hearing from you soon.
Thank you in advance for your help and support.

[IssamSayyaf]

I have a question, could you tell me how can I run it using UART without PPP now, and when the new update is ready I can move to it?
how can I adjust the Flags to tell it the number of /dev/ttyUSBX and specify the LENA_R8.

Thank you in advance

[RobMeades]

Certainly: in the uDeviceCfg_t structure you pass to uDeviceOpen() you would set the moduleType field of uDeviceCfgCell_t to U_CELL_MODULE_TYPE_LENA_R8; you could also set it to U_CELL_MODULE_TYPE_ANY and ubxlib will read the module type and set it for you but it is slightly quicker to set the proper module type yourself.

To tell Linux the correct serial port to use with the module, if, say, you were using /dev/ttyUSB5 then in the uDeviceCfg_t structure you pass to uDeviceOpen() you would set the uart field of uDeviceCfgUart_t to 5 and the pPrefix field to /dev/ttyUSB.

You can see how we configure this structure in the examples, e.g. this one which runs PPP from ESP-IDF; a Linux version might look similar.

[RobMeades]

Hi again. I have pushed a preview branch that contains support for PPP on LENA-R8 and also support for PPP with Linux here:

https://github.com/u-blox/ubxlib/tree/preview_ppp_linux_lena_r8_rmea

Details about how to make it happen can be found in the Linux platform README.md and you will find example code here. A few things to note:

• There seems to be a limitation with LENA-R8 that, once a PPP connection is running, any other AT-command-based activity that needs to send data to the network using the clients on-board the LENA-R8 (i.e. things like using the ubxlib function to look up a DNS address, using ubxlib MQTT or HTTP, using a ubxlib socket) will fail. This is currently preventing me checking the code in as such simultaneous operations are something we specifically test for ubxlib. I am trying to find out if there is any way around this; I imagine you won't mind, as I guess you will do all of those things from Linux natively once PPP is up; if there is no way around it I will need to modify our tests to match for LENA-R8.
• Running/configuring pppd can be quite complex. especially as most things connected with it seem to be considered a security risk. In our test system we have the pppd executable setuid (so that non-root users can run it and it will assume root privileges when it needs to) and we configure it with noauth (since no cellular module is going to ever be able to authenticate itself to pppd). You will need to decide on your approach to such matters.

Please give it a try and let me know if it works for you. If you confirm that it works I will merge the support for PPP with Linux and, once I've sorted out what it is doing, the support for PPP with LENA-R8, into master here and will delete the preview branch some time after that.

[IssamSayyaf]

Okay, Thank you very much. I will test it and come back to you thank you very much.

[RobMeades]

FYI, branch updated to handle the case where pppd disappears without ubxlib knowing about it; probably wouldn't be an issue for your testing.

[RobMeades]

We've now had time to test this pretty thoroughly ourselves and so it is pushed here, see commits ac08677 and f62f008; if you just take head revision you should be fine.

If that works for you please close this issue, otherwise let us know how we can help.

[IssamSayyaf]

to be honest not yey, I moved to another task, and I have to check and test everything related to LTE the next week. Of course, I will check everything.
I would like to thank you for your great support and help. Thank you very much.

[RobMeades]

NP: I shall delete the preview branch, please just work from a refresh of master and let us know if you have problems with it.

[IssamSayyaf]

Great news, okay of course thank you very much

[IssamSayyaf]

Hello,

I would like to thank you, I build it and I understand how I should choose the LEAN and the connection port and I have all the library as .o

I need some support, how can in the end build the final application and connect all of this library, moreover, I want to make the library work on an ARM processor.
how can I generate the elf file? this is my question
now I have compiled everything I have all the library.o, and for example, I want to test my board using this main_ppp_linux.c
however how can I generate the elf file and apply the cross-compiling?

Thank you in advance.

this is my modification
static const uDeviceCfg_t gDeviceCfg = {
.deviceType = U_DEVICE_TYPE_CELL,
.deviceCfg = {
.cfgCell = {
.moduleType = U_CELL_MODULE_TYPE_LENA_R8,
.pSimPinCode = NULL, /* SIM pin */
.pinEnablePower = U_CFG_APP_PIN_CELL_ENABLE_POWER,
.pinPwrOn = U_CFG_APP_PIN_CELL_PWR_ON,
.pinVInt = U_CFG_APP_PIN_CELL_VINT,
.pinDtrPowerSaving = U_CFG_APP_PIN_CELL_DTR
},
},
.transportType = U_DEVICE_TRANSPORT_TYPE_UART,
.transportCfg = {
.cfgUart = {
.uart = 5, // UART port number
.pPrefix = "/dev/ttyUSB" // Prefix for the device file
.baudRate = U_CELL_UART_BAUD_RATE,
.pinTxd = U_CFG_APP_PIN_CELL_TXD,
.pinRxd = U_CFG_APP_PIN_CELL_RXD,
.pinCts = U_CFG_APP_PIN_CELL_CTS,
.pinRts = U_CFG_APP_PIN_CELL_RTS,
#ifdef U_CFG_APP_UART_PREFIX
.pPrefix = U_PORT_STRINGIFY_QUOTED(U_CFG_APP_UART_PREFIX) // Relevant for Linux only
#else
.pPrefix = NULL
#endif
},
},
};

[RobMeades]

I build it...

That's good news, well done!

how can in the end build the final application and connect all of this library

That kind of depends what you want your application to do. The example shows how to bring up a network connection and the section in the README.md of the Linux platform folder shows how to set up pppd so that the connection is visible to the Linux kernel. After that you should just be able to use connectivity from within Linux in the usual way, or make ubxlib API calls from the application that you have linked the ubxlib library into.

moreover, I want to make the library work on an ARM processor.

When you say "ARM processor", since you are talking of an .elf file, I guess you mean an MCU (like nRF52/nRF53, STM32, ESP32, that kind of thing). The answer will depend entirely on what the MCU is and what the SDK is. The MCU manufacturer will usually provide/support one or more SDKs and ubxlib supports some of those SDKs: for nRF52/nRF53 we support nRFConnect/Zephyr, for STM32F4 we support STM32Cube, for other STM32 flavours we support native Zephyr and for ESP32 we support ESP-IDF. You would choose one of these SDKs and then follow the instructions in the relevant ubxlib /port/platform/xxx folder to perform the build.

[IssamSayyaf]

Great, I want to run the application on ARM cortex A7 with Linux os. So the platform is Linux

target_link_libraries(YOUR_APPLICATION_NAME ubxlib ${UBXLIB_REQUIRED_LINK_LIBS}) target_include_directories(YOUR_APPLICATION_NAME PUBLIC ${UBXLIB_INC} ${UBXLIB_PUBLIC_INC_PORT})

So I need to add these two lines for the cmakelist.txt to compile my application and link it with ubloxlib

Is it right?

[RobMeades]

Taking a step back for a moment, just to align on terminology in case of misunderstandings.

Above you mention ".elf file and apply the cross-compiling"; cross-compiling means using a toolchain on machine (a) to build an executable file that will NOT run on machine (a) but will instead run on machine (b). The executable file created would usually be an .elf file, or possibly a .hex file or even a .bin file, machine (a) would usually be a Windows or Linux or Mac desktop machine and you would usually use some form of download/flash tool to move the .elf file to machine (b), where it would run. The reason for doing this is usually because machine (b) is an embedded MCU or some such, it is not a development environment, not a place where you would write code, and is not powerful enough to run a compiler, so you need a "special" toolchain (e.g. GCC ARM) running on a desktop machine to produce code for an entirely different processor to that where the compiler is running. This toolchain is different to the GCC you might already have on your Linux desktop, which only makes code that will run on that Linux desktop (compiling, as opposed to cross-compiling).

Above you also say "I want to run the application on ARM cortex A7 with Linux OS": given that you mentioned cross-compiling and a .elf file, I guess that this target machine is some form of embedded Linux and it has to be machine (b) because it is not sufficiently powerful to run a compiler itself, you need machine (a) to run the compiler.

So you will need something like GCC ARM, or whatever the suppliers of the "ARM cortex A7 with Linux OS" machine suggest, installed on your desktop machine, machine (a), and, after that, you would create a build environment that calls GCC-ARM (rather than the native GCC compiler for machine (a)) on the .c files of your application, plus the ubxlib files. If you are using CMake then yes, it would be pretty much as indicated, just make sure that the correct toolchain for the target machine is being called by the CMake files.

[IssamSayyaf]

Thank you very much,
I have built the example and a cmake I will share with you, but I still have a problem, with a cross-compiling problem Could you help me?
I will be thankful
just I want to build
This is the project containing "CMakeLists", issam_LTE.c issam_LTE.h
project.zip

[RobMeades]

OK: what is the problem?

[IssamSayyaf]

I think I discovered the problem there are problems with OpenSSL and libgpiod
I am trying to add it to gcc-arm to generate the file based on gcc-arm.

I will come back to you to tell you.

A huge thanks for your helping

[IssamSayyaf]

I am embarrassed too much could you give me an example of how can I build the issam_LTE.c using gcc-arm I tried too much, but I still have a lot of problems.

You mentioned this was tested by Raspberry how can I generate a file and test it on raspberry, should I build the system on raspberry pi.

Moreover if just can you just help me on this point would be great, how can I build the issam-lte,c using gcc-arm, as you mentioned I am working with embedded Linux, especially stm32mp1

[RobMeades]

Cross-compiling is a complex thing to do: for an embedded MCU, where everything is usually compiled from .c files in one go, i.e. there are no pre-compiled libraries, one can just get a flavour of GCC for the target MCU (e.g. GCC-ARM) and away you go, but if the target is a Linux machine and you need to include in your application third party libraries like OpenSSL and libgpiod then you will, of course, need to obtain and point your build at versions of those third party libraries that have been compiled for the target architecture, the thing you are cross-compiling to; this makes the process even more complex.

If the target is a kind of Raspberry Pi that runs Linux then, 10 years ago, I might have suggested that compiling for the Pi on a Windows or Linux desktop was necessary, since the Pi's back then were not so powerful, but these days a Raspberry Pi 3, 4 or 5 should be perfectly fine for compiling the relatively small application you have in mind, so I would go for compiling everything natively on the Raspberry Pi, no cross-compiling required.

Then you can just fetch the OpenSSL and GPIO libraries on that Raspberry Pi (I think the Pi already has these installed but if not libssl-dev and libgpiod-dev are probably what you want) and everything should work.

[IssamSayyaf]

Dear, thank you for all your support and great results, the software is working very well.
I built the example and ran it and I was able to connect, everything was fantastic. however, I think this will be the last question. during the run of the example I stacked at this point, you can guide me, or give me any hints. I will be thankful.

After creating a ppp connection and connecting with APN, the software started to enter into a loop and repeat the last 5 commands more and more. Do you know what is it the problem?

---

root@stm32mp1-hexabitzv2-mx:~/LTE_1/ubxlib/port/platform/linux/mcu/posix/runner/issam/build# ./issam_LTE
U_CELL: initialising with enable power pin not connected, PWR_ON pin not connected and VInt pin not connected.
AT

OK
AT

OK
U_CELL_PWR: powering on, module is already on.
ATE0

OK
AT+CMEE=2

OK
AT+UDCONF=1,0

OK
ATI9

02.00,A01.22

OK
AT&C1

OK
AT&D0

OK
AT&K0

OK
AT+UPSV=0

OK
AT+UGPRF?

+UGPRF:2,0,""

OK
AT+CFUN=4

OK

+CREG: 0,"0000","0000",0
U_PORT_PPP: listening for pppd on socket 127.0.0.1:5000.
Opened device with return code 0.
Br[ 812.650387] TCP: request_sock_TCP: Possible SYN flooding on port 5000. Sending cookies. Check SNMP counters.
inging up the network...
U_CELL_NET: preparing to register/connect...
AT+CREG=2

OK
AT+CGREG=2

OK
U_PORT_PPP: pppd has connected to socket.
AT+CEREG=4

OK
AT+CIMI

234502106062261

OK
AT+CIMI

234502106062261

OK
U_CELL_NET: APN from database is "jtm2m".
AT+CGDCONT=1,"IP","jtm2m"

OK
AT+UAUTHREQ=1,0,"",""

OK
AT+CGDCONT=2,"IP","jtm2m"

OK
U_CELL_NET: setting automatic network selection mode...
AT+COPS?

+COPS: 0

OK
AT+CFUN=1

OK
AT+CREG?

+CREG: 0,"0000","0000",0

OK
-1: NReg
AT+CGREG?

+CGREG: 2,0,"0000","0000"

OK
-1: NReg
AT+CEREG?

+CEREG: 4,0,"0000","00000000", 0,0,0,"00000000","00000000"

OK
-1: NReg
AT+CREG?

+CREG: 0,"0000","0000",0

OK
-1: NReg
AT+CGREG?

+CGREG: 2,0,"0000","0000"

[RobMeades]

This is normal: the cellular module is trying to connect to the cellular network, which may take some time (at least seconds and, on the first attempt in a location where the cellular module has not connected before, potentially minutes).

[IssamSayyaf]

Great! After 242 seconds, I have this message
Would you like me to do something special?

Thank you very much,

OK
-1: Deny
AT+CREG?

+CREG: 0,"1903","5f66",0

OK
-1: NReg
U_CELL_NET: unable to register with the network, is APN "jtm2m" correct and is an antenna connected?
AT+CEER

+CEER:No Error Call

OK
AT+CFUN=4

OK

+CREG: 0,"0000","0000",0
U_CELL_NET: connection attempt stopped after 242 second(s).
Unable to bring up the network!
Closing device...
-1: NReg
Segmentation fault (core dumped)

[RobMeades]

Can you post a bit more of the log, maybe include the whole log as an attachment? "Deny" means that some form of service has been denied by the cellular network but the exact form of that service is not clear as the Deny will be an interpretation of a URC (i.e. an unsolicited output from the module that conventionally begins with a +) which happened before the bit you have pasted in above. It could be that circuit-switched service has been denied but packet switched service is possible (in which case either there's a bug in our code or the timeout is real) or it could be that both circuit and packet switched service has been denied, in which case your SIM card has not been accepted on any visible cellular network.

EDIT: what SIM card are you using and have you been given an APN you must provide when using that SIM card (if so are you using that APN)?

Segmentation fault (core dumped) is, of course, unexpected, irrespective of whether you have achieved a connection or not; do you get any back-trace at that point?

[IssamSayyaf]

Okay, I will attach the log file. if can you take a look and tell me, what do you think the problem? I will be thankful for your help. You can find the file as an attachment.
Thank you in advance

+CREG: 0,"0000","0000",0
U_PORT_PPP: listening for pppd on socket 127.0.0.1:5000.
Opened device with return code 0.
Bringing up the network...
U_CELL_NET: preparing to register/connect...
U_PORT_PPP: pppd has connected to socket.
AT+CREG=2

OK
AT+CGREG=2

OK
AT+CEREG=4

OK
AT+CIMI

234502106062261

OK
AT+CIMI

234502106062261

OK
U_CELL_NET: APN from database is "jtm2m".
AT+CGDCONT=1,"IP","jtm2m"

OK
AT+UAUTHREQ=1,0,"",""

OK
AT+CGDCONT=2,"IP","jtm2m"

OK
U_CELL_NET: setting automatic network selection mode...
AT+COPS?

log_LTE.txt

[RobMeades]

Thanks: relatively quickly (about 1/3rd of the way into your log) the network is returning "denied" for both circuit-switched and packet-switched service:

+CREG: 3,"1903","5f66",0 [begins occurring at line 1324 out of 4186]
+CEREG: 4,3,"1903","5f660000", 0,0,20,"00000000","00000000" [begins occurring at line 1352 out of 4186]

So either (a) your SIM card is not valid or (b) you are not using the correct APN for your SIM card.

What SIM card are you using and were you given an APN to use with that SIM card?

[IssamSayyaf]

I used a mobile thing company
I have to change the APN.

https://www.thingsmobile.com/private/thingsmobile

[RobMeades]

Ah, yes, set the APN to "TM" and try again.

[IssamSayyaf]

Yeah I recognize the problem I will search how to modify the APN in the code
Thank you very much, sorry I am not too much expert on these things.

Thank you I will modify it

[RobMeades]

Obviously you will need to debug this to find out what would cause U_ERROR_COMMON_PLATFORM.

[IssamSayyaf]

I moved to implement this example it works, but it looks like uses the same port for LTE, in I brought up the LTE, and then I tried to move to GNSS, Everything was good however, there is an error

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

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

I don't know if it is the right way to start, could you recommend an example to start developing it to make LENA work?

log_GNSS.txt
gnss_code.txt

[IssamSayyaf]

I feel I am stuck, if you can help me I will be thankful

[IssamSayyaf]

without UART, use the same port I received message is not support, if you can guide me how can I make it run using UART I mean another port, I will be thankful

[RobMeades]

You can take that approach if you wish, but remember that it will not support "streamed" position from the GNSS device (i.e. none of the ubxlib location/GNSS APIs with Streamed in the name will work): calling uNetworkInterfaceUp() on the cellular device will indeed use the same transport as uDeviceOpen() created, either starting up CMUX to do so or, where CMUX is not supported [the LENA-R8 case], it will drop back to using AT+UGUBX commands, which are not able to support streamed position from the GNSS device (as AT commands only do "polled" kind of behaviours).

The reason you are getting "+CME ERROR: Operation not supported" is likely because of the GNSS system selection number used at the end of the AT+UGPS command: we set it to "all" and some GNSS-enabled-cellular modules then set all of the ones they support, ignoring ones they don't while other GNSS-enabled-cellular modules reject the number if it asks for GNSS system types that the GNSS chip inside the cellular module does not support. You can try setting U_CELL_LOC_GNSS_SYSTEM_TYPES to, say 3, for now, and see if that works.

[IssamSayyaf]

Now, it is working, without this error unsupporting, however, still have a problen.
Unable bring the GNSS
This my modification
// NETWORK configuration for GNSS
static const uNetworkCfgGnss_t gNetworkCfg = {
.type = U_NETWORK_TYPE_GNSS,
.moduleType = U_CELL_LOC_GNSS_SYSTEM_TYPES,
.devicePinPwr = -1, // The pins of the cellular module that are connected
.devicePinDataReady = -1 // to the GNSS chip's power and Data Ready lines
};

log_GNSS.txt

[RobMeades]

Ah, yes, I forget LENA-R8 does support CMUX, so the ubxlib code will try to use it, LENA-R8 just doesn't support access to the built-in GNSS chip over CMUX. For this case you should do a clean build with U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY defined and that will force ubxlib to only use AT commands to talk to the GNSS chip built into the cellular module.

[IssamSayyaf]

And if I want to have streaming, what should I do where should I move?

Because this will work on trucks so, I think the streaming will be important. Maybe latter, I will think about streaming but now for this what do you think the problem.

[RobMeades]

If you want streamed GNSS position then, as indicated above, you will need to debug why you were getting U_ERROR_COMMON_PLATFORM when you tried to call uDeviceOpen() for the GNSS device on the auxiliary UART.

[IssamSayyaf]

okay I will check latter, for the streaming.

Regarding this U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY , I didn't understand it.

[IssamSayyaf]

Could you tell me what should I do for this "U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY"

[RobMeades]

I mean that you should do a clean build with the conditional compilation flag U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY defined for the build.

[IssamSayyaf]

Ah okay, got it. I will do it.
Thank you very much

[IssamSayyaf]

I have an error :)
cc: warning: U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY: linker input file unused because linking not done
cc: error: U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY: linker input file not found: No such file or directory
make[2]: *** [CMakeFiles/ubxlib.dir/build.make:76: CMakeFiles/ubxlib.dir/home/root/LTE/ubxlib/common/at_client/src/u_at_client.c.o] Error 1
make[2]: *** Deleting file 'CMakeFiles/ubxlib.dir/home/root/LTE/ubxlib/common/at_client/src/u_at_client.c.o'
make[1]: *** [CMakeFiles/Makefile2:85: CMakeFiles/ubxlib.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

[RobMeades]

"linker input file not found: No such file or directory" is not an error I have ever seen or heard of I'm afraid. I would guess that you are not specifying the conditional compilation flag to your toolchain correctly...?

[IssamSayyaf]

it is like this
export U_FLAGS="-DU_CFG_PPP_ENABLE -DU_CELL_PRIVATE_PPP_CONTEXT_ID_LENA_R8=-1 -DU U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY"

[RobMeades]

-DU U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY doesn't look right to me...?

[IssamSayyaf]

I think I fix it

[IssamSayyaf]

it is the same

U_CELL: initialising with enable power pin not connected, PWR_ON pin not connected and VInt pin not connected.
AT

OK
AT

OK
U_CELL_PWR: powering on, module is already on.
ATE0

OK
AT+CMEE=2

OK
AT+UDCONF=1,0

OK
ATI9

02.00,A01.22

OK
AT&C1

OK
AT&D0

OK
AT&K0

OK
AT+UPSV=0

OK
AT+UGPRF?

+UGPRF:2,0,""

OK
AT+CFUN=4

OK
U_PORT_PPP: listening for pppd on socket 127.0.0.1:5000.
Opened cellular device with return code 0.
Bringing up GNSS...
U_PORT_PPP: pppd has connected to socket.
AT+CMUX=0,0,,128

OK
ATE0
ATE0

OK
AT+CMEE=2

OK
Unable to bring up GNSS!
U_PORT_PPP: pppd has been disconnected from socket.
U_PORT_PPP: no longer listening for pppd on socket.
Done.

[RobMeades]

Are you sure that was a clean build?

[IssamSayyaf]

Yeah I removed the directory and mkdir new one, then I export then cmake, the make.

I will try again

[RobMeades]

You can see the code here:

ubxlib/common/network/src/u_network_private_gnss.c

Lines 214 to 262 in a2d986e

	#ifndef U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY
	// Determine if CMUX and the GNSS channel are already enabled,
	pDeviceSerial = pUCellMuxChannelGetDeviceSerial(devHandle,
	U_CELL_MUX_CHANNEL_ID_GNSS);
	if (pDeviceSerial != NULL) {
	// All good, use what we have with discard on overflow set
	pDeviceSerial->discardOnOverflow(pDeviceSerial, true);
	gnssTransportHandle.pDeviceSerial = pDeviceSerial;
	gnssTransportType = U_GNSS_TRANSPORT_VIRTUAL_SERIAL;
	errorCode = (int32_t) U_ERROR_COMMON_SUCCESS;
	} else {
	if (upNotDown) {
	// If we're going up, try to enable CMUX and the GNSS channel
	// No need to worry about the flags above as all of these
	// functions do nothing if the thing is already there
	errorCode = uCellMuxEnable(devHandle);
	if (errorCode == 0) {
	// It is, good: make sure a GNSS channel is opeend
	errorCode = uCellMuxAddChannel(devHandle,
	U_CELL_MUX_CHANNEL_ID_GNSS,
	&pDeviceSerial);
	if (errorCode == 0) {
	// Set discard on overflow so that we aren't
	// overwhelmed by a stream of position data
	pDeviceSerial->discardOnOverflow(pDeviceSerial, true);
	// If we're on wake-up-on-data UART power saving and CMUX, switch
	// UART power saving off the GNSS stuff has no concept of waking
	// stuff up in that way.
	errorCode = uCellPwrDisableUartSleep(devHandle);
	if (errorCode == 0) {
	pNetworkContext->usingCmux = true;
	gnssTransportHandle.pDeviceSerial = pDeviceSerial;
	gnssTransportType = U_GNSS_TRANSPORT_VIRTUAL_SERIAL;
	}
	}
	}
	if (errorCode < 0) {
	// Tidy up on error
	if (!pNetworkContext->cellMuxAlreadyEnabled && !uCellPppIsOpen(devHandle)) {
	uCellMuxDisable(devHandle);
	}
	if ((pDeviceSerial != NULL) &&
	!pNetworkContext->cellMuxGnssChannelAlreadyEnabled) {
	uCellMuxRemoveChannel(devHandle, pDeviceSerial);
	}
	}
	}
	}
	#endif

If U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY is defined execution should never get to line 216. You can try putting a debug print there to see what is happening.

[IssamSayyaf]

I made like to told me
U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY is not define

so it doesn't define the Flag this how I export

Are there any problem
export U_FLAGS="-DU_CFG_PPP_ENABLE -DU_CELL_PRIVATE_PPP_CONTEXT_ID_LENA_R8=-1 -U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY"

[RobMeades]

export U_FLAGS="-DU_CFG_PPP_ENABLE -DU_CELL_PRIVATE_PPP_CONTEXT_ID_LENA_R8=-1 -U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY"

I think you are missing a D there.

[IssamSayyaf]

God! sorry for this stupid mistake.

Okay, it looks like is going on the right way, I still have a problem

'U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY is define
U_CELL: initialising with enable power pin not connected, PWR_ON pin not connected and VInt pin not connected.
AT

OK
AT

OK
U_CELL_PWR: powering on, module is already on.
ATE0

OK
AT+CMEE=2

OK
AT+UDCONF=1,0

OK
ATI9

02.00,A01.22

OK
AT&C1

OK
AT&D0

OK
AT&K0

OK
AT+UPSV=0

OK
AT+UGPRF?

+UGPRF:2,0,""

OK
AT+CFUN=4

OK
U_PORT_PPP: listening for pppd on socket 127.0.0.1:5000.
Opened cellular device with return code 0.
Bringing up GNSS...
Unable to bring up GNSS!
U_PORT_PPP: no longer listening for pppd on socket.
Done'

[RobMeades]

OK, so now you need to get into the flow of debug. Do you have a debugger in your setup or are you just planning to use debug prints? If the former then you can put a break-point here:

ubxlib/common/network/src/u_network_private_gnss.c

Line 339 in a2d986e

errorCode = uGnssPwrOn(devHandle);

...and from there step down into uGnssPwrOn() to see what is happening. If the latter then you can insert debug prints at that point and then within uGnssPwrOn() to find out the same thing.

Basically, get yourself set up for debugging and "do that thang", so to speak, as you would for any development.

[IssamSayyaf]

Okay Okay, I think it will be better to make a real debug, I will use gdb, and then I will let you know.

[IssamSayyaf]

Hello,
I hope everything is fine

I had some Hw problem I have solved, currently I am able to receive NMEA message from the GNSS, the boudrate is 38400, however, I am trying to run one of your example, I am facing some problem, could you advice me which example and how can I use your framwork to receive and control with the GNSS, thank you very much.

It is connected on /dev/ttySTM2, however, I always, have a problem with framwork could you help me.

[IssamSayyaf]

issam_LTE.txt
I am working on this, however I don't know what is the problem

[RobMeades]

Hi there: it is a bit difficult to know how to help without knowing what the problem is. Looking at the code you have attached, the field .pPrefix seems to be being initialised multiple times, which I'm surprised compiles:

            .pPrefix = "/dev/ttySTM", // Prefix for the device file   <<< THIS SEEMS CORRECT
	    .baudRate = 38400, /* Use 0 to try all possible baud rates and find the correct one. */
            .pinTxd = U_CFG_APP_PIN_GNSS_TXD,  // Use -1 if on Zephyr or Linux or Windows
            .pinRxd = U_CFG_APP_PIN_GNSS_RXD,  // Use -1 if on Zephyr or Linux or Windows
            .pinCts = U_CFG_APP_PIN_GNSS_CTS,  // Use -1 if on Zephyr
            .pinRts = U_CFG_APP_PIN_GNSS_RTS,  // Use -1 if on Zephyr
            //  <<< .pPrefix seems to be being initalised again, to what seem to be incorrect values, below >>>
#ifdef U_CFG_APP_UART_PREFIX
            .pPrefix = U_PORT_STRINGIFY_QUOTED(U_CFG_APP_UART_PREFIX) // Relevant for Linux only
#else
            .pPrefix = NULL
#endif