Cell based positioning with TK-202

The TK-202 tracker sends the mobile network data, when you configure it to reply in "SMS format" and request current location with smsone+password command.

The last four numbers in the SMS define MCC (Mobile Country Code), MNC (Mobile Network Code), LAC (Location Area Code) and Cell Id. The last two are in hexadecimal format. To find out the location of the tracker without GPS signal, you can use for example the following services:

1. http://cellphonetrackers.org/gsm/gsm-tracker.php (before inserting the LAC and Cell Id, remember to convert them into decimal format!)
2. http://www.track-position.com/loc?c=cellid-lac-mnc-mcc (replace word cell id and lac with decimal converted values; replace words mnc and mcc with their respective values)
3. http://openbmap.org/api/getGPSfromCellular.html
4. https://labs.ericsson.com/apis/mobile-location/ (requires registration)
5. http://opencellid.org/ (requires registration)

TK-202 tracker

TK-202 tracker

Be warned: this blog post is not about software. It's about hardware!

Here's some usage instructions for TK-202 (or TK202) tracker manufactured by Xexun. Although Xexun offers user manuals on their web site, the manuals are far from perfect. By combining different manuals for different products, you can find almost all the information written below.

Some comments about the tracker

It seems that the tracker stays functional over 30 hours if it's only using GPS and GSM connections. I haven't tried to use it with the home station that would allow the tracker to shut down GPS (and maybe even GSM) modules.

The TK-202 is quite well built. However, it has some features I don't like too much. First of all, you cannot change the time or date shown by the watch. When TK-202 has a GPS signal, it sets the time automatically to the current time. I guess it should also change the date according the the GPS data, but I have never seen it working. The time is set to UTC (GMT) time and user has to configure the offset from UTC time to get the local time correctly shown.

Another disturbing feature is that the small buttons the watch has are very difficult to operate. If you manage to press the buttons, you don't get any feedback from the watch. There are two buttons on the side of the watch. One of them sends SOS message and the other shows current tracker coordinates. To show the current tracker coordinates, you need to hold down the coordinate switching button for a couple of seconds. If the tracker doesn't know it's coordinates, it just shows blank screen. When coordinates are shown, the tracker displays them with blue back light on the screen. You can easily send an SOS message by pressing a button, but there's no way to tell whether the watch really has sent the SOS message or not. To turn the tracker on and off, you have to hold down the both buttons simultaneously for some seconds. It seems that you must press the coordinate switching button just before pressing the SOS button. Otherwise the tracker just sends the SOS message and doesn't turn off. Even when the tracker is turned off, it uses a lot of battery.

Small side buttons

The worst feature of TK-202 is that it's quite bad in locating itself. I have been walking with the tracker by the sea (guaranteeing that there's nothing that could disturb the GPS signal) for more than half an hour and the tracker hasn't been able to find its location. If the tracker looses the GPS signal, it may not be able to recover or the recovery takes ages.



General  instructions for using SMS commands
The + sign used in the tracker SMS commands means that the text should be catenated together without any other characters such as space.

After each command, the tracker sends some form of OK message. Don't try to send more than one command at a time.

Tracker initialization

begin+password

When the tracker is in default configuration (first time use), the command is the following.

begin123456

Send this command after the tracker has acquired its position for the first time.

Changing the password
To change the default password, use the following command.

password+old password+space+new password

For example to change password from 123456 to 654321, send the following SMS.

password123456 654321

Adding authorized phone numbers
Authorized phone numbers are allowed to query tracker's position either by SMS or call (depending on the operating mode). Although authorization is required by some TK-202 features, it's generally not mandatory. To make all features easily  accessible from your own cell phone, you may authorize it (and by doing this, you also block random people from accessing your tracker).

admin+password+space+cell phone

For example, to authorize Finnish cell phone number 040 1234567 so that it would work also outiside Finland (i.e. using international format, the Finnish country code is +358), you could use the following.

admin123456 00358401234567

Note that the + sign is coded as double zeroes! The rest of the authorized numbers (there may be five at most) must be configured by the first authorized number.

To remove one authorized number,  send the following SMS (I haven't tried this).

noadmin+password+space+authorized number

To remove all authorized numbers, use normal begin command that was used when the tracker was taken into use (I haven't tried this). For example.

begin123456

Changing answering modes (positioning, monitoring, two-way calling)

For some reason the TK-202 manual does not tell how to set up two-way calling mode. This is weird, because on of the selling points of TK-202 is definitively the two way calling feature (I haven't found many watch trackers with microphone and loudspeaker that would allow user to make two way calls)!

There are three modes in TK-202 that I'm aware of: tracking, monitoring and two-way talk. When the tracking mode is on, the tracker sends its position as SMS when it's being called by an authorized number. In monitoring mode, the tracker hangs up when called by an authorized number and calls back automatically. When call is answered, the authorized caller is able to hear what's happening in the surroundings of the tracker. In two-way talk mode, a call from authorized number is automatically answered by the tracker and the caller and the person carrying the tracker may talk to each other. Here's how to change between the modes.

tracker+password
monitor+password
talk+password

For example.

tracker123456
monitor123456
talk123456

In my opinion, both the monitoring and two-way talking are very well implemented. There is a faint echo on the line, but it's still very easy to communicate.

Changing the time zone (to set the time shown by LCD display)


The tracker is showing time in UTC time, if not changed by configuration. You can set the time difference between UTC and local time with this command.

time zone+password+space+GMT time

For example, for Finnish winter time, you should use the following.

time zone123456 2

Use negative numbers for time zones "before" UTC.


Changing the SMS format sent by the tracker

This is also something that's completely missing from the TK-202 manual. User is allowed to change the format of the SMS sent by the tracker. Here's some instructions.

To get one Google map link from the tracker, send the following message.

smslinkone+password

To get the results always in Google maps format, send the following message.

smslink+password

To get the results always in plain SMS format (default mode), send the following message (I haven't tried this).

smstext+password

It's also possible to get a single SMS formatted message.

smsone+password

Tracking periodically

You can configure the tracker to send multiple location SMSs with one command. You can specify how many location messages you want and how often these messages should be sent. However, it seems that the tracker is somehow failing to count the number of messages correctly and you may get more messages than you requested.
The command form is the following.

tXXXsYYYn+password

The part XXX is number of seconds, minutes or hours that the tracker should wait between the messages. Replace s with m to get minutes and h to get hours, respectively. The YYY part is the total number of messages the tracker should send. Both XXX and YYY have range of 001 - 255 and you must always use three digits.

To turn of periodic tracking, use this command.

notn+password

Some features to be tried later

TK-202 may have the following features that I haven't tried them yet (I'm not sure as I found these from manuals for other products).

1. tlimit+password+space+distance in meters (for example tlimit123456 50)
• This command should set the tracker to alarm if it is being moved more than 50 meters away from the point where the command was given. Distance of 0 meters will cancel the warning.
2. GpsAutoSearch+password+space+120 (for example GpsAutoSearch123456 120)
• This command should change the refreshing frequency of GPS measured coordinates in seconds. The accepted values are between 120 - 600 seconds.
3. restart+password (for example restart123456)
• This command should remotely restart the tracker. Perhaps useful in some situations
• I tried this once and the tracker stopped functioning. The only way to get it working again was to remove the battery
4. volume+password+number
• This command should change the loud speaker volume. Accepted range is 0 to 99.
5. Some other commands? Geofencing is also interesting, but not useful for me...

Battery cover

Battery front

Battery back

Sovelluksien konfiguroinnista sananen

Olen projekteissani törmännyt moneen erilaiseen tapaan tehdä sovelluskonfiguraatiota. Konfiguraatiolla tarkoitan tässä sitä, että sama käännöstuote eli (yleensä) binääri saadaan toimimaan eri tavalla konfiguraatiota muokkaamalla ilman tarvetta tehdä uudelleenkäännöstä lähdekoodista. Esimerkiksi tietokannan osoite ja tunnus ovat yleensä konfiguraatiotiedostoon erotettuna, koska testi- ja tuotantoympäristöissä käytetään usein eri tietokantaa.

Mielestäni on parempi viedä konfiguraatiota erillisiin tiedostoihin mieluummin enemmän kuin liian vähän. Joidenkin mielestä kuitenkin erilliset konfiguraatiotiedostot ovat jopa turhia, koska heidän ajatusmallinsa mukaan koodi voidaan aina kääntää ja asentaa uudelleen, kun lähdekoodissa oleviin asetuksiin tehdään muutoksia. Ylenmääräisestä konfiguroitavuudesta on kyllä haittaakin ja parasta on, jos melkein kaikille konfiguroitaville asioille voi antaa järkevän oletusarvon joko suoraan sovelluksen lähdekoodissa tai sitten erillisissä oletusarvoja sisältävissä konfiguraatiotiedostoissa.

Nähdäkseni on olemassa neljä eri tapaa tehdä sovelluksen konfiguraatiota.

1. Lähdekoodissa olevat vakiot, joiden muuttaminen vaatii lähdekoodin uudelleenkääntämisen
2. Konfigurointi erillisiin tiedostoihin (Javassa esimerkiksi properties-tiedostot), joiden sisältö kiinnitetään käännösaikaisesti esimerkiksi Maven filttereillä.
3. Konfiguraatiotiedostot, jotka eivät mene binääripakettien (JAR, WAR, EAR ja vastaavat eri kielissä) sisään ja joita voidaan muutella kääntämisen jälkeen vapaasti. Muutosten käyttöönotto vaatii prosessin uudelleenkäynnistyksen
4. Prosessin ajoaikainen konfiguraatio eli asetusten muuttaminen ilman prosessin uudelleenkäynnistystä. Tämä tapa on käytössä melkein kaikissa graafisen käyttöliittymän sisältävissä sovelluksissa, mutta erittäin harvoin taustaprosesseissa

Esittämäni konfiguroitavuuden tasot ja niiden järkevä käyttö projektissa riippuu täysin projektin koosta ja tavoitteista.

Jos koodailee itsekseen tai hyvin pienellä ryhmällä sovellusta, jonka ajoympäristö on yksinkertainen ja build-prosessin sekä kehittäjäryhmän hallitsema, voidaan rajoittaa konfiguroitavuus tapaan 1. Tällöin vaatimuksena on se, että kehittäjän on äärimmäisen helppo viedä pienetkin mutokset suoraan tuotantoon ja erillisiä testiympäristöjä ei juurikaan käytetä. On huomattava, että mikäli käytössä on yksikin ympäristö tuotannon lisäksi, se näkyy aina lähdekoodissa. Jokainen tuettava lisäympäristö ja poikkeama konfiguraatiossa vaatii muutoksia lähdekoodiin.

Tapa 2 on käyttökelposuudeltaan hyvin lähellä tapaa 1. Näillä on kuitenkin se merkittävä ero, että uudet ympäristöt tai erilaiset konfiguroinnit eivät enää vaadikaan välttämättä lähdekooditason muutoksia. Toki sovelluksen pitää osata hakea asetukset koodista erillään olevista tiedostoista. Yleensä tavassa 2 erilliset konfiguraatiotiedostot leivotaan binääripakettien sisään ja niiden buildin jälkeinen muuttaminen vaatii pakettien avaamista ja uudelleen paketointia käsipelillä. Tapa 2 soveltuu pieniin projekteihin, joiden ajoympäristö on projektien kehittäjien täydellisessä hallinnassa ja jossa kehittäjän on äärimmäisen helppo viedä pienetkin muutokset suoraan eri testi- ja tuotantoympäristöihin.

Tavassa 3 konfiguraatiomuutokset eivät koskaan vaadi lähdekoodin muutoksia tai binääripaketin uudelleen kasaamista. Kaikki konfiguraatio on erillään varsinaisesta binääristä ja binäärille vain kerrotaan mistä päin sen tulisi käynnistyksen yhteydessä hakea konfiguraationsa. Tämä tapa soveltuu lähes kaikkiin projekteihin eikä ole juurikaan monimutkaisempi toteuttaa kuin tapa 2.

Tapa 4 on käytössä yleensä vain graafisen käyttöliittymän sisältävissä sovelluksissa. Joskus tosin taustaprosessejakaan ei saa niin vaan käynnistellä uudelleen ja niiden konfiguraatiota pitää pystyä muuttamaan ajonaikaisesti. Vaikka tapa 4 kuulostaa parhaalta ja joustavimmalta tavalta sovelluskonfiguraatioon, on sen toteuttaminen kaikelle konfiguraatiolle useimmiten haastavaa ja aivan liian työlästä saavutettuun hyötyyn nähden.

Olen ollut huomaavinani, että Maven filteröintiä käytetään vähän liian innokkaasti sovelluskonfiguraatioon, jossa tavoitteena on tavan 3 joustavuus, mutta sitä yritetään tehdä tavan 2 välinein. Vaikka Mavenin filteröinnillä saadaan helposti tehtyä erilaisia profiilikohtaisia konfiguraatioita, ei filteröintiä voi soveltaa järkevästi kaikelle konfiguraatiolle kuin hyvin suppeissa projekteissa. Esimerkiksi projektissa, jossa varsinaisesta ajoympäristöstä vastaa muu kuin kehitysporukka, täytyisi ajoympäristön ylläpitäjien jatkuvasti kertoa ajoympäristön muutoksista (vaikkapa uusi tietokantasalasana), jotta ne saataisiin sovelluksen konfiguraatioon Maven buildin yhteydessä. Vaikka kehitysporukka vastaisikin kokonaan eri ajoympäristöistä ja asennukset voitaisiin tehdä uudestaan konfiguraatiomuutoksia sisältävän Maven buildin jälkeen, joudutaan joka ajoympäristölle ajamaan erillinen build eri profiililla. Uusi build eri profiililla sisältää riskin siitä, että eri build-tuloksissa on muitakin eroja kuin vain erilaisia filtteröitäviä konfiguraatioita (Mavenin kanssa on helppo mokata tällaisessa erityisesti release-pluginia käyttäessä).

Kun itse lähden tekemään taustaprosessina pyörivää sovellusta (eli suurin osa esimerkiksi selaimella käytettävistä sovelluksista, jotka pyörivät sovelluspalvelimen sisällä), lähden toteutuksessa aina siitä, että konfiguraatioon voi käyttää tapoja 1, 2 ja 3. Jos teen graafisella käyttöliittymällä varustettua sovellusta, otan lähtökohtaisesti tavat 1, 2, 3 ja 4 käyttöön. Yleensä tavan 3 tukeminen on helppo toteuttaa, joten ei ole mitään mieltä jättää sitä pois ja tyytyä vain tapohin 1 ja 2 edes ihan pienimmissä projekteissa. Hyödylliset pienet projektit yleensä kasvavat isommiksi projekteiksi ja tavat 1 ja 2 eivät skaalaudu projektin koon kasvaessa. On kuitenkin huomattava, että mikään esitetyistä tavoista ei yksistään ole yleensä paras tapa. Paras lähestymistapa on tukea ainakin kolmea ensimmäistä tapaa ja tehdä niiden käyttö sovelluskehittäjälle yhtä helpoksi. Näin sovelluskehittäjän on helppo tehdä tekemästään ominaisuudesta halutulla tasolla konfiguroitava.

Apachetop on Amazon Linux

There's handy utility for monitoring Apache logs almost in real time called apachetop. Apachetop shows the traffic your Apache is handling based on the log entries Apache writes. Of course you can read the log files with some file viewer too, but apachetop gives you an overall picture of what's currently happening on your web site, which is not easy to achieve by reading only the log files.

Initially I had some trouble on installing apachetop on EC2 running Amazon Linux, but I managed to do it with these simple commands.

% wget http://www6.atomicorp.com/channels/atomic/centos/5/x86_64/RPMS/libadns-1.4-3.el5.art.x86_64.rpm
% wget http://pkgs.repoforge.org/apachetop/apachetop-0.12.6-3.el5.rf.x86_64.rpm
% yum install libadns-1.4-3.el5.art.x86_64.rpm
% yum install apachetop-0.12.6-3.el5.rf.x86_64.rpm

The commands above download the Centos RPM files and install them using yum. It's better to download the RPMs and install them manually than add some random Centos repositories to your system. Although Amazon is mostly compatible with Centos, it's risky business use standard Centos repositories.

After installing, you can start the apachetop to monitor your Apache. If you have several virtual hosts each writing to different log file, you can add all of them to a single apachetop session. Let's assume you have virtual hosts vhost1 and vhost2, which write logs vhost1_access_log and vhost2_access_log. To monitor both of these, use the following command.

apachetop -f vhost1_access_log -f vhost2_access_log -H 5000 -s 1 -l

I also added some extra parameters here. The -H sets how many total hits the monitoring shows before starting to rotate the log data. The -s sets how many URL path elements are used to distinguish different URLs. For example -s 2 would set mean that /path1/path2/path3 and /path1/path2/path4 would be counted as one URLs. On the other hand, /path1/path3/path2 and /path1/path2/path3 would be different. The last switch -l just says that all URLs should be changed to lowercase before comparing them to each other. Use man apachetop to see more details.

Remote VisualVM session through SSH tunneling

VisualVM is standard Java profiling&monitoring tool that comes with Oracle's SDK. Probably you knew this already, if you have read this far.

Remote VisualVM session through SSH seems to be quite difficult. I found several instructions on how to do it, but they didn't say what to do exactly, especially in my Amazon EC2 environment. The EC2 host we're monitoring here has public elastic IP as well as private IP address.

VisualVM requires SOCKS tunneling instead of standard SSH port forwarding for some reasons I didn't study too well. And anyway, you don't have to know either to get it working...

VisualVM connection setup

1. Create SOCKS tunnel to remote host (in this example it's an EC2 instance)

   % ssh -D 10000 user@remote.host.com

2. Prepare the process you want to monitor. In this case, we're monitoring a Tomcat process so we're adding the following JAVA_OPTS to the Tomcat process. Notice that the JMX port is set to 9000 and this is the port we're connecting to later.

   JAVA_OPTS="...all_the_required_java_opts_here... -Dcom.sun.management.jmxremote.port=9000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
   

3. Start the Tomcat with the JAVA_OPTS given above
4. Create permissions.txt for jstatsd with the following content

   grant {
     permission java.security.AllPermission;
   };
   

5. Start jstatsd process

   jstatd -J-Djava.security.policy=permissions.txt
   

6. Start VisualVM on your localhost
7. Navigate to Tools -> Options -> Network and set there the following values
1. SOCKS Proxy: localhost
2. Port: 10000
8. Check the local IP of the remote host by executing ifconfig (assuming Linux as operating system) on the remote host. The output below is edited slightly to hide some details

   % ifconfig 
   eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
             inet addr:10.1.1.1  Bcast:10.1.205.255  Mask:255.255.255.0
   ...
   

9. In VisualVM, add new remote monitoring session from File -> Add Remote Host
1. Host name is the internal IP address of the remote host, in this case 10.1.1.1
10. Right click the created remote host and select Add JMX Connection
1. The correct value in this example is 10.1.1.1:9000
11. Now you're monitoring should start working! SSH was complaining about connection timeouts, but they don't seem to matter too much

What's important to notice is that public elastic IP does not work in VisualVM connection setup!