1

I'm sorry if I'm not asking in the right way, but this is my first post here. Until now, I've often been here, but only read. I have an old device that sends an SMS through a Siemens C35i phone when certain activities are detected. The Siemens C35i is an old model and that's why I wanted to cheat the device a bit and connect to it through a Raspberry Pi to read these SMS messages and save them on a server like www. I have no experience in this type of programming, but I managed to connect the device to the Raspberry Pi and read the initial commands sent by the device. At the beginning, the device sends ATE0 and soon after AT+CGMM to make sure that the C35i phone is connected. I managed to write a program that responds, but the device reads only the first two characters of the response, which is C3, and the rest is cut off. What can I do to make the Raspberry Pi respond with the full identifier? Where can I make corrections? Here's my program:

import serial
import time

ser = serial.Serial('/dev/ttyUSB0', 19200) # ustawienia portu COM

at_file = open("AT.dat", "a") # otwarcie pliku AT.dat do zapisu
serial_file = open("serial.dat", "a") # otwarcie pliku serial.dat do zapisu

while True:
    data = ser.readline() # odczytanie jednej linii danych z portu COM
    data_str = data.decode("cp1252").strip() # konwersja danych na string

    if "AT+CGMM" in data_str: # jeśli transmisja zawiera kody AT
        response = "C35i"
        # Wysłanie odpowiedzi
        ser.write((response + "\r\n").encode("cp1252"))
        print(response)
        at_file.write(data_str + "\n") # zapis do pliku AT.dat
    else:
        serial_file.write(data_str + "\n") # zapis do pliku serial.dat
toyota Supra
  • 3,181
  • 4
  • 15
  • 19
Car Audio
  • 11
  • 1

1 Answers1

0

I have no experience in this type of programming

Then the first document you should start reading is the V.250 specification, most importantly chapter 5 (just to emphasis how important that document is: Even after working with implementing AT command in mobile phones in Ericsson for over a decade I and my colleagues still consulted that standard regularly).

Specifically for your scenario when emulating a modem (called DCE in V.250) your code is lacking sending a Final result code after receiving an AT command line from your old device (referred to as DTE from now on in this answer). Final result codes are OK, ERROR and several other responses1. This is covered in chapter "5.7 DCE responses".

In fact after sending the first ATE0 command line the DTE should be expecting and waiting for a final result code before continuing, so it would be perfectly within acceptable behaviour for that to be the only command line it sent since it did not receive a response.

The only reason for the DTE to continue with sending AT+CGMM after it failed to receive a response for ATE0 I assume is some thinking like "ATE0 and similar is only initialization commands, if they in some way fails then continue nevertheless and hope things still work out".

So you need to restructure your code a bit so that you:

  1. Buffer incoming data until you have received a complete and full command line (see chapter "5.2 DTE commands lines") and then and only then start parsing the command line.
  2. Consider if you want to support aborting of commands - you most likely will get away by not supporting it in your case, but let it be a conscious decision.
  3. Parse the command line and execute each command that is present.
  4. After the command line is finished executing send back a final result code.

1 While text result codes are the norm note that there also theoretical is a possibility for them to be delivered as numerical values with ATV0. So if the DTE sends that command you should honour it.

hlovdal
  • 26,565
  • 10
  • 94
  • 165