I am implementing a GSM solution with the following hardware and software stack:
- Raspberry Pi Zero W
- Nodejs application
- Adafruit FONA SIM800H
- Serial communication between RPi/Node and the FONA.
- SSH with putty into the raspberry pi.
With ATE1 it can be seen that the SIM800H responds with these weird buffers containing 00’s. The SIM800H does not respond like that with all AT commands. Here is an example.
RESPONSE (first represented as the Buffer and then ToString’ed to see the text representation):
<Buffer 41 54 2b 43 49 50 53 48 55 54 0d 0d 0a 53 48 55 54 20 4f 4b 0d 0a>
This is looking great! Let move onto the next command:
<Buffer 41 54 2b 43 53 54 54 3d 22 54 45 4c 45 4e 4f 52 22 2c 22 22 2c 22 22 0d>
<Buffer 0d 0a 4f 4b 0d 0a>
Ok, this is also looking great. Next command (and here the weirdness starts!):
<Buffer 41 54 2b 43 49 49 43 52 0d>
<Buffer 0d 0a 4f 4b 0d 0a>
<Buffer 00 00>
<Buffer 00 00 00>
and this response with a Buffer of one to four 00’s repeats itself for about 20 times. The following AT+CIFSR command responds properly. And then the following AT+CIPSTART command again responds with this weird data, I eventually get the CONNECT OK, followed by a bunch of these weird “empty” buffers. After all Buffers with 00’s the SIM800H quietly waits for the next AT command, as expected.
The SIM800H also spits out these buffers with 00’s while waiting for +CREG: 1 after startup. Lots of these buffers, maybe 50 to 100 of these buffers containing one to four 00’s.
Have any of you every experienced this kind of response?
I struggle with a lot of timeouts with the +SAPBR=1,1 command and the with many of the +HTTP commands. The +SAPBR=1,1 command can take a bit of time and I have the recommended 85s timeout, but a command like +HTTPPARA should not really be timing out. For most of the time the AT commands work flawlessly, but sometimes the SIM800H responds with all this nonsense. And I think that these nonsense responses are causing the timeouts. It is like the internal buffers of the SIM800H gets messed up or something. And then… all of a sudden it is working again. Is it maybe something with the network? I have flashed the SIM800H with version 1309B11SIM800H32. I will soooo much appreciate it if someone can help me. I have been working on this solution for almost 2 years and feel comfortable with the tech stack I am using, but this issue (when it pops up) is hitting me for a six!
Seems like it can be an electrical issue on the UART ports. Can you describe it as detailed as possible (topology, distances, connections, logic voltage converters, power supplies, etc)?
The Adafruit FONA breakout board does all the level shifting and power supply. The FONA is charges a lipo battery from which the system is powered. The UART’s TX and RX lines are about 70mm long and runs directly from the RPi Zero to the FONA. In the picture below the RX and TX lines are highlighted white. At the bottom is the RPi Zero and at the top are 2 headers for the FONA since I use either the FONA Mini (https://www.adafruit.com/product/1946) or the FONA 808 Mini (https://www.adafruit.com/product/2542). The pinouts for the two FONA’s are not the same.
The RX and TX traces are 0.1524mm wide. Copper layer thickness is 1oz. The bottom of the pcb is a ground pour.
The RPi and FONA’s logic level is 3.3V.
Baud rate is 230400.
Are the TX and RX lines to long? Too thin?
Nice little SIM800 breakout board! I’ve only worked with the cheap stripped-down chinese ones.
That seems ok, only thing that worries me are all those twists and that 90º angle on the bifurcation. But I don’t think those should be too problematic.
Ok, so supposing that the shift level circuit works properly, some things I’d check would be:
- Keep in mind that the maximum speed for “auto-bauding” that the SIM800 supports is 115200. Depending on the mode of operation, this might be problematic. And since this is also the “default” baud-rate, I would go as far as think of it as the “recommended” baud-rate.
- Also, I have no idea what level-shifting circuit have Adafruit used. If it’s one of those with a couple of MOSFETs and resistors, it might not be very fast – those are usually used for i2c at the lowest speeds – .
- What power supply are you using to feed the FONA and its charger?
Yea, Adafruit makes awesome breakout boards. They are not the cheapest, but they work well.
I agree with your remark on the twists and 90deg bifurcation. I will straighten them out on the next version. However, even at 230400 baud the speeds we are talking about is still relatively low.
I do not use auto-bauding. I fix the baud rate with the +IPR command. I will go back to 115200 baud.
Adafruit uses a 74VHCT125PW for level shifting. I think it is proper level-shifting IC and should be up for the job.
I use a Mean Well RS-15-5 AC-DC single output enclosed power supply. It steps down 230VAC to 5VDC at 3A. As far as I know Mean Well power supplies are really good.
How often do you get timeouts/errors with AT commands? Some AT commands should reply almost instantaneously, like fore example AT+HTTPPARA=“URL”,“www.google.com”. Why these kind of AT commands get a timeout/error is strange. It is more understandable with AT commands like AT+HTTPACTION and AT+CIICR that involves the network
Even ATH has timeouts sometimes when I want to cancel an incoming call. According to the datasheet ATH has a max response time of 20s. So I have to wait 20s before I can be sure that it has timed out, and then resend the ATH command.
Do these things happen to you as well?
Ok, hardware seems overly qualified!
Never! Even when I’ve build a very rough prototype at the beginning, I only got some eventual misses and somethimes some ghost
<CR LF>. In production boards which incorporate some cheap chinese SIM800 module, I don’t see nor ever have seen such problems.
Can you try swapping some of the components? Like using an Arduino instead of a Raspberry, or using some other SIM800 module.