1

I am adding a SIM800L module to a home burglar alarm system I'm building around a RPi3. I've already encountered, and overcome, the usual power problems, and I can successfully use the module to make and receive calls, and send tones; I use:

minicom -D /dev/ttyUSB0 -b 4800

to manually communicate with the module. It's not working as a modem, just as a means to send and receive calls and SMS messages. The module acts correctly, calls and receives, hangs up, and reads SMS fine. The problem lies in the quality of the serial console output, which is sometimes garbled, showing garbage, or missing, characters. I'll show what I mean (NNNNNNNN stands for my own mobile number, which gets called correctly... sometimes the number itself gets mangled in the output):

atdNNNNNNNNN;
OK
at+clcc
+CLCC: 1,0,2,0,0,"NNNNNNNNN",129,""

OK
at+clcc
é 1,0,2,0,0,"NNNNNNNNN",129,""

OK
at+clcc
+CLCC: 1,0,2,0,0,�鑦¦Âʪ��²Êbʊ�Êbj

OK
at+clcc
+CLCC: 1,0,2,0,0,"NNNNNNNNN",Lʦbj

OK

This makes it impossible to automate the module based on its output, because any preg_match will fail.

I twisted together the RX and TX cables (which use dupont connectors, and are no more than 15cm long), and the ground is common between the SIM800L module and the USB port of the raspberry where the TTL adapter is attached (I checked continuity with a multimeter). I tried all the baudrates supported by the module with no benefit (I didn't test above 115200 since there would be no point).

Other people report similar issues with this module itself, but no definitive solution is .

I thought that I could enable parity check with this module, but setting the connection parameter to 7E1 from the default 8N1 in minicom yields no results, as in, I cannot even send the command from within minicom. If I use a PHP code to write in /dev/ttyUSB0 the command followed by a carriage return, the output shown in minicom with parity enabled (7E1) is completely garbled and unusable:

j5
C¡j5CQ+¨ê=L(Q+êAO$T1 ªT"CQ+ꪨê1                                                    |
¡HO©HMZ+�o[&éj
j5
¡j5
C顡j5
¡j5
C¡j5
C¡j5

The same PHP code correctly manages the SIM800L when the parity check is disabled (results from minicom and my PHP code are completely equivalent, I will need to use the latter for automation).

If I try to set parity check with AT commands, all I get is an error:

AT+ICF=?
ERROR
at+icf?
ERROR
at+ifc?
+IFC: 0,0

OK
at+ipr?
+IPR: 4800

OK

My questions are:

  1. Is there a way to enable parity check while connecting to SIM800L?
  2. Is there a reason, hence a feasible solution, to the corrupted output text coming from the module?
tlfong01
  • 4,847
  • 3
  • 12
  • 24
ephestione
  • 125
  • 1
  • 8

2 Answers2

2

I solved the question #1.

I wrote that SIM800 GND and RPi USB GND had continuity, and I wasn't "wrong", as testing with a multimeter for continuity I got a match, as in, multimeter was buzzing.

BUT, I didn't connect SIM800 GND directly to USB-TTL GND, as every device in the system has common GND already.

Turns out there was a small ground loop anyway, to the point where, after adding another jumper cable between SIM800 GND and USB-TTL GND, every "output corruption" was gone, or at least it was in every test I did until now.

Question #2 about enabling parity check on SIM800 is still open. Apparently, there is no way to do that, nor any explicit documentation exists.

MatsK
  • 2,882
  • 3
  • 17
  • 22
ephestione
  • 125
  • 1
  • 8
-1

Question

(1) SM800 serial communication is not reliable, how to fix it?

(2) How to set parity check?

Answer

/ to continue, ...

References

(1) SIM800 Series_AT Command Manual_V1.09

Appendices

(A) SIM800 Serial Port Functional Spec

sim800 at

tlfong01
  • 4,847
  • 3
  • 12
  • 24