SIM7020E NB-Iot module does not respond to AT commands - raspberry-pi

I am using a RPi Pico, a NB-IoT SIM7020E Module from Waveshare and a Twilio Super SIM card. I fitted the Raspberry Pi Pico into the SIM7020E module using header pins: a picture of the setup is given through this link (Picture 1: Hardware setup).
To send different AT commands to configure the modem and set up the APN, I used Micro Python and copy pasted the Python code into Putty (after doing ctrl C, ctrl E and ctrl D to run the code). The main functions I utilised to send AT commands are “uart.write”, “uart.any” and “uart.read”. I have copy-pasted a portion of the code here:
#Send an AT command - just return the response
def send_at_get_resp(cmd, timeout=1000):
# Send the AT command
uart.write((cmd + "\r\n").encode())
# Read and return the response (until timeout)
return read_buffer(timeout)
#Read in the buffer by sampling the UART until timeout
def read_buffer(timeout):
buffer = bytes()
now = ticks_ms()
while (ticks_ms() - now) < timeout and len(buffer) < 1025:
if uart.any(): # check if there is anything to be read
buffer += uart.read(1) # read 1 characters, returns a bytes object
return buffer.decode()
#Send an AT command - return True if we got an expected otherwise False
def send_at(cmd, back="OK", timeout=1000):
# Send the command and get the response (until timeout)
buffer = send_at_get_resp(cmd, timeout)
if len(buffer) > 0:
return True
else:
return False
send_at("AT")
send_at("ATE1")
The issues I have with the code are that:
After sending an AT command (“AT” and “ATE1”), uart.read reads ‘b\x00’ and not the AT command. It looks like the SIM7020E module does not receive the AT command and does not respond to it (I should receive the response “OK”).
The “Read_buffer” function (see code below in picture 2) that reads the command in the buffer by sampling the UART returns an empty string.
Before sending the AT commands, I powered the module on and off to boot the modem using the Pin(14) of the SIM7020E module. When powered on, the module’s LED switches on so I know that my python code can communicate correctly and that the problem occurs for AT commands only.
Alternative 1:
I have tried typing AT commands ("AT" and "ATE1") directly on Putty (I did not hit Ctrl-C to break to the Python REPL), but I received an error message saying that Putty does not recognise the AT command (Picture 2: error with Putty)
Alternative 2:
I also tried using an AT command tester for Simcom modules from the website https://m2msupport.net/m2msupport/download-at-command-tester-for-simcom-modules/, but the software was unable to connect to the USB port (Picture 3: error from the AT command tester). It recognised the port but could not connect to it. The software asked me to try other baud rates and to enable flow control, so I tried all the possible different baud rates, and it did not work. For the flow control, I did not know how to configure it.
I do not understand why the module does not recognise the AT commands despite the other alternatives I tried and if it comes from a hardware or a software related problem. Do you know how I can make my module respond to AT commands?

It doesn't look like you are using the right serial interface in Putty. When you send your AT commands directly in Putty what is the COM5 port? It should be the COM port that shows up under the modem in the device manager.

Related

How can I send a particular NMEA command as part of the start-up configuration for gpsd?

The GPS hardware I'm using with my Raspberry Pi, if sent the command $CDCMD,33,1*7C, will report the status of the antenna connection.
I'd like this command to be issued whenever my GPS daemon starts. My current config file at /etc/default/gpsd looks like this:
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/serial0 /dev/pps0"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-n"
# Automatically hot add/remove USB GPS devices via gpsdctl
USBAUTO="false"
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"
Is there anything I can add to this config file to insert either the antenna command, or the path of a file containing the command?
I've searched all over for documentation for the config file, yet all I can find is example file, nothing that fully documents what options are available for configuration.
Alternatively, if the gpsd daemon is already up and running, and already has control of the serial port used to communicate with the GPS hardware, is there a way to send an NMEA command that gpsd will pass along to the hardware?
The only way I've been able to test this command was to shut down gpsd, then run minicom to issue the command to the hardware directly.

Is there a library for MSR605X that works with Raspberry Pi?

I have been trying to locate a working library for the MSR605X magnetic card reader/writer. At time of writing, I have tried five separate libraries. Only two of these were explicitly for the 605X the other three were for the older 605. All the libraries I have tried either did nothing at all or errored before completing a command (can't figure out the errors either).
I am running Raspberry Pi OS 32 bit on a Raspberry Pi 3 B+ the MSR605X communicates via a USB connection.
So far the library that seems to be most complete is: https://pypi.org/project/msrx/
However, I can not get this library to read or write (either nothing happens or I get a Serial exception "cannot reconfig port).
Any help or links to documentation for this reader is welcome.
EDIT: Adding the commands ran with the above library
msrx -D /dev/input/event4 read
msrx -D /dev/input/jso0 read
The -D is to specify the device path (default is /dev/ttyUSB0 which doesn't exist on my system). I obtained the above two paths by searching for USB serial devices then matching the search result to the device ID which I obtained from lsusb.
Running these commands results in a serial exception (could not reconfig port) which I assume means that I have the wrong device path. I have also checked for any tty* device paths that are changed when I plug in the reader. I consistently get a permission denied error whenever trying to run the above commands with a tty* device path (I am root on this system).
msrx author here — MSR605 requires an external 9V power injected into its cable (via the barrel jack port), otherwise it won't power up properly.

XDP offloaded mode flags set is not working with bcc

I'm trying to run this tutorial XDP code that is provided in the bcc.
The code I use is this script: bcc/examples/networking/xdp/xdp_drop_count.py.
and to my understanding, XDP flag works as follows (from that question):
#define XDP_FLAGS_SKB_MODE (1U << 1)
#define XDP_FLAGS_DRV_MODE (1U << 2)
#define XDP_FLAGS_HW_MODE (1U << 3)
So, doesn't this mean that if I change the flags bit to
flags |= 1 << 3
I should be able to run this code in hardware accelerated mode (offloaded)?
I have a NIC card that supports XDP HW accelerated mode and it works fine when I just attach a simple program with only one line of code:
return XDP_PASS;
and attach it in offloaded mode by using ip link set dev interface xdpoffload etc.
So I have confirmed my NIC is capable of loading an offloaded XDP program but when I try the above, it gives me an error:
bpf: Attaching prog to enp4s0np1: Invalid argumentTraceback (most recent call last) :
File "xdp_drop_count.py", line 132, in <module>
b. attach_xdp(device, fn, flags)
File "usr/lib/python2.7/dist-packages/bcc/__init__.py", line 723, in attach_xdp % (dev, errstr))
Exception : Failed to attach BPF to device enp4s0np1: No such file or directory
Also, when I set the flags to :
flags |= 1 << 2
I am not sure if this is actually running the XDP program in driver mode.
Am I missing something?
Thank you in advance.
If you build bcc from sources
Since commit d147588, bcc has hardware offload support. To offload programs using bcc, you will need three things:
The XDP_FLAGS_HW_MODE bit (1U << 3) should be set in the flags passed to attach_xdp().
The name of the interface to which you want to offload the program should be given to BPF() with the device= parameter. It will allow bcc to offload the maps to the appropriate device. It is unnecessary if you don't have maps.
The interface's name should also be given to load_func, again with parameter device=, such that bcc tells the kernel where to offload the program.
Note that, with the latest bcc sources, the xdp_drop_count.py script has been updated to do all this for you when you pass the -H option:
sudo ./xdp_drop_count.py -H $ETHNAME
For older versions of bcc
Older versions of bcc do not support hardware offload. You can use bpftool or ip (>v4.16) instead, e.g.:
sudo ip link set dev $ETHNAME xdpoffload obj prog.o sec .text
sudo bpftool prog load prog.o /sys/fs/bpf/prog type xdp dev $ETHNAME
For a BPF program to be attached as a XDP program, it needs to be offloaded to the NIC first, when being loaded on the system.
In your case, the b.load_func() provided by bcc does not support any option for offloading programs when passing them to the kernel. So when you later call b.attach_xdp() with the XDP_FLAGS_HW_MODE, the function fails, because it cannot find any program offloaded on the NIC.
Right now there is no workaround for offloading program with bcc. As pchaigno mentioned, the function simply does not offer an option to indicate the program should be offloaded.
It should not be too difficult to add support for offloading programs to bcc though, so it should probably be available in the future (especially if pchaigno feels like adding it :p). You would still need to replace the per-CPU array by a regular array in your program, as the former is not supported for offload at this time.
Regarding the mode in which your programs run, this is something you can check with bpftool net for example.

How do I get Robotframework (in Eclipse) to respond to terminal prompt

I'm currently running Robotframework in Eclipse on Windows 10 OS. I'm using an external python library that allows students and teachers to use this extracted library to connect to our hardware devices. I'm automating the extractions from the main site package made by our developers. If more than one device is plugged into the USB ports on the PC, then the code does the following:
x = input("Select one device:")
selected = int(x)
This causes a terminal prompt so the user has to type in a 0, or 1 for example, then hit the ENTER key. User response will allow the code to further process a connect to the selected device. Note, this prompt is not a GUI. So when I run Robotframework, it will execute the steps up to the point where it's prompting.
It seems like this should be pretty easy, but I can't seem to figure it out. Since you're inside a piece of code that's waiting for input, how do you make RobotFramework do something with it?
Edit: It occurs to me that maybe there's a way to execute a delayed Robotframework step that starts an external python command after a specified time, to throw a '0' and a RETURN key response. I had a python file made from an import of pynput.py library which appears to work from the command line execution (prints a 0, or a 1, and a return line feed). There's gotta be an easier way I'd think, but I don't know what it is.
Edit: Can I run a keyword from a listener that watches for the command prompt and the keyword runs another python file to feed the prompt? If I get this to work, then all I have to do is leave the devices on the USB port (or hub for that matter), and select the devices I want to do further testing on. Our devices are supported Blooth tooth as well but I need to run both USB and BLE tests to verify our Python extractions the teachers and students can use.
Edit: The other option is to use a software programmable hub and select the USB with a specific device on it, but I'm trying to avoid that.
OK, I solved it using Robotframework background process. I wrote a small python file that gets executed from the process. It has a 5 second timer (more than I need) and then Robotframework runs the next Test Case step. The Python file then does some keyboard presses, selecting the port and an ENTER key which goes out to the console (feeding the input prompt). It connects the sensor.
So in my Robotframework Test Case I do the following:
*** Test Case ***
smoke_test
Start process . Python . usbportselect
open usb
The Python program called from the process looks like this:
import time
import pynput
from pynput.keyboard import Key, Controller
keyboard = Controller()
def choose_usb(portvalue)
keyboard.press(portvalue)
keyboard.release(portvalue)
keyboard.press(Key.enter)
keyboard.release(Key.enter)
time.sleep(5)
choose_usb('0')
Note: I'm pretty sure this won't fix all the problems with using processes, but it's at least a start and a way to feed input to a prompt resulted from a future Test Case step

VLC MPTS streaming

I'm trying to stream MPEG-TS using VLC as UDP Multicast. I have a recorded file with several programs. I need receive each program on my output as single program TS.
I do it with console interface in ubuntu 14.04 and I have a problem. I cannot get on my output any program except the first one.
cvlc MyMPTS.ts --sout '#duplicate{dst=udp{mux=ts,dst=239.233.1.1:5510},select="program=1"}' -
this command works well, but if I try adding another program to chain or I change my program number to another I got a following output:
[0x7ff748c93c38] main decoder error: cannot create packetizer output (mpga)
[0x7ff748c8c168] main decoder error: cannot create packetizer output (mpgv)
And there is nothing on output
If I stream using GUI it works well. I can select any program in my MPTS and get it on output, I can launch several windows of VLC and setup streaming with different programs as well. But GUI doesn't work in my case.
Why vlc cannot work with programs except the first defined from source file
Using you command I get:
[00007fa880008b38] stream_out_standard stream out error: UDP output is only valid with TS mux
[00007fa880008b38] stream_out_standard stream out error: no suitable sout mux module for `udp/‌​ts://...'
This seems to be fixed by removing the mux=ts from dst=udp:
cvlc input.ts --sout '#duplicate{dst=udp{dst=...},select="program=94",dst=udp{dst=...},select="program=102"}'
It will still complain about mpga and mpgv but it will start sending mpeg-ts over UDP. No idea what it doesn't like though, maybe something to do with muxer selection.