Why TC65 SMS OTAP software update is great

WARNING: All the Cinterion related content from this blog will be removed to go to the javacint wiki soon. Please get used to going there.

Update anything

Cinterion gives specifications on how to send SMS messages to launch a remote Over The Air Provisionning (OTAP) operation.

Recently, someone asked me : We have a little program on some TC65 chips that only send SMS, we would like to connect it to the software that you built. What would we have to do. Well that where the magic comes. You don’t have to touch any of the hardware. The only concrete thing you might have to do is enable GPRS on the sim cards of your M2M fleet.

Let’s say the current little program’s name is “little.jar” (+ its “little.jad”). You have to build a program called “little.jad” that :

  • Change the name of the starting program from a:/little.jad to a:/m2msoft.jad
  • launches a local OTAP operation (with the “AT^SJOTAP” command)

Then you publish it on your HTTP server, send an SMS to every TC65 chip with the address of your HTTP server, and HERE IT IS ! Your whole M2M equipments fleet is updated with your brand new software.

Note on the SMS

According to Cinterion’s specifications, it’s pretty easy to send the software update SMS. But, when the time comes where you actually have to do it, you might get stuck, because it has to be precisely forged. I built a little (english+french) program that enables me to send SMS update to any TC65 ship I like.

It looks like that :


I updated the program. More details here.

A little bit deeper

You should remember that whatever parameter is sent by SMS, it is overridden by the “AT^SJOTAP” setting. The only way to have a remote complete control over the chip is to send the “AT^SJOTAP=” command.

That means that if you want to just put your chips where they have to act and then do a little OTAP to install the first program on it, you have to set :

  • AT^SJOTAP
  • AT^SCFG=”Userware/Autostart”,””,”1″

Cinterion TC65 Chip

WARNING: All the Cinterion related content from this blog will be removed to go to the javacint wiki soon. Please get used to going there.

M2M projects are the type of project I like to work on. Connecting remote devices, making them work together, and controlling everything remotely are things i love !

I discovered the Cinterion TC65 (which belonged to Siemens then) 3 years ago. And it was a dream come true. I’ve been mostly working on it to build some powerfull GPS tracking software over GPRS. But I have also worked on some other projects making it communicate with some equipments using GPIO or serial port.

Some things you might like with the TC65 Chip :

  • Java Virtual Machine (J2ME)
  • Only requires a serial or a virtual serial link over a USB cable to program
  • You can easily build powerful, multi-threaded programs
  • Easy management of GPIO, SPI, I2C ports
  • Easy management of TCP/UDP connections
  • Quite powerful (400 KB of RAM, 1.7 MB of memory)
  • You can update your code remotely with at commands or specially formated SMS
  • It’s fast enough for most of your M2M usages (but it’s not well suited for sound or video transport)

I’m quite disappointed to see how only few people/companies are interested in this product. The product is great, developers tools are great and the over the air updating feature is great too ! I think it costs around 60/70 € ($95). One reason might be that the first version of the chip was pretty buggy. The only safe solution was to add a hardware watchdog.

There’s a pretty interesting feature that I would love to use : libraries that are downloaded and updated separately from the main program. But sadly, it isn’t compatible with some old v1 chips I still use.

Available TC65 software versions are :

  • TC65 v1 : First version. Very unstable. It could crash for days. It also happened that the software was suddenly deleted. Couldn’t get standard output to the virtual serial port on USB. Sometimes OTAP SMS could save the chip, sometimes we just had to wait for days before it decided to come back to life.
  • TC65 v2 : New hardware (HW v2). Seems more stable. Thought, I have one chip where it sometimes crash just 20 seconds after startup.
  • TC65 v3 : Can be upgraded from a software v2 (needs a HW v2). Offers a software watchdog.
  • TC65i v1 : Cinterion has bought it. Smaller, better power saving mode.

And for the XT65 chip :

  • XT65 v1 : TC65 v2 with GPS
  • XT65 v2 : TC65 v3 with GPS

Vendors selling their TC65 with a watchdog often don’t have one. They just rely on the software watchdog of the TC65 v3 chip.

MySQL Master-Master desynchronization

Settings a master-master synchronization is pretty easy. You can find a quick guide to do this on google, just try.

What is a little bit more problematic is when you lose your loved sync. And that can happen. It happened to me yesterday, I upgraded my two servers from Debian 4.0 to Debian 5.0. The reason is that the old version (something like 5.0.32) used the Relay_Log_File ${hostname}-relay-bin.XXXXXX. And the new version (5.0.51a-24-log) decided to use mysqld-relay-bin.XXXXXX.

I tried to solve it the easy way with just a :

1
2
STOP SLAVE;
CHANGE MASTER TO RELAY_LOG_FILE="mysqld-relay-bin.000001";

but the server wasn’t happy with that. So I took the time to take the current slave settings :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State:
                Master_Host: **HOST**
                Master_User: slave1
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000521
        Read_Master_Log_Pos: 306043
             Relay_Log_File: mysqld-relay-bin.000050
              Relay_Log_Pos: 306137
      Relay_Master_Log_File: mysql-bin.000521
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 306043
            Relay_Log_Space: 306137
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)

On both server, I did something like that :

1
2
3
4
5
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO RELAY_LOG_FILE="mysqld-relay-bin.000001", MASTER_LOG_FILE="mysql-bin.000521", MASTER_LOG_POS=306043,
RELAY_MASTER_LOG_FILE='mysql-bin.000521', RELAY_MASTER_LOG_POS=306043;
START SLAVE;

The position of the log is pretty important.

It might sometimes occurs that you RELAY_MASTER_LOG_POS on the slave is higher that the Position that the server possesses for the same file. The reason is that sometimes the master sends its logs, crashs and haven’t saved it to his logs. In this case, you might have a little bit more data on the slave than the server. That means that you should lower the MASTER_LOG_POS of your slave so that it isn’t higher than the Position shown by the “show master status\G” command.

I really recommend using this precise method instead of restarting the whole synchronization process. Which occasionally requires you to stop your servers to copy the files. On my servers, the databases take 15 GB. It isn’t a big database bug that already makes you think twice before doing a copy (or even a rsync).

By the way, I really talked about it, but InnoDB/MySQL is a very simple/efficient/sure choice for a database. The only big drawback of the InnoDB is that there isn’t a simple online backuping solution. I like to save the database and its logs regulary (a bad raw copy of a InnoDB database can be corrected by its logs) and to extract the whole database in SQL every night.

By the way, if you don’t understand everything and particularly why each slave must have two threads to read master logs, you should read this.

Compile mono on Debian

Mono enables you to run .Net program on almost every operating systems and my second favorite one is Debian/Linux (my first one is Windows as you can guess).

You need to get some tools :

1
apt-get install subversion make automake autoconf python gcc g++ libtool pkg-config bison libxml-perl gawk

Get the SVN repository (very slow) :

1
2
3
4
5
6
mkdir ~/mono
cd ~/mono
svn co svn://anonsvn.mono-project.com/source/trunk/mcs
svn co svn://anonsvn.mono-project.com/source/trunk/mono
svn co svn://anonsvn.mono-project.com/source/trunk/libgdiplus
#svn co svn://anonsvn.mono-project.com/source/trunk/gtk-sharp

You need to set this :

1
export PKG_CONFIG_PATH=/usr/lib/pkgconfig/

If you don’t have any mono on the system :

1
2
3
cd ~/mono/mono
make get-monolite-latest
make EXTERNAL_MCS=false

You can now compile everything, it takes a lot of time to complete:

1
2
3
4
cd ~/mono/mono
./autogen.sh
make
make install

If there’s a problem with a missing file error, try to re-launch these three last commands, the “./autogen.sh” should fix it.