Things get weird with 115200 baud #1
Comments
|
Things started going south for me on 9600 baud as well, but this fix did the trick. Things work great on 115200 baud now, too. I think that python stops monitoring the serial port once you exit a "with" statement, so things were getting lost in the gap between "send" and "watch". def watch_and_send(cmd, timeout=10, success=None, failure=None, echo_cmd=None):
with serial.Serial(PORT, BAUD, timeout=1) as ser:
ser.write(cmd.encode('utf-8') + CMD_LINEBREAK)
t_start = time.time()
reply = list()
while True:
if ser.in_waiting:
line = ser.readline()
echo = False
if echo_cmd:
echo = line.decode('utf-8').strip().endswith(echo_cmd)
if line != CMD_LINEBREAK and not echo:
line = line.decode('utf-8').strip()
reply.append('\t' + line)
if success and line.startswith(success):
return ("Success", reply, time.time()-t_start)
if failure and line.startswith(failure):
return ("Error", reply, time.time()-t_start)
if (time.time()-t_start) > timeout:
return ("Timeout", reply, time.time()-t_start)
time.sleep(0.02) |
|
I'm going to keep this thread going with some more things I've run into:
openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem |
|
@CoolNamesAllTaken I followed the guide here on test.mosquitto.org to generate the certs and key. |
|
Ha, just saw your comment above. Will leave this here in case it's helpful to anyone. Figured out the key problem. I was generating the wrong format of RSA Key, and then using that key as a certificate instead of using it to create a certificate request. The correct command sequence is below. openssl genrsa -out azure.key
openssl req -out azure.csr -key azure.key -newThen, use azure.csr with the mosquitto guide linked in the post above to get an actual client certificate. Apologies for the spam--I'm picking this up for the first time, and hoping that if I generate some sort of documentation people might have a better time down the line. I'd be happy to do a PR with my code changes and maybe some readme improvements if you'd like @tmcadam . |
|
Yes please @CoolNamesAllTaken |
|
I'm still working through the code changes, but seem to have connections working to some degree for MQTT with only a remote server certificate (I put mqtt-bothcerts on the backburner for now since Azure doesn't actually have a nice key signing tool like mosquitto as far as I can tell). @tmcadam dumb question: what is the But I don't really understand what it's saying. My best guess is that it's a connection ID value used for multiplexed connections with multiple IPs, but I'm not sure. So far I've set it to 0 or 1 and things work (as long as all the |
|
I'm not really sure to be honest. I guess you could test if you get a second IP using another index while having the first connected. I guess not all carriers would support that as well. |
|
I've found the SIMCOMM docs pretty useless and out of step with firmware updates on occasions. It's painful working with AT as well with no meaningful feed back from commands. Just all trial and error. |
|
Yeah it's unfortunate how bad the documentation is. The worst part is that there seems to be 3 different ways of doing things for every command, and using any mix of the two methods causes things to break. I'm trying to integrate with the TinyGSM library on Arduino right now and things are blowing up royally. Would you like me to fork your repo to add changes, or would you like to give me write access? I have a branch that I'm working on at dev/jm/mojo that I can push if you'd like to see any of my changes so far. |
|
@CoolNamesAllTaken Added you as collaborator, you should be able to push. Be aware our modules are on fairly different firmware versions (I'm Sim7000e @ B07), but we can add that as flag in the command line and handle the variations in the script if we need to. |
I am trying to do this as well (based on an esp32 and the sim7000 connected) the initial setup in the current master of TinyGSM is a merge from my fork. Compared to the SIM800 stuff the AT+CIPSSL command is not present on the SIM7000 which would simply set TCP to use SSL function. |
|
@captFuture One of the things that was confusing me about the TinyGSM code was that it was doing a very complicated setup for an "IP Bearer" configuration. It is my impression that a TLS connection is referred to in the AT manual as an "App", which uses an entirely different set of AT commands. For instance, AT+CAOPEN instead of AT+CIPSTART. I'm currently rewriting the Sim7000 TinyGSM code to use SSL only, and consequently use the AT+CA___ type commands. This corresponds to the set of commands that seems to work fine in @tmcadam's python script for mqtt over ssl with a ca cert only. Is my understanding correct? |
|
Thank very much for your thread. It answers my questions. Appreciate your experience-sharing. |
|
thanks for the post here, it helped a lot. the code works for me except for the SSL part. my goal is to be able to connect to https://httpbin.org with AT+SHCONN. I downloaded the root cert from https://httpbin.org, named it "httpbin-ca.cer". It looks like: -----BEGIN CERTIFICATE----- Then I used python sim7000.py cert-load to upload the cert to the SIM7000A module, no issue. I am able to check it with QPST EFS explorer. Finally I ran the mqtt-cacert function (updated some commands) and getting the following response, I tried running it through putty, SSCOMV5.13.1, I tried different cert, different sites. It gets ERROR on AT+SHCONN no matter what. am I missing some critical step? No issue with HTTP calls. I appreciate anybody's help here, if you have a working root cert and matching site that you know is working, please share it. at this point, I don't know if this is a defective module. The firmware shows Revision:1351B04SIM7000A. thanks a lot! ... ----------- AT+CNACT=1 ----------- ----------- AT+CNACT? ----------- ----------- AT+SHCONF="URL","https://httpbin.org" ----------- ----------- AT+CSSLCFG="sslversion",1,3 ----------- ----------- AT+CSSLCFG="convert",2,"httpbin-ca.cer" ----------- ----------- AT+SHSSL=1, "httpbin-ca.cer" ----------- ----------- AT+SHSSL? ----------- ----------- AT+SHSTATE? ----------- ----------- AT+SHCONN ----------- ... |
|
You can try: Some of my examples: AT+SHSSL=1,"" AT+SHSSL=1,"" AT+SHSSL=1,"" AT+CSSLCFG=convert,2,ca.crt |
|
I had a similar issue when running code at 115200 and even some at 9600 baud. The beginning of strings were missing. Also note that I was able to remove all of the sleep commands and received data came through as expected!! Thank you for sharing your code, I have adopted some to SIM7080, the AT command and return does work well. #def send(data):
# with serial.Serial(PORT, BAUD, timeout=1) as ser:
# ser.write(data)
#def send_cmd(cmd):
# send(cmd.encode('utf-8') + CMD_LINEBREAK)
#def send_cmd(cmd):
# with serial.Serial(PORT, BAUD, timeout=1) as ser:
# ser.write((cmd.encode('utf-8') + CMD_LINEBREAK))
def send_cmd(cmd, timeout=10, success=None, failure=None, echo_cmd=None):
# with serial.Serial(PORT, BAUD, timeout=1) as ser:
# ser.write((cmd.encode('utf-8') + CMD_LINEBREAK))
#def watch(timeout=10, success=None, failure=None, echo_cmd=None):
with serial.Serial(PORT, BAUD, timeout=1) as ser:
t_start = time.time()
ser.write((cmd.encode('utf-8') + CMD_LINEBREAK))
reply = list()
while True:
#time.sleep(.2)
if ser.in_waiting:
line = ser.readline()
echo = False
if echo_cmd:
echo = line.decode('utf-8').strip().endswith(echo_cmd)
if line != CMD_LINEBREAK and not echo:
if line != "\r\n":
line = line.decode('utf-8').strip()
reply.append('\t' + line)
if success and line.startswith(success):
return ("Success", reply, time.time()-t_start)
if failure and line.startswith(failure):
return ("Error", reply, time.time()-t_start)
if (time.time()-t_start) > timeout:
return ("Timeout", reply, time.time()-t_start)
#time.sleep(0.1)
def AT(cmd="", timeout=10, success="OK", failure="+CME ERROR"):
cmd = 'AT' + cmd
print("----------- ", cmd, " -----------")
#send_cmd(cmd)
#reply = watch(echo_cmd=cmd, timeout=timeout, success=success, failure=failure)
reply = send_cmd(cmd, echo_cmd=cmd, timeout=timeout, success=success, failure=failure)
print("{0} ({1:.2f}secs):".format(reply[0], reply[2]))
print(*reply[1], sep='\n')
print('')
return reply |
Commands work fine at 9600 baud, but something goes wonky at 115200 baud (none of the responses are received, and all I get is timeouts). My guess is that since the send and receive commands execute sequentially, the slight delay between send and receive at the higher baud rate causes something to get missed. It might be worth rearranging things slightly such that the script starts reading the serial port before the command is sent.
Thanks for making this script! Super helpful as both a tool and a reference :)
The text was updated successfully, but these errors were encountered: