OZZMAKER SARA-R5 serial port issues

[Alex Babij]

Hi, I have the SARA-R5 LTE-M GPS + 10DOF with an external GPS antenna which I have mostly working, but I have some issues I am still trying to work out.
The accuracy and time to fix is slower than I was hoping, although that may just have to do with the conditions where I am. (not sure if there is a way to tell if it is using the external GPS antenna or if it just will use whatever is attached to the u.fl) If I give it clear sky access and let it use AssistNow Online, it gets a fix pretty fast and the location is mostly accurate. If I open up the GNSS stream on /dev/ttyGSM3 one of the strings has a bunch of weird characters in front of it(pic attached), although I am not sure if that matters or not.

The first issue I am having is that I will frequently get the error ‘minicom: cannot open /dev/ttyGSM3: Device or resource busy’ when I try to access the gps data stream with the command ‘minicom 115200 -D /dev/ttyGSM3’.
If I wait long enough it will eventually work, but there will be no gps data, and if I open /dev/ttyGSM2 or 1, I can no longer input AT commands. I am assuming this is from some kind of issue with the serial connection but I have no idea how to fix it/what is going on.

The second issue I am having is if I run ‘sudo reboot’ to restart the raspberry pi, multiplex channels disappear, but the ‘cmux’ command stops working and returns the error ‘cmux: Cannot read /dev/serial0: Resource temporarily unavailable’ I am able to open the serial connection with ‘minicom 115200 -D /dev/serial0’, but it just outputs a bunch of random characters. (pic attached)
My guess is that it has to do with the gps staying powered on, since if I power cycle the raspberry pi and the gps it fixes the issue until I try to reboot again. Im not sure why its putting out random characters to the serial0 channel, I read that that can be a baud rate issue but I have no idea here.

Attachments:

1. 

   agps-serial-3.jpg
   

2. 

   serial0-after-reboot.jpg
   

[Mark Williams]

Hi Alex

If you dont enable the mux and cold boot the Pi and the SARA-R5, do you get random characters when connecting to Serial0?

In the second scenario, after the reboot… if you get garbage on serial0, can you try and connect the pin highlighted below to ground for 1 second. this will reset the SARA-R5. Then run CMUX again.

Mark --OzzMaker.com --

[Alex Babij]

Thanks for the reply, disabling the mux and cold booting the whole system, I can enter serial0 and it works as expected, can send commands and get gps data from it, no garbage characters.

Using sudo reboot, then resetting the SARA-R5 by connecting to ground lets me run CMUX again and it works as expected.

I am still having the issue where after entering cgps or gpsmon, the serial connection through minicom becomes unresponsive. If I enter ttyGSM3, no data comes out, and if I enter ttyGSM1 or ttyGSM2 I am no longer able to type anything, and even exiting minicom with ctrl+A, Q becomes laggy.

[Mark Williams]

we should be able to update the cmux program so that it can workout if the SARA-R5 is in CMUX mode…  ill get back to you on this.

There other issue is strange.  There is a little delay when accessing or leaving the virtual serials, but it should <1 second, this is normal.
What Pi are you using?
Is it overclocked?
Do you have anything else attached or running?

Mark --OzzMaker.com --

[Alex Babij]

I am using a raspberry pi 3a+, not overclocked, ssh into it so no display out or keyboard, only thing connected is the SARA-R5 and I am not running extra software on there, just the terminal. In terms of delay, it is usually <1 second to exit minicom, but when I get that error it will take 5+ seconds to give me the option to exit. I’ll try a bunch of different combinations of cellular on/off inside vs sky access, etc. to see if that changes things.

I have been using the python scripts from the gps and agps tutorials which I tweaked for python3 to set the gps parameters, but I have the same issue with the serial connection occur when setting them manually. The python script for the cellular connection can be a bit finicky and will sometimes return ‘ERROR’ when running: ‘AT+CGACT=1,1’, ‘AT+UPSD=0,0,0’, and ‘AT+UPSD=0,100,1’ . My guess is its still trying to establish a cellular connection and thats why it fails, since if I wait long enough and run those AT commands they will eventually work, although I’m not really sure, since if I run ‘AT+CGDCONT?’ I will get back an IP address but still have those 3 commands fail.

[Alex Babij]

From my testing so far, it seems that either using the cellular assisted gps mode or cgps is what is causing the serial port issues. If I turn off the cellular radio and dont go through any of the config, it is able eventually able to get a fix unassisted and doesn’t have any issues with the serial port. gpsmon works fine and I can go back and forth between that and ttyGSM3 without issue. After maybe 20 minutes of running I went into cgps, it didn’t seem to get any gps data (no text lines refreshing below the gui), and then at that point the serial connection broke and I had the same issue as before: no data into cgps or gpsmon, cant type in ttyGSM2, and ttyGSM1, etc.

Using assisted mode and manually going through the cellular setup commands until I am able to successfully ping google.com before turning on the gps, I am amble to get a fix within a minute or two as expected. Entering gpsmon only, then exiting it and trying to access ttyGSM3 gives the device or resource busy error. If I keep trying to access it, ttyGSM3 will eventually open, but won’t show any data, and reentering gpsmon after this point will make it fail to recognize the gps and nothing will work until a restart of the raspberry pi + gps/ a cold boot. (pic attached)

I dont think its an issue with the raspberry pi itself, since it remains responsive even when minicom/ the serial connection stuff starts breaking. It doesn’t seem to be overheating or anything like that, its cold enough outside where I am that it stays barely warm to the touch when its outside. Conversely when its inside and warms up more I still have the same issues.

Another thing I am seeing is when I have some of those cellular commands for PDP and IPV4 fail it shows up in the hologram dashboard as a “session without data”. Im thinking that may be the cause of the issues with the cellular commands, but in terms of how/if that could affect the serial connection I have no idea.

Attachments:

1. 

   gpsmon-error.jpg
   

[Mark Williams]

Hi Alex, sorry for the late reply.  how are you going with this?   Do you see the same issues if you run gpsmon only  and not cgps?

Mark --OzzMaker.com --

[Alex Babij]

Yeah still having the same issues unfortunately, I do get the same issues to occur with gpsmon only, and I will also get the same error “device or resource busy” just based on time. I had the gps module and PI powered on, but made sure that the GPS itself was “off” with ‘AT+UGPS?” returning 0, didnt run gpsmon or cgps, etc. After waiting long enough I would eventually still get the same “device or resource busy” error on ttyGSM3, although I could still send commands and get responses back like normal in ttyGSM1. If I kept trying to enter ttyGSM3 with minicom, it would eventually work, but I would get no data in there (as expected since gps is off). I didn’t disable gpsd during this, so that may be the reason for getting the “device or resource busy” error, but that doesn’t seem to be the cause of the serial connection becoming unresponsive.

Another thing I tried was after having the channels eventually becoming unresponsive after using gpsmon, I ran ‘sudo killall gpsd’ then tried to enter ttyGSM3 with minicom. That did actually work, but it would show completely random characters, unlike other instances in my previous posts where they would be mostly correct strings with the first line of a new batch of strings having some random characters at the front of it.

[Alex Babij]

Just as a further update: I decided to just start over, I did a clean install of the raspberry pi os, reformatted the SD card and then went through the setup like normal. When I got to the part of the setup where you run ‘minicom 115200 -D /dev/serial0’, I got the same “device or resource busy” error for the channel serial0 (gps module had been powered on for ~6 minutes by that point). Power cycling everything fixed this issue. Continuing on by setting up multiplexing then running the gps:
When running the module in assisted gps mode with ‘AT+UGPS=1,4,67’ (gpsd, cgps, gpsmon is still not installed at this point), I get correct NMEA strings with garbage data at the front of it in the same position every time a new set of strings gets sent (pic attached). After sitting in ttyGSM3 in minicom for a while with these errors, exiting the channel and then trying to immediately re-enter it resulted in ttyGSM3 outputting no data, and ttyGSM1 and 2 becoming unresponsive, requiring a restart to fix it. From my research, it seems like the random characters could be either just a signal integrity issue with the serial connection, or the module trying to send UBX binary messages with the NMEA strings. https://stackoverflow.com/questions/55831738/ublox-gps-strange-characters-interspersed-with-nmea-output
I don’t have the same garbage characters appear in ttyGSM3 with unassisted gps mode ‘AT+UGPS=1,1,67’, despite having the cellular radio enabled and connected as if I was going to use the assisted gps mode.

At this point, I hadn’t installed gpsd yet, so I’m thinking that the issue might be with the GPS module instead? I don’t really know what else could be the problem at this point. The gps module clearly has some settings that are persistent between power cycles because the cellular radio will automatically turn itself on on powerup, which it didn’t originally do, and also it says in the documentation that it saves certain settings between power cycles. I haven’t tried updating the firmware on the gps or resetting to factory defaults, which I guess would be the next thing to try, not sure what your thoughts on any of that are.

As a side note, I could never get cat or screen to work to connect to the serial0 channel, even with the correct baud rate of 115200. Running either cat or screen would just make the SSH terminal unresponsive. Not sure if this is an actual issue or just a quirk of the module.

Attachments:

1. 

   garbage-chars-agps1467.jpg
   

[mechtech]

Alex, I am new to the board and I am having issues getting the multiplexing working and I saw you mentioned you did get it working. My issue is there is no n_gsm.ko file but there is a n_gsm.o file.

I am is a raspberry pi OS 64bit fresh as of a few days ago on rpi 3b+, any ideas?

[Alex Babij]

Weird, I am pretty new to raspberry pi stuff so I don’t really know. I am assuming all of the previous steps worked for you? I had to install python 2.7 when I did a fresh install to be able to do some of the multiplexing setup. If you do ‘sudo -i’ then ‘cd /root/linux/drivers/tty’, then ‘ls’, what shows up in the list of files? (pic attached of what mine looks like)

Attachments:

1. 

   n_gsm-kernel.jpg
   

[mechtech]

Yeah had to install python2.7 has well. As I found issues I commented about them in this thread https://ozzmaker.com/forums/topic/post-here-for-support-on-the-ozzmaker-sara-r5-lte-m-gps-10dof/ You will see there is another file that is not found while trying to run the make command, /root/linux/drivers/tty/serial/sc16is7xx.ko. From what I have recently read about the make command, I believe that is the command that makes the n_gps.ko file, and with the sc16is7xx.ko missing, I am blocked.

[richardp]

Hi Alex
To me, it looks like it isnt random rubbish (problem with serial line) as the characters always appear in the same place. Maybe it is UBX messages.

Is echo disabled on the serial interface?
stty -F /dev/serial0 -a

You can try and reset the GPS using this command from /dev/ttyGSM2
AT+UGUBX="b56206040400ffff02000e61"

If this doesnt work, please send an email to sales @ ozzmaker

Richard --OzzMaker.com --

[Alex Babij]

My reply wouldn’t post, Im guessing because I put links in it, so here it is with the pictures just attached.
Thanks for the reply, I believe the serial interface is disabled since I did that step during setup. Here is the output of ‘stty -F /dev/serial0 -a’ (pic attached). Resetting the GPS with ‘AT+UGUBX=”b56206040400ffff02000e61″‘ didn’t work unfortunately. The command did successfully run, picture of output: (pic attached) (same result in ttyGSM2). I tried it a couple times, doing a power cycle after each time, but after configuring the cellular connection again and going through all that, same result unfortunately: Still random characters in the NMEA strings the same as my previous attached pictures. After exiting gpsmon and trying to enter ttyGSM1 or 2 after having the gps run for a few minutes results in the serial channel ends up becoming unresponsive, and reentering gpsmon makes it no longer display data, same as before.

I opened up a second ssh terminal and monitored the resource usage as I was running the gps with the ‘top’ command. The cpu usage went up when running the python scripts which I think is normal, but when just using the minicom channels, running gpsmon, etc. the cpu usage was around 2%: (pic attached)

Part of whats so frustrating is that its so inconsistent. If I start the gps with ‘AT+UGPS=1,4,67’ (or some other combination of gps systems i.e. 71 instead of 67), enter gpsmon, then exit it and enter ttyGSM1 or 2, I can still send commands and get responses back, but if I wait 1-3 minutes, it doing the same things results in the channel becoming unresponsive: can’t type in it, and becomes laggy when trying to quit out of minicom, and restarting gpsmon will result in it having no data, all with pi cpu usage staying around ~2% or so. If I stay in gpsmon it will continue to print NMEA strings and try to get a fix for as long as I keep it open, but closing it results in the above issues.

After sending ‘AT+UGPS=1,4,71’ and entering gpsmon I get the following for the first few seconds after launching (pic attached), then back to only NMEA strings. Not 100% sure but I think gpsd tries to filter out what it considers garbage data i.e. not NMEA strings, so it may still be that those are UBX messages or something in that specific case. Attached are pictures of the output from ttyGSM3, then the result of running gpsmon right after: attached below

Attachments:

1. 

   echo-disabled-on-serial-interface.jpg
   

2. 

   succesful-reset.jpg
   

3. 

   resource-usage-top.jpg
   

4. 

   1_4_71-ttyGSM3.jpg
   

5. 

   gpsmon-first-launch.jpg
   

[Alex Babij]

Just tried leaving it running gpsmon for like an hour, same thing as in my other recent reply, gpsmon is fine until I exit, then serial channel freezes up and gpsmon stops getting data.

[Author]

Posts