SecuDroid - Android Anti Theft Loss app Review

SecuDroid - Anti Theft/Loss app for Android

Google is now activating over 500,000 devices each day, growing at 4.4% week on week. This huge raise, led to a big explosion of apps being downloaded from the Android Market, which - at the time of this writing - is 6,148,593,955 (more info at

Among these, there is one particular kind of application which is potentially useful for every single Android user: an app which allows you to locate, track or find your phone in case of theft or loss. SecuDroid is one of those must-have apps which you'd better not need to use, but you'll definitely be glad to have it when somebody steals your phone or you lose it somewhere.


  • Location information including accuracy, speed and altitude 
  • Periodic tracking
  • Silent pictures using either the front or back camera
  • Remote Lock & Wipe functions
  • SIM card change notification 
  • FindMe Ringtone
  • Invisible Mode
  • E-mail integration  


  • How does SecuDroid work?

SecuDroid sleeps silently in your Android device waiting for commands sent from any cellphone by SMS. The answer to these comands will be sent by SecuDroid either by e-mail or by SMS.

These SMS will not show up on your phone because they are intercepted by SecuDroid, so the thief will not suspect that you are on your way to recover your phone.

  • How can I be sure that nobody will be able to track me if I install SecuDroid?

When you request an action from SecuDroid you must precede the command with a password. This password can be changed at any times from the SecuDroid configuration window and, by default, it is set to "PW" (without quotes).  Anyone who knows this password will be able to track you or even wipe your data off your phone.

  • How can I hide SecuDroid so that noone knows that it's there?

SecuDroid will appear as "eNotes" under the installed applications list. Also, you will be able to remove the launcher icon from the configuration window.

  • If I remove the launcher icon, how can I modify the settings?

You'll be able to launch the configuration window by dialing a pre-configured code from the stock phone app. This code, by default, is 3535 but you can change it at any times.

  • Will SecuDroid be able to determine my location even if GPS is off?

In order to switch GPS on, Android enforces the user to do it manually. However, SecuDroid will enable the GPS hardware without user interaction (by tricking the OS) to get the location and, afterwards, it will switch it off automatically to hide itself. Nonetheless, it is highly recommended that you test this feature in your particular device because this is likely to be avoided by Android in the future. In this case, just leave the GPS setting on (no impact on battery life) or you'll only get positions based on GSM towers triangulation.

  • Somebody stole my phone and I want to find out who, will the thief be able to locate the pictures in the phone storage?

No. Pictures are stored temporally without image extensions and they will be erased right after being sent

  • If I take a picture remotelly, will the thief hear the camera shutter sound?

SecuDroid will take pictures silently by disabling the shutter sound. However, some devices are impossible to get the shutter sound disabled due to legal restrictions so you must make sure how your device works by testing it first. You'll probably be able to disable it by some other means like rooting your phone and removing the sound but SecuDroid doesn't encourage you to root your phone unlike other apps.

  • The FindMe function is pretty cool but what if I left the phone in silent/vibration mode?

Just send a BEEP command to your phone and SecuDroid will ring loud for 60 seconds or until you switch the screen on/off no matter what the previous state was. After this command, volume will be set at maximum leve so you're free now to call and find out where the sound comes from

  • Just realized that I lost my phone with critical information. How can SecuDroid help me?

Before trying to track or locate your phone, you should lock it with a password to make sure that noone can access to your sensitive data or even make calls. If you feel that the information inside your phone is even more important than the device itself, wipe the data within a few seconds by issuing a WIPE command.

  • Transparency is really important. Does SecuDroid include any phone-home component that could compromise my privacy?

SecuDroid does NOT include any phone-home component. You can be completely sure that SecuDroid will not connect to a 3rd party server and will not use your location or personal information in any ways.

  • What e-mail account does SecuDroid use to send the pictures and location info to?

You can configure a GMail account from SecuDroid settings window and this will be the account used to send the answers to remote requests. If, for example, this account is removed or you change the password, the answers will be sent back via SMS (or MMS if a picture was requested). The default destination e-mail address is also configured and has not necessarily to be a GMail address.


Campus Party 2011

I'm back from the 15th edition of Campus Party and it was a great success for us regarding the competitions we took part in. Here are the results:

  • Web/Mobile App Development Challenge by Coritel (Accenture) - Innovation Area: 1st place!
  • "Best of Show" Robotics competition: 1st place
  • "Speed Runners" Robotics competition: 1st and 2nd places
  • "Campus Climbers" Robotics competition: 3rd place

CP prizes

I enjoyed very much this edition of Campus Party attending  great conferences  and meeting up with some old friends again and new people into robotics and technology. I'm already looking forward to the next edition and seeing more cool stuff during a whole week in Valencia :)


Drive the uXbot from your Android device

I wrote an application for Android OS based devices to control the uXbot robot remotelly via Bluetooth. This has been my first experience with Android development and, even though the UI creation isn't very straightforward, the rest of the features such as Bluetooth discovering, pairing or sensor data acquisition have been fairly easy.

 uXbot Mobile Manager SplashuXbot Mobile Manager


I'll be uploading some videos in the next few days and, when it's a little bit more tested, I'll be glad to publish the sources so that anyone can add new features (IR sensor readings, battery voltage, firmware uploading using uXbot internal bluetooth bootloader,...).




Silvestre & uXbot - Line Following Champions

Last week, we attended two of the most important championships in Spain with Silvestre and uXbot.


  • In Hispabot, the track had a ramp which was pretty challenging for our robots since they were not designed with this in mind. The major problem was that the robots got blind for a while in their way up and also in their way down. This problem was worse for Silvestre since it's larger and its sensors spent more time in the air, reason why the uXbot managed to get to the top of the podium with Silvestre right behind him on the 2nd place.
  • Robolid hold a really crowded championship with around 80 robots taking part in the robotrackers category and 20 robots in the Line Following contest. Silvestre and uXbot had to fight with most of the best robots in Spain and they finally won with Silvestre in the 1st place and uXbot 2nd.  On a side note, a new electronic system was used during the contest to measure lap times, average and top speeds and Silvestre's top speed was over 5 meters per second (18 km/h)!

The most remarkable features of the robots are:

  • DC Maxon motors
  • FPGA to accurately read the quadrature signals from the encoders and real-time processing (Silvestre)
  • Inertial sensors
  • Track learning: the algorithm takes about 2-2.5 laps to identify when the lap starts over and extract the characteristics and speed-up/braking points.
  • Adaptative behaviour: Throughout the laps, the robots modify their parameters (speed, speed-up/braking points,...) for each part of the track. This allows the robot to adapt themselves to the track conditions (dust, creases, ...)

Below you can see a video from the training days to the final round of the latest contest. Some slow motion parts show how the robots performed over the ramp at Hispabot and how they had to fight with the skids right after the downhill 😉


uXbot Bluetooth Bootloader

I've never liked to use an external hardware to program microcontrollers, so one of the reasons to choose the LPC1343 microcontroller for the uXbot robot was its internal USB MSC bootloader which enables users to download their firmwares by dragging & dropping files into a flash drive. However, when you're working in your robot, sometimes it's a pain to pick it up and plug it to the PC, specially when you're a lazy engineer :-) so here I want to introduce you a tiny Bluetooth Bootloader for the uXbot robot.

Bootloader Flash Layout

As you can see, the bootloader resides at the end of the flash memory and whenever the user code jumps into it, it copies itself to RAM before starting the flashing process. This way, the bootloader can also be updated from the bootloader itself :-) In the video below you can see a demo of the bootloader in action. From the uXbot Manager PC application the firmware is downloaded into the robot's memory (via Bluetooth, of course) and the new code can start running right after the process is completed (less than 2 seconds to download a ~2KB firmware).  The user code jumps into the bootloader whenever the button is pressed but the application can enter the bootloader remotely or by any other means.

Stay tunned.


ARM Cortex-m3 - Remote debugging using GDB (1)

One of the things I've found more interesting and useful in Robotics is debugging.

Most of the time we use to print out traces through a serial port and, the luckiest ones, who own a JTAG emulator, can dig deeper into their bugs but always with a cable plugged.

So, now thanks to the excellent Espardino project and the help of its author, Ajo, who is a very good friend of mine, I decided to write my own stub for the ARM cortex-m3 architecture. You can check out more information about Espardino's remote monitor here.

Also, the following are a nice source of information I used to write this stub:

The video below shows a debugging session of the stub running inside the LPC1343 ARM Cortex-M3 of the uXbot robot. The GDB is connected to a tiny application which acts as a bridge between the TCP connection and the bluetooth link to the robot. Given that this application is listening on a TCP port, the GDB debugger can be running somewhere else (on my iPhone? ;)) and it would still work.

In my next article I will get more into detail about the stub itself and the exception handling.


SPI Communications - Slave Core VHDL

SPI (Serial Peripheral Interface) protocol is a synchronous serial data link which operates in full duplex mode. It's got a higher throughput compared to I2C or SMBus  and it's very useful for high speed short-range communications.

The SPI protocol specifies the following signals:

  • SCLK — Serial Clock (output from master)
  • MOSI/SIMO — Master Output, Slave Input (output from master)
  • MISO/SOMI — Master Input, Slave Output (output from slave)
  • SS — Slave Select (active low, output from master)

All lines can be shared for every slave device in the bus except the Slave Select signal which has to be different (out of band selection) for each slave.

This is the basic operation depending on the CPOL and CPHA values:


The SPI core I've implemented is fixed for Slave and CPOL=0/CPHA=0 modes. This means that the MOSI line will be sampled at every rising edge of the SPI Clock whilst the MISO signal will be set right before this rising edge (actually, on the falling edge) so that it can be properly sampled by the Master.

SPI Module

As the FPGA will have its own clock, we'll be having two different clock domains since the SPI master signals will be generated externally and they won't be necessarily synchronized to the FPGA internal clock. Thus, the approach will be sampling all the external signals to get them synchronized and using two shift registers for input and output data.

 Source code:

entity spi_slave is
  port (
    RESET_in    : in  std_logic;
    CLK_in      : in  std_logic;
    SPI_CLK     : in std_logic;
    SPI_SS      : in std_logic;
    SPI_MOSI    : in  std_logic;
    SPI_MISO    : out std_logic;
    SPI_DONE    : out std_logic;
    DataToTx    : in std_logic_vector(7 downto 0);
    DataToTxLoad: in std_logic;
    DataRxd     : out std_logic_vector(7 downto 0)
end spi_slave;

architecture Behavioral of spi_slave is

    signal SCLK_latched, SCLK_old : std_logic;
    signal SS_latched, SS_old : std_logic;
    signal MOSI_latched: std_logic;
    signal TxData : std_logic_vector(7 downto 0);
    signal index: natural range 0 to 7;
    signal RxdData : std_logic_vector(7 downto 0);


 -- Sync process

  process(CLK_in, RESET_in)

    if (RESET_in = '1') then
      RxdData  '0');
      index <= 7;
      TxData  '0');
      SCLK_old <= '0';
      SCLK_latched <= '0';
      SS_old <= '0';
      SS_latched <= '0';
      SPI_DONE <= '0';
      MOSI_latched <= '0';

    elsif( rising_edge(CLK_in) ) then

      SCLK_latched <= SPI_CLK;
      SCLK_old <= SCLK_latched;
      SS_latched <= SPI_SS;
      SS_old <= SS_latched;
      SPI_done <= '0';
      MOSI_latched <= SPI_MOSI;

      if(DataToTxLoad = '1') then
          TxData <= DataToTx;
      end if;

      if (SS_old = '1' and SS_latched = '0') then
          index <= 7;
      end if;

      if( SS_latched = '0' ) then
         if(SCLK_old = '0' and SCLK_latched = '1') then
            RxdData <= RxdData(6 downto 0) & MOSI_latched;
            if(index = 0) then -- cycle ended
               index <= 7;
               index <= index-1;
            end if;
         elsif(SCLK_old = '1' and SCLK_latched = '0') then
            if( index = 7 ) then
               SPI_DONE <= '1';
            end if;
            TxData <= TxData(6 downto 0) & '1';
         end if;
      end if;
     end if;
   end if;
   end process;

   -- Combinational assignments

   SPI_MISO <= TxData(7);
   DataRxd <= RxdData;

end Behavioral;

In order to test this core I wrote a simple testbench wich basically waits for a command from the master and answers it. This will serve as a base for the microcontroller code which will send this same command (0xA0) and wait for the answer (0xA4). This is the simulation view:


As you can see, when the spi_done signal goes high, the datarxd register is loaded with the value 0xA0. Afterwards, the answer to this command (0xA4) is loaded into the datatoxload register and the MISO line is set to the right bit at every falling edge of the SPI clock signal.

As the simulation looks good, I decided to wire up the FPGA to an LPC2148 microcontroller and test the SPI core for real. The following code will run in the LPC:


void send_fpga_cmd(unsigned char cmd)
    unsigned char dummy;
    IO0PIN &= ~(1<<11);    // Select FPGA
    while ( !(SSPSR & 0x02) );
    SSPDR=(unsigned int) cmd;
    while((SSPSR & (1<<4)));
    IO0PIN |= (1<<11);    // deselect FPGA
    dummy = SSPDR;         //flush the RxFIFO


unsigned char read_fpga_byte()
    unsigned char data;
    SSPDR= 0xFF;         // write dummy data out to gen clock
    while((SSPSR & (1<<4)));
    data = SSPDR;
    return data;

    data = read_fpga_byte();

I configured the SPI bus to run at 2MHz on the microcontroller. Here you can see the logic analyzer output which shows that the SPI core works as expected.


As you can see, the microcontroller sends a ping (0xA0 byte) and the FPGA answers with a response command (0xA4 byte). The SPI clock frequency is exactly 2.000MHz and the behavior is the expected one.

Silvestre FPGA - SPI Test
Silvestre FPGA - SPI Test


FPGA - Actel ProASIC3 First Steps

I want to show you how easy is to start playing around with FPGAs. The following example is based on the Actel A3P250 Devel board programmed with the microJTAG board.

The idea is simple: we're going to design a PWM module and make the on-board leds flashing at different rates. The RTL design of the PWM module is shown in the picture below:

PWM component RTL

Let's have a look at the components inside the PWM module:

PWM Module RTL

As you can see the 10-bit PWM module has got one register, a 10-bit counter and one comparator. To test our module, I'll write a simple VHDL code:

-- test.vhd
library IEEE;

entity example2 is
    Port (

                LEDS:out STD_LOGIC_VECTOR(3 downto 0);
                CLK_in: in STD_LOGIC;
                RESET_in: in STD_LOGIC

end example2;

architecture Behavioral of example2 is

component pwm is
    Port (

        CLK_in:     in std_logic;
        PWM_in:     in std_logic_vector(9 downto 0);
        PWM_load:   in std_logic;
        PWM_reset:  in std_logic;
        PWM_out :   out std_logic

end component;

      signal counter: natural range 0 to 48000;
      signal result: STD_LOGIC_VECTOR (9 downto 0);
      signal pwmout: STD_LOGIC;
      signal clk_div: std_logic;


    pwm1 : pwm port map ( CLK_in => CLK_in, PWM_in => result,
 PWM_load => '1', PWM_reset => not RESET_in,
 PWM_out => pwmout);

         if (RESET_in='0') then

            counter <= 0;
            clk_div <= '0';

        elsif (CLK_in'event and CLK_in='1')    then

            if (counter = 47999) then
                clk_div <= not clk_div;
                counter <= 0;
               counter <= counter + 1;

            end if;
        end if;

    end process;

    process(clk_div, result)
        if (clk_div'event and clk_div='1')    then
            result <= result + 1;
        end if;

    end process;

    LEDS <= (others => pwmout);

end Behavioral;

The frequency divider makes the 'result' signal increment every 48K*2 ticks of the main clock (24MHz). The 'result' signal is connected to the input of the PWM module which will load its value every time it changes because the LOAD signal is always '1'.

The result will be that every 4ms, the PWM input will increment by 1 from 0 to 1023 (10 bit value). The PWM output - which is connected to all LEDs in the  board - will take all values after 4 seconds and the cycle will repeat continuously.

You can download the whole source code from the link below:

VHDL Source code

The A3P250 Devel kit was a present from my friend Ajo and I want to thank him for such a nice board :)


CRJET 2010 International Robotics Competition

Last 8th October took place the 3rd edition of the CRJET International Robotics Competition in Cataluña.

Silvestre was the WINNER of the Line Following Robots category. During the qualifying session in the morning, Silvestre set the fastest time, completing 3 laps to the 11.752 meters track in 14.02 seconds (2.5m/s average speed). Piolin - Silvestre's little brother - made the second best time at qualifying but had some issues and got a final 3rd place losing against Shibuya in the Semifinal round.

CRJET 2010 Qualifying results    CRJET 2010 Track

Its revolutionary positioning system allowed Silvestre to identify the main straight and to speed up to 4.8 m/s. Thanks to its inertial sensors and the wheel encoders, Silvestre could brake at the right point reaching the corner at a safe speed. This strategy had not been seen in any Line Follower competitions so far making Silvestre look even more impressive.

 Silvestre Highlights (the slow motion part is very cool 😉 )

Final Race, Silvestre VS Shibuya:

For the next contests, the challenge is to make another key improvement to keep Silvestre on the top of the podium.

Also, Tobias was awarded with the "Most High-Tech" prize in the "Best of Show" category so it was a pretty successful weekend :)


Silvestre - Line Following Robot

Silvestre Robot

Silvestre is a line following robot who was born early this year. So far, he's competed in two national contests in Spain achieving a 5th place in the first one and winning the other one.Among his main  features:

  • 8 Infrared sensors
  • Two Maxon DC motors
  • Bluetooth enabled (telemetry and configuration)
  • LPC2148 ARM7 32-bit microcontroller
  • PD Loop running at 100Hz
  • Error estimation using cubic interpolation over the IR sensors data
  • Accelerometer and gyro sensors

In the video above you can see Silvestre running on a 8.44m long track. Whenever he crosses the mark, sends the lap time over the Bluetooth link to a PC software which displays the timing information along with some other data such as battery level. In the best lap in the video he can reach up to 2.24m/s and as long as the wheels become dirty, the grip decreases and therefore, the times get worse.

The microcontroler's got 512KB the flash. Half of this memory's currently holding a custom filesystem to store configuration profiles (speed, PID constants, enabling/disabling features, etc.) which can be loaded, stored and deleted through the PC software.

In order to speed up the communication between the computer and the robots we designed a low bandwith binary protocol with error correction which's been implemented and optimized carefuly in all of our robots. This way, the development of new software (for both robot and computer side)  gets simplified from the communication point of view and there's no need to start over again every time. You can see an screenshot of the PC application we've built:


RL-Telemetry application

The inertial sensors help Silvestre to measure how good he's performing and enables him to adjust the speed and PID constants as  the wheels are losing grip. Basically, the accelerometer data is used to accelerate faster to the setpoint speed whereas the gyro tells him whether he starts drifting (too much angular acceleration).

In the contests being held in Spain, there are no marks indicating when a lap has started so there's no way for the robot to figure out when to modify its parameters  so something that might be useful as well with the gyro data is to be aware of the actual orientation of the robot. Thus, integrating the gyro signal, Silvestre knows when he is facing the initial position again and this is likely the starting point. However, this approach is not valid when the track's got two or more straights in the same direction because the robot will get to 360º and the lap's not been completed yet.

The key for improving Silvestre's performance has been undoubtely the ability to gather data from the sensors in real-time so that they can be later analysed on a computer.

My friend Alberto Calvo and me have worked hard on this robot and we're looking forward for new contests and challenges. Our main goal, rather than just following a line, was researching how the usage of inertial sensors and self-learning processes could be applied on this kind of robots.  We're still working on Silvestre in our spare times so I'll probably update this post soon.