Can not read data from uart with micropython and SIM7070G NB on ESP32 controller - uart

I try to get my SIM7070G Cat-M/NB-IoT/GPRS HAT running with micropython on a ESP32 MC via UART. Unfortunately I did not find any libraries but I thought this can not be too difficult with micropython. I am working on this problem now for 3 days and do not get any response when sending commands with uart.
USB with computer:
Sending AT commands gives an answer like sending AT and receiving OK.
Micropython:
from machine import UART
from time import sleep
sleep(1)
print("activate")
p = Pin(27, Pin.OUT, Pin.PULL_UP)
sleep(0.1)
p.on()
sleep(1)
p.off()
sleep(0.5)
print("activated")
uart = UART(1, 115200,rx=9,tx=10,timeout=5000)
#uart.init(9600, bits=8, parity=None,rx=25,tx=26,stop=1)
uart.write(b'AT\r\n')
print("uart.write(b'AT\r\n')")
sleep(1)
data = uart.any()
print(str(data))
I just do not get a response. data is always 0.
What I tried:
checked connection 100 times, TX->RX and RX->TX, 5V, GND, PWR
different pins did not work
different baudrate... no difference.
Anyone a solution? That would be really great.
Link to manufacturer of SIM7070G HAT

I figured out the solution. As #hcheung sais, I have to call AT command a few times (up until 10 times) to let the module get the baudrate. It will work than properly.

Related

STM32 Ethernet UDP Problems

Good work everyone,
I am communicating with the STM32F746 processor using the lwip library. I got the ethernet buffers in the special area of ​​the RAM and protected it with the MPU. Then I disabled the buffering feature. My code works as I want, but after 10-15 minutes communication is cut off. My grounding, my connections, everything looks good.
I left the mpu protection as default (0x30000000).
I wrote the following in the flash.ld file
. = ABSOLUTE(0x20010000);
*(.RxDecripSection)
. = ABSOLUTE(0x20010080);
*(.TxDecripSection)
. = ABSOLUTE(0x20010100);
*(.RxArraySection)
. = ABSOLUTE(0x200118D0);
*(.TxArraySection)
I set memory region from ethernetif.c file. But the result is still the same. My connection drops after 10 minutes.

BG95 Can't Activate - AT+QIACT=1 returning error

I'm trying to get a BG95 to activate on hologram.
Here are my commands:
AT+QCFG="band",F,180A,180A OK
AT+QCFG="iotopmode",2 OK
AT+QCFG="nwscanseq",020301 OK
AT+QCFG="nwscanmode",0 OK
AT+QCFG="snrscan",0 OK
AT+QICSGP=1,1,"hologram","","",1 OK
AT+QIACT=1 ERROR
At first I thought it was antenna/signal related so I ran AT+CSQ and got this:
+csq: 11,99
This tells me I have a good signal I believe.
Next I tried AT+QNWINFO and get this:
+QNWINFO: "eMTC","311480","LTE BAND 13",5230
In my mind this is saying it's connected to a network.
After trying that I tried to activate again and got this:
AT+QIACT=1
ERROR
The weird thing is it activated just fine about a week ago with pure AT commands. I did try and use an Arduino library with it (WisLTEBG96TCPIP) which may have changed a setting in it. I've done a factory reset but the it still woln't activate.
Another strange thing is the hologram dashboard. Every once and a while it will show the SIM as connected, even though I can't activate.
I have tried with 2 different SIM cards any get the same activation error.
Any help would be greatly appreciated!
Verizon has cut off all non ODI products. If your hardware has not been Verizon ODI 'certified' it will no longer be allow to be connected to their network, I have 5 new pet rocks thanks to them. The solution is to purchase new modems from vendors that have been through the Verizon ODI program or switch carriers.
I had the same problem before, after a lot of maling with network operator I find out that there isn't a LTE-CAT-M1 (eMTC) network in my area, I tested in another area successfully
Also before setting AT+QCFG commands try AT+CFUN = 0
and after setting AT+QCFG commands try AT+CFUN = 1 .
before sending AT+QIACT, try 'AT+CEREG?' command several times and tell me what is the return of it

Openthread CLI UDP communication from main.c (NRF52840)

We are working with NRF52840 dongles and want to be able to have them relay data over an OpenThread mesh network through UDP automatically. We have found within the OpenThread API a solid Udp.h library with all the Udp functions we need to create code that runs on the dongles from the main.c.
Below is our code that should broadcast the message: "Hallo" to all nodes that have an open socket on port 1994.
We have read that the ipv6 address ff03::1 is reserved for multicast UDP broadcasting and it works perfectly when manually performed with the CLI udp commands.
CLI: Udp open, udp send ff03::1 1994 Hallo
With all the nodes that have udp open, udp bind :: 1994, receiving the Hallo message from the sending node.
We are trying to recreate this in the main.c of our nodes so that we can provide the nodes with some intelligence of their own.
This piece of code is run once when the push button on the dongle is pressed.
The code compiles perfectly and we have tested the functions that have a return with the RGB led (green OK, red not) to confirm that there weren't any errors produced (sadly not all functions return a no_error value)
void udpSend(){
const char *buf = "Hallo";
otMessageInfo messageInfo;
otInstance *myInstance;
myInstance = thread_ot_instance_get();
otUdpSocket mySocket;
memset(&messageInfo, 0, sizeof(messageInfo));
// messageInfo.mPeerAddr = otIp6GetUnicastAddresses(myInstance)->mNext->mNext->mAddress;
otIp6AddressFromString("ff03::1", &messageInfo.mPeerAddr);
messageInfo.mPeerPort = 1994;
messageInfo.mInterfaceId = OT_NETIF_INTERFACE_ID_THREAD;
otUdpOpen(myInstance, &mySocket, NULL, NULL);
otMessage *test_Message = otUdpNewMessage(myInstance, NULL);
otMessageSetLength(test_Message, sizeof(buf));
if (otMessageAppend(test_Message, &buf, sizeof(buf)) == OT_ERROR_NONE){
nrf_gpio_pin_write(LED2_G, 0);
}
else{
nrf_gpio_pin_write(LED2_R, 0);
}
otUdpSend(&mySocket, test_Message, &messageInfo);
otCliUartOutputFormat("Done.\0");
otUdpClose(&mySocket);
}
Now, we aren't exactly experts, so we are not sure why this isn't working as we had a lot of trouble figuring out how everything is called/initialised.
We hope to create a way to send and receive data through UDP through the code, so that they can operate autonomously.
We would really appreciate it if someone could assist us with our project!
Thanks!
Jonathan
There are a few errors in your code:
Remove the call to otMessageSetLength(). The message length is automatically increased as part of otMessageAppend().
The call to otMessageAppend() should be: otMessageAppend(test_message, buf, (uint16_t)strlen(buf)).
Removed the & before buf.
Replaced sizeof() with strlen().
Couple other things you should consider:
After calling otUdpNewMessage(), if any following call returns an error, make sure to call otMessageFree() on the message buffer.
Custody is only given to OpenThread after a successful call to otUdpSend().
Do not call udpSend() from interrupt context.
OpenThread library was designed to assume a single thread of execution.
Hope that helps.

Receive data from host computer using Circuit Python on Circuit Playground Express

I am using a Circuit Playground Express from Adafruit, and I'm programming it with Circuit Python.
I want to read data transmitted from the computer to which the Circuit Playground Express is connected via USB. Using input() works fine, but I would rather get the buffer of the serial instead, so that the loop would go on while there's no input. Something like serial.read().
import serial does not work on Circuit Python, or maybe I must install something. Is there anything else I could do to read the serial buffer using Circuit Python?
Aiden's answer lead me in the right direction and I found a nice (and slightly different) example of how to use supervisor.runtime.serial_bytes_available from Adafruit here (specifically lines 89-95): https://learn.adafruit.com/AT-Hand-Raiser/circuitpython-code
A minimum working example for code.py that takes the input and formats a new string in the form "RX: string" is
import supervisor
print("listening...")
while True:
if supervisor.runtime.serial_bytes_available:
value = input().strip()
# Sometimes Windows sends an extra (or missing) newline - ignore them
if value == "":
continue
print("RX: {}".format(value))
Tested on: Adafruit CircuitPython 4.1.0 on 2019-08-02; Adafruit ItsyBitsy M0 Express with samd21g18. Messages sent using the serial connection in mu-editor on macOS.
Sample output
main.py output:
listening...
hello!
RX: hello!
I got a simple example to work based on above posts, not sure how stable or useful it is, but still posting it here:
CircuitPython Code:
import supervisor
while True:
if supervisor.runtime.serial_bytes_available:
value = input().strip()
print(f"Received: {value}\r")
PC Code
import time
import serial
ser = serial.Serial('COM6', 115200) # open serial port
command = b'hello\n\r'
print(f"Sending Command: [{command}]")
ser.write(command) # write a string
ended = False
reply = b''
for _ in range(len(command)):
a = ser.read() # Read the loopback chars and ignore
while True:
a = ser.read()
if a== b'\r':
break
else:
reply += a
time.sleep(0.01)
print(f"Reply was: [{reply}]")
ser.close()
c:\circuitpythontest>python TEST1.PY
Sending Command: [b'hello\n\r']
Reply was: [b'Received: hello']
This is now somewhat possible!
In the January stable release of CircuitPython 3.1.2 the function serial_bytes_available was added to the supervisor module.
This allows you to poll the availability of serial bytes.
For example in the CircuitPython firmware (i.e. boot.py) a serial echo example would be:
import supervisor
def serial_read():
if supervisor.runtime.serial_bytes_available():
value = input()
print(value)
and ensure when you create the serial device object on the host side you set the timeout wait to be very small (i.e. 0.01).
i.e in python:
import serial
ser = serial.Serial(
'/dev/ttyACM0',
baudrate=115200,
timeout=0.01)
ser.write(b'HELLO from CircuitPython\n')
x = ser.readlines()
print("received: {}".format(x))

Bluetooth Serial between Raspberry Pi 3 / Zero W and Arduino / HM-10

I am trying to establish a bluetooth serial communication link between a Raspberry Pi Zero W, running Raspbian Jessie [03-07-2017], and an Arduino (UNO).
I am currently able to write data to the Arduino using bluetoothctl.
The application requires that we are able to write data to a particular BLE Slave. There are multiple [HM-10] Slaves to switch between, the Slave needs to be chosen during the program execution.
There is no BAUD rate preference. Currently, we are using 9600 universally.
Functions have been created that automatically connect and then write data to an "attribute", this shows up as data on the Serial Monitor of the Arduino.
Python Code - using BlueZ 5.44 (manually installed):
import subprocess
from subprocess import Popen, PIPE
# Replaces the ':' with '_' to allow the MacAddress to be in the form
# of a "Path" when "selecting an attribute"
def changeMacAddr(word):
return ''.join(c if c != ':' else '_' for c in word)
# Connects to a given MacAddress and then selects the attribute to write to
def connBT(BTsubProcess, stringMacAddr):
BTsubProcess.stdin.write(bytes("".join("connect "+stringMacAddr +"\n"), "utf-8"))
BTsubProcess.stdin.flush()
time.sleep(2)
stringFormat = changeMacAddr(stringMacAddr)
BTsubProcess.stdin.write(bytes("".join("select-attribute /org/bluez/hci0/dev_"
+ stringFormat +
"/service0010/char0011" + "\n"), "utf-8"))
BTsubProcess.stdin.flush()
# Can only be run once connBT has run - writes the data in a list [must have numbers 0 - 255 ]
def writeBT(BTsubProcess, listOfData):
stringList = [str('{0} ').format(elem) for elem in listOfData]
BTsubProcess.stdin.write(bytes("".join("write " + "".join(stringList) + "\n"), "utf-8"))
BTsubProcess.stdin.flush()
# Disconnects
def clostBT(BTsubProcess):
BTsubProcess.communicate(bytes("disconnect\n", "utf-8"))
# To use the functions a subprocess "instance" of bluetoothctl must be made
blt = subprocess.Popen(["bluetoothctl"], stdin=subprocess.PIPE, shell=True)
# blt with then be passed into the function for BTsubProcess
# Note: the MacAddresses of the Bluetooth modules were pre-connected and trusted manually via bluetoothctl
This method works fine for small sets of data, but my requirements require me to stream data to the Arduino very quickly.
The current set up is:
Sensor data (accelerometer, EEG) via USB serial is received by the Pi
The Pi processes the data
Commands are then sent to the Arduino via the in built bluetooth of the Pi Zero W
However, while using this method the bluetooth data transmission would delay (temporarily freeze) when the sensor data changed.
The data transmission was flawless when using two pre-paired HM-10 modules, the Pi's GPIO serial port was configured using PySerial.
The following methods have also been tried:
Using WiringPi to set-up a bluetooth serial port on the /dev/ttyAMA0
using Python sockets and rfcomm
When attempting to use both of these methods. The Python code compiles, however, once the Serial Port is opened the data is seemingly not written and does not show up on the Arduino's Serial Monitor.
This then cripples the previous functions. Even when using bluetoothctl manually, the module cannot be unpaired/disconnected. Writing to the appropriate attribute does not work either.
A restart is required to regain normal function.
Is this approach correct?
Is there a better way to send data over BLE?
UPDATE: 05/07/2017
I am no longer working on this project. But troubleshooting has led me to believe that a "race condition" in the code may have led to the program not functioning as intended.
This was verified during the testing phase where a more barebones code was created that functioned very well.