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,665
  • 3
  • 10
  • 24
ephestione
  • 125
  • 1
  • 8
  • @Fred I feel like this shouldn't have been moved to the raspberry board, since I don't think this is raspberry specific, rather it's regarding the serial interface. I'm using a USB-TTL adapter, so the device the USB adapter is attached to, has no saying over what the adapter itself is returning from the serial console, am I right? – ephestione Sep 27 '19 at 16:29
  • Based on a global Stack Exchange search it looks like Stack Overflow has dealt with the most SIM800L questions. I'm not sure how it ended up here. – Fred Sep 27 '19 at 18:44
  • @Fred oh sorry, I saw that you edited the message and also thought it was you who moved it, yet by your reply it appears you didn't. I understand how Stack Overflow might be the most suited usually, yet regarding this particular situation, it was especially hardware oriented, rather than software, that's why I posted in SuperUser – ephestione Sep 28 '19 at 16:41

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,791
  • 3
  • 16
  • 20
ephestione
  • 125
  • 1
  • 8
  • Jumper cables and breadboards are cool for prototyping. If you plan to keep using your alert system, you should assemble it properly and use soldering or crimping for connections. Otherwise two years down the road the jumper cable will oxidize and your ground problem will come back. – Dmitry Grigoryev Nov 08 '19 at 10:07
  • My system is still in the experimental phase, so yes, an hypothetical finished hardware will have everything soldered on a perfboard. I even dream about selling kits one day, but that's just me fantasizing. Right now the hardware is in early beta stage (and software in proper beta) so breadboard and jumper cables are needed :) – ephestione Nov 08 '19 at 19:35
-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,665
  • 3
  • 10
  • 24
  • Hi, and thank you the the reply. You pointed out a page of a PDF manual that I have, but the last part I wasn't so fresh about: "autobauding requires no parity". This though doesn't make it clear IF I can set parity check when manually setting the baudrate. I made sure to manually set baudrate with AT+IPR=4800 yet even if I try AT+ICF=? after that, it still returns ERROR, so strangely the parity check setting is among the official commands accepted by the module, but it won't work anyway – ephestione Sep 27 '19 at 11:14
  • Just a couple of quick, random comments: (1) The lower the speed, the more reliable, ie, less errors in transmission. Therefore it is a good idea to do the first stage of testing using 1200 baud, though 2400, 4800, 9600 are still as reliable, (2) Jus to make very sure, try to do loopback of your minicom terminal emulator, (3) Are you sure your AT+CF = ? test is done correctly. Let me check the manual and let you know over the weekend. – tlfong01 Sep 27 '19 at 14:30
  • yup, I also did the tests with 1200 baudrate, it still shows the same problem. – ephestione Sep 27 '19 at 16:26
  • I copied the AT+ICF commands from the PDF manual that I already had over here, and each one, AT+ICF=?, AT+ICF? and AT+ICF=X (where X is the parity mode I want to set), returns ERROR. The module plainly refuses to have anything to do with parity :D – ephestione Sep 27 '19 at 16:33
  • Well, if everything else looks OK, but only "AT+ICF=X (where X is the parity mode I want to set), returns ERROR", then it is very likely that (1) SIM800 does not want to do that. (2) I usually have at least two identical devices for swap testing. I also use more than one terminal emulators (Win10 RealTerm/TeraTerm) and (Rpi minTerm/puTTY etc) to do parity mode tests (Win to Rpi) without the SIM800, to make sure everything else beside SIM800 is working properly, ... – tlfong01 Sep 30 '19 at 01:22
  • I tend to think that "parity checking" misses altogether with SIM800, as I see nowhere on the internet that anyone is using it, and even in the manual it defaults to indicating 8N1 as connection parameters. Maybe that AT+ICF command found its way in the official documentation without actually being supported. – ephestione Sep 30 '19 at 07:49
  • @ephestione,Ah yes, I agree with you. Perhaps parity is simply not supported. Perhaps you can do this instead of using parity: (1) Send any command, if return error, then send again, until no error. This way it is as good as using parity and resend with parity error. – tlfong01 Sep 30 '19 at 07:56