Tracker Project

Idea

The idea is to design a custom GPS-tracker, communicating over cell data connection (2G/3G/4G, maybe 5G), providing SMS and phone call backup channels and sending alarm on specific events (leaving geofence, exceeding a specific speed, noting vibrations, maybe reacting on noise, fire or external trigger). All that in a battery-driven setup with the focus on energy and data saving.

Components

The list of the components is continuously updated as new findings come up and alternatives get tested.

Functions

The list of considered functions is continuously updated.

• SMS API
  • Set password
  • Set callback phone no.
  • Set APN
  • Set server address
  • Set API key
  • Set SIM PIN
  • Get position on request
  • Get position on movement (geofence)
  • Get position on speed
  • Get position on vibration (sensitivity)
  • Get position on external input
  • Get position on noise (sensitivity)
  • Get position on PIR
  • Get position on heat (sensitivity)
  • Get status (same as LEDs)
• Forward SMS to a number
• Send event on incoming call (not the one from registered phone)
• Turn LEDs on/off
• Phone
  • Call listen/speak
  • Get called on alarm
• API
  • TLS
  • Install certificate

Hardware Selection

Breakout boards for the development and testing:

• ESP8266-based with integrated SH1106 OLED display (HW-364A, similar to NodeMCU Lolin V3 plus OLED)

  

• ESP8266-based (ESP-12F module)

  

• ESP32-based (ESP-32 WROOOM-32)

  

• SIM7600E-H (Waveshaew SIM7600X 4G HAT module)

  

Hardware Findings

• The only reasonable interface between the microcontroller and the modem is UART (serial line). Since the modem HAT utilizes a bidirectional voltage-level translator (TXB0108) for the serial line, it can't drive the RX line of the ESP if there is the USB-RS232 (CH340C) converter on board in parallel. The pull-ups of the CH340C chip are way to strong. Because of that and because of having only this one serial port on the ESP8266 chip (the other one is shared with the flash memory and therefore unusable), further development on the ready-to-go modules is not possible (at least not without modifying them).

  

• The powering of the SIM7600X HAT seems to be somehow complex and will need to be modified for the final setup. It utilizes 3 voltage converters: an LDO from 5V to VBAT (4.something volts) as accepted by the SIM7600E-H chip, an LDO from 5V to 3.3V for the 3.3V logic (the SIM7600E-H is mostly 1.8V based), and a step-down converter from 5V to 3.0V for the PCM audio chip.

Software Findings

By the use of Micropython the development of the actual code should be easy and much faster than writing it all in C. Nothing against C, but the need of compiling and flashing the chip for each simple mistake is a huge waste of time. Still there are first ugly things:

• The implementation of the serial read buffer it either buggy (the last character on each buffer rotation seems to be eaten) or it's a limitation of the hardware (ESP8266).
• The use of REPL (interactive interpreter) becomes impossible on the serial line, as it will be needed for the modem. Fortunately the WebREPL variant works very well.

AT Commands Testing

• < denotes modem's output
• > denotes user's output

Boot with a SIM card (PIN-free)

< RDY
< 
< +CPIN: READY
< 
< SMS DONE
< 
< PB DONE

Boot without a SIM card

< RDY
< 
< +CME ERROR: SIM not inserted

Incoming call, answer, remote hang up

< RING
> ATA
< VOICE CALL: BEGIN
< 
< OK
< 
< VOICE CALL: END: 000017
< 
< NO CARRIER

Incoming call, no answer, remote hang up

< RING
< 
< RING
< 
< RING
< 
< RING
< 
< MISSED_CALL: 01:06AM +49REDACTED

Activating caller ID presentation, incoming call, no answer, remote hang up

> AT+CLIP?
< +CLIP: 0,1
< 
< OK

> AT+CLIP=1
< OK
< 

< RING
< 
< +CLIP: "+49REDACTED",145,,,,0
< 
< RING
< 
< +CLIP: "+49REDACTED",145,,,,0
<
<MISSED_CALL: 01:10AM +49REDACTED

Internet setup

Factory settings are preconfigured to a 'CMNET' APN for IPv4 data and 'ims' APN for IPv6 data, which obviously would work in China Mobile network only.

> AT+CGDCONT?
< +CGDCONT: 1,"IP","CMNET","0.0.0.0",0,0,0,0
< +CGDCONT: 2,"IPV4V6","ims","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0
< 
< OK

Setting own provider's APN, e.g.:

> AT+CGDCONT=1,"IP","web.vodafone.de",,,,
< OK

Establishing an Internet connection:

> AT+NETOPEN
< OK
< 
< +NETOPEN: 0

The +NETOPEN: 0 was somehow confusing. Querying for the status a few seconds later gave a positive response:

> AT+NETOPEN?
< +NETOPEN: 1
< 
< OK

TCP communication

Open a connection:

> AT+CIPOPEN=1,"TCP","REDACTED",12345
< OK
< 
< +CIPOPEN: 1,0

Send data:

> AT+CIPSEND=1,10
< >
> 1234567890
< OK
< 
< +CIPSEND: 1,10,10

Any data received is forwarded directly to the user (in the default mode):

< RECV FROM:REDACTED:12345
< +IPD10
< abcdefghi<CR>

Closing a connection:

> AT+CIPCLOSE=1
< OK
< 
< +CIPCLOSE: 1,0

If closed by the remote party:

< +IPCLOSE: 1,1

Pinging (by DNS name)

> AT+CPING="miltschek.de",1,2
< OK
< 
< +CPING: 1,188.34.192.217,64,446,255
< 
< +CPING: 1,188.34.192.217,64,501,255
< 
< +CPING: 3,2,2,0,446,501,473

HTTPS client

Opening a connection with the GET method:

> AT+HTTPPARA="URL","https://miltschek.de/"
< OK
< AT+HTTPACTION=0
< OK
< 
< +HTTPACTION: 0,200,2854

Reading out the data:

> AT+HTTPREAD?
< +HTTPREAD: LEN,2854
< 
< OK
> AT+HTTPREAD=200
< OK
< 
< +HTTPREAD: DATA,200
< <!DOCTYPE ...

Repeat it until the end of data:

> AT+HTTPREAD=200
< OK
< 
< +HTTPREAD: DATA,54
< 9th, 2023</em></a></li>
<                        <li><a href="/article_2023-10-
< +HTTPREAD: 0

If you try to read further:

> AT+HTTPREAD=200
< ERROR

If you ask for available data again:

> AT+HTTPREAD?
< +HTTPREAD: LEN,0
< 
< OK

Certificate validation

The HTTPS client does not care about the server's certificates and silently accepts invalid ones. Need to verify it, whether the SSL client works differently.

(to be continued...)

SMS

This simple topic (as I thought at the beginning) did grow up to a quite big one and got a separate page. Please follow the link to read the whole article.

USSD Codes

The so called quick codes, or rather Unstructured Supplementary Service Data, can be accessed by the AT+CUSD command. The only thing one needs to know is the correct alphabet coding.

> AT+CUSD=1,"*106#",15
< OK
<
< +CUSD: 0,"Kontostand: 20,60 EUR",1

The last parameter <dcs> denoting a Cell Broadcast Data Coding Scheme is the key. These codes are specified in GSM 03.38, Chapter 5. In Germany a value of 15 seems to be the correct one. The value is equal to 00001111 binary, which renders (acc. GSM 03.38) to the default alphabet with an unspecified language. Other values (or a default one of 0) do produce an error:

> AT+CUSD=1,"*106#"
< OK
< 
< +CME ERROR: unknown

or:

> AT+CUSD=1,"*106#",12
< OK
< 
< +CME ERROR: retry operation

For interactive-like services, simply send your response before a timeout happens:

> AT+CUSD=1,"*100#",15
< OK

after a few seconds you get:

< 
< +CUSD: 1,"Aktuelles Guthaben: 20,60 EUR
< W�hl bitte aus:
< 1 Aufladen
< 2 Guthaben & Verbrauch
< 3 Tarife & Optionen
< 4 Spracheinstellungen
< 5 Vorteilsangebot",1

Yes, there is a coding issue, which needs to be solved in order to correctly see national characters. I keep the �-signs here as a reminder.

then, simply send the selected option, e.g. 2 for balance and usage:

> AT+CUSD=1,"2",15
< OK
< 
< +CUSD: 1,"W�hl bitte aus:
< 1 Guthaben abfragen
< 2 Bonus-Guthaben abfragen & mehr Infos
< 3 Verbrauchs-Check
< * Zur�ck",1

then, e.g. a 1 for the balance:

> AT+CUSD=1,"1",15
< OK
< 
< +CUSD: 1,"Du hast ein Guthaben von 20,60 EUR
< * Zur�ck
< # Hauptmen�",1

and finally, special keys do work as well, e.g. a # for the main menu:

> AT+CUSD=1,"#",15
< OK
< 
< +CUSD: 1,"W�hl bitte aus:
< 1 Aufladen
< 2 Guthaben & Verbrauch
< 3 Tarife & Optionen
< 4 Spracheinstellungen
< 5 Vorteilsangebot",1

After a timeout (in my case ca. 25 seconds), the session gets closed, denoted with an error message:

< +CME ERROR: unknown

Text-to-Speach

Surprisingly, the modem offers a TTS service, which can do both: read out the text locally (to your earphone) or remotely (to the calling person). Just the loudness seems to be way too high and the volume option does not really change much.

Instruct the service to send the voice to the remote party:

> AT+CDTAM=1
< +CDTAM:
< 
< OK

Answer an incoming call:

< RING
> ATA
< VOICE CALL: BEGIN

Request a readout:

> AT+CTTS=2,"Thank you very much"
< OK

After the synthesizer is idle again, you get an event:

< +CTTS:0

DTMF Reception

If the calling party sends DTMF tones, without doing anything they get recognized and corresponding events get generated:

+RXDTMF: 1

+RXDTMF: 2

...

+RXDTMF: *

+RXDTMF: #

Same should work for the extended keys A, B, C and D.

References

• GSM 03.38: language-specific requirements for GSM within the digital cellular telecommunications system (Phase 2/Phase 2+).

Previous: SMS TPDU Transfer Protocol Data Unit

Main Menu