SMS OTAP program for the TC65 updated

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.

Program updated !

As I told you in the comment where I released this TC65 SMS OTAP program, it didn’t support serial communication. Well, I have added this feature. The program is now able to directly send OTAP SMS, using a GSM modem.

The “config.bin” with your settings file isn’t compatible anymore.

Please tell me if it works for you and/or if you find bugs. You can also ask me questions about the TC65 if you need some help.

So, to use this program :
1. Extract at least SMSOTAP.exe from
2. Launch “SMSOTAP.exe”
3. Connect your TC65/XT65 modem to your serial port (or virtual serial port using USB interface)
4. Build a short message (take care about the class and the PID)
5. Click on the “Send” button

Note : When your type your message, the “\n” and “\r” are replaced by ‘\n’ and ‘\r’ chars. The carrier-return (CR) chars typed in the textbox are not sent. No other chars than ‘\n’,’\r’ are converted (but I might change that if you need it).

Note 2 : You should always remember that the “AT^SJOTAP” parameters always override the SMS ones. So, if you want to be sure you will always be able to remotely update your chip, you should reset all parameters by sending the “AT^SJOTAP=” command.

Note 3 : There’s a pretty good chance that this program works on a lot of other GSM modems than the Cinterion TC65 chip. It has never been tested on any other chips but it uses standard AT commands (you can see them in the window).

Cinterion TC65’s TCP stack limits

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.

If you use the TC65 to transmit some frequent (with a transmission interval of less than 700 ms) data, you should know that the TC65’s has a poor TCP implementation considering the ACK management of sent messages.

When the TC65 sends a TCP packet, it waits for an ACK packet before sending any other packet. It means that if you have a delay 400 ms between the TC65 and your server (which is very quite common), the TC65 will wait for 800 ms (400 ms for the data packet from the TC65 to the server and 400 ms for the ACK packet to return) before sending any data.

I discovered it because I wanted to send real-time GPS tracking data, and at a rate of 20 positions per second it was way above the minimal delay of 800ms. My positions came by packet of 5 to 20.

I asked for help to the french Cinterion’s support with complete description of the problem, “AT^SCFG” complete view and some libpcap network captures. And they couldn’t give me any real solution to this problem.

I think this is a chosen restriction. The chip has a memory of 400 Kb, to send a packet before waiting the acknowledge of the previous packet, it would have to use a more complex TCP stack and to consume some RAM to store all the packets left to acknowledge. I might be wrong, there might be a way to activate this, but right now Cinterion isn’t able give me any answer.

The only solution I found is to send data from the TC65 using UDP and to receive data using TCP. And receiving in real-time (I mean short time) DOES work perfectly with the chip (no need for increasing the receive buffer). You just have to disable Nagle’s algorithm (TCP_NODELAY=TRUE) on the remote host (most probably the TCP server).

The tomato firmware

Tomato is firmware for the WRT54G router. The firmware is simple and it has a very simple and powerful QoS management interface. It enables you do everything you should require from your router.

It just lacks VPN and IPv6 support, both functionalities I used on my previous OpenWRT firmware. But with this one, I didn’t have to type a single command line.

Here are some screenshots :

Sorry for the stupid gray margins. I didn’t realized that screengrab (Firefox extension) would take them. And now I’m too lazy to take new screenshots.

Bandwidth usage :

QoS management :

CIFS Access :

Remote logging :

Routing table :

I tried the Androïd 1.5 SDK

I tried the Androïd 1.5 SDK, it’s my first step on Androïd. I made a simple program to do a background calculation which brings back results to the UI, it counts the number of time it has been launched (by using the preferences data storage), it also takes pictures on the camera. I still can’t manage to display the preview (even if I do manage to get the data of the preview on the PreviewCallBack).

The APIs are pretty well organized. I can’t say it’s as confortable as Windows Mobile with C# .Net CF on VS2005/2008, mainly because it’s java (no event, dumb classes, lunatic interface and classes naming) and the layout creation GUI is ugly. But you can make powerful (I didn’t say fast) programs in no time.