I need to inform me about an implementation of the AT + CSQ command for a Sim800L GSM module, landed in gsmutils / gsmctl.

The idea is to be able to know the signal level in some automatic way or rather, from a remote computer to the mounted system (sim800l conected to Beaglebone)

Finally I need a permanent signal monitoring without the need to disconnect gsm utils and have to connect by UART to use the AT commands

I have not used the Sim800L GSM module. But a decade ago I did use cell phone tethering as an internet connection. During that time I was familiar with accessing AT / Hays style commands used to get information from the phone. So I might be able to help you, If someone with Sim800L GSM comes along they would be more likely to help you, until then I could lend a hand.

From looking at pictures (not reading docs) It appears that the Sim800L GSM module is designed to work with single board computers such as the raspberry pi. For my piece of mind, does it use USB or some other bus. Even if simulated USB it will show up with the command "lsusb"

So you are using packaged software to access the Sim800L GSM module or are you trying to write your own software? Are you sending data over the connection using PPP?

It seems that you are trying to have two different programs access the GSM module at the same time. This can not be done if both programs access the GSM module directly through the serial link (Note1). The only way to have two programs access the GSM module at the same time is to use a library to act as a traffic cop. Many programs can use PPP at the same time because PPP is that traffic cop.

The idea is simple if one program tries to dial using "ATD9876543210" at the same time another program is trying to get a list of available baud rates "AT+IPR=?" the module might get "ATD987654AT+IPR=?3210" which is total garbage as far as the module is concerned.

In order to help you I will need to understand a bit more on how you are using the module? Are you only trying to monitor signal strength while PPP sends date over the GSM module? If so I would need to dig into the PPP documentation to see if it has the ability to play nicely with other programs. If you are not using PPP then studying PPP documentation would be a waste of time.

None1 : The device is in the /dev directory. The device urandom is serial
ls -l /dev/urandom yields.
"crw-rw-rw- 1 root root 1, 9 Dec 3 20:02 urandom"
The first character on the line is 'c'

In fact, I am using the GSM module connected to a BeagleBone Black card and I am also using PUTTY to communicate with it through UART. The connection is through the Micro USB input on the board and with USB to the computer. In addition, it is connected by ethernet.

My query is that if there is any way to generate a script or if there is a command in GSM Utils / GSM ctl by which you can access the signal level without having to do it through AT comands.

If the only thing you wish to do is continually monitor the signal strength with your setup, it seems the easiest thing to do, is just write a script that sends the AT command to the UART, then parse the results. The script should wait some time then repeat the process. It is possible that such a script exist. I would try Google-ing queries such as "monitoring 3G signal strength Linux" might try 4G and GSM in the place of 3G. If you know the /dev device that you are using with PUTTY, you can use any program to send/receive the same date from the UART.

The only problem is the above process monopolizes the UART. Such a script would not allow you to conduct any other business using the Sim800L GSM module, until you kill the script

If you do try to create a script that monitors the GSM signal continuously using the AT commands, I would you look into the python implement of the "expect" framework. The module for python that implements expect is called "pexpect". Writing a script that require two-way communication over a single channel can be tricky. The expect framework makes some of the complications easier to navigate.

Sorry for not explaining myself well, what I need is that from the command line of PUTTY, to write a command that calls the command AT + CSQ without the need to have a program type screen or similar (I do not need to be necessarily continuous, I only need access for when I deem it convenient from the command line)

Up u.u

Sorry for the delay, I was gone and was hoping that someone else could jump in and take this up for you.

For the sake of context I am calling the BeagleBone Black card a computer. From an engineering point of view it only makes since to call it a computer. Programs run on the BeagleBone and it manages it's own communications. You are basically sitting in front of your laptop/desktop and accessing a remote computer using putty. In terms of raw processing power, the BeagleBone Black exceeds many of the computers that ran early versions of Windows.

As I said, I don't have the module, so I can't test this. The first thing I would try is just sending the command straight from the BeagleBone to the Sim800L. The Sim800L is a peripheral of the BeagleBone and if it was identified correctly, it should appear in the BeagleBone's /dev directory. I don't know where it appears to the /dev directory, but for the sake of this example, I'm going to call it /dev/GSM (If you don't know how to find the /dev then say so).

The first try is to simply run minicom on the BeagleBone to communicate with the Sim800L. I have assumed from the beginning that you have already done this. Maybe I was wrong in assuming this. If you need to know how to do this, reply back to get help.

Once it is known that you can communicate with the Sim800L, you can try sending the commands to the Sim800L by using other means. What happens when you try.

Note: the /dev/GSM must be substitute for the real /dev entry.

I'm so sure echo/cat is the right way to go. This method could be very fragile and could easily get stuck if something unexpected happens. I consider running "expect" on the BeagleBone as a way to communicate with the Sim800L, because "expect" is better at handling unexpected situations.