Tuesday, 23 December 2014

EFCom Pro GSM connecting to Arduino

I ordered the EFCom Pro GSM module this month and to be honest it was beyond "fun" to get it working. Being cheap I ordered it for half of what the official Arduino GSM modules goes for so was determined to get it to work (even though the documentation available at present pretty much doesn't exist.

Arduino software serial has a limit of 38400 in baud rate due to the processing that would be required for faster baud rates. Unfortunately the EFCOM GSM Pro comes with auto-bauding enabled (mine seemed to always go to 115200) - causing insane headaches for anyone trying to connect it to an Arduino. 

You may be getting funky characters, a favourite seems to be y...

The sketch below seemed to do the trick, after a power off/on cycle the GSM came back at 19200. To do this you need to use the hardware pins on the Arduino, I have the Arduino UNO so pin 0 for RX (connects to the GSM module's TX pin) and pin 1 for TX (connects to the GSM module's RX pin), then I loaded the ugly sketch:

void setup()             

void loop()                   
  if (Serial.available()){

The above sketch could be skipped if you plan to keep using the pin 0 and pin 1 on the Arduino at 115200. The GSM module should flash a light every 3 seconds to indicate it's on a network and that part is okay.

You can also connect the RST from the EFCom Pro to a digital pin, in my case pin 5 and PWR I connected to pin 6. I connected two switches, the aim was to send an SMS when either switch was triggered and a voice call with if the first switch was triggered.

The example sketch is below:

const int switchOne = 2;     // Digital 2 -> Door switch 1
const int switchTwo = 4;     // Digital 4 -> Door switch 2
int switchOneState = 0;
int switchTwoState = 0;
int messageOneSent = 0;
int messageTwoSent = 0;

void setup()
 //Serial.print("Setup complete...\n");

 digitalWrite(6, LOW);   // Turn the GSM Modem OFF - connect PWR from GSM board to pin 6 digital
 digitalWrite(6, HIGH);   // Turn the GSM Modem ON
 //digitalWrite(5, LOW);  // Reset the GSM Modem - connect RST from GSM board to pin 5 digital

 pinMode(switchOne, INPUT);
 pinMode(switchTwo, INPUT);

 delay(20000);//Wait for GSM to come online
 send_message("GSM system has been turned on and is ready...");

void loop()

 switchOneState = digitalRead(switchOne);
 switchTwoState = digitalRead(switchTwo);

 if (switchOneState == LOW){
  //Switch one
  if (messageOneSent == 0){
   send_message("Door one closed :-)\n");
   messageOneSent = 1;
  }//else don't keep sending for a determined condition
 } else {
  messageOneSent = 0;

 if (switchTwoState == LOW){
  //Switch two
  if (messageTwoSent == 0){
   send_message("Door two closed :-)\n");
   messageTwoSent = 1;
  }//else don't keep sending for a determined condition
 } else {
  messageTwoSent = 0;

void send_message(char msg[255])
  //Serial.print("Sending message:");
  delay(100);                    //Wait for a second while the modem sends an "OK"
  Serial.print("AT+CMGF=1\r");    //Because we want to send the SMS in text mode
  Serial.print(msg);   //The text for the message
  Serial.print(char(26));    //Because we want to send the SMS in text mode

void voice_call()
  Serial.println("ATD + +27xxxxxxxxxx;");
  Serial.print("ATD + ATH");

The amount of time the module takes to register on the network does vary, on Cell C in South Africa it took around 8 seconds before I could start sending messages. Sending an SMS however took about 5-7 seconds, so I have a delay of 10000, ideally I should have a loop checking for serial available but it wasn't such a complex project that required the additional code.

Another issue I encountered was the power requirement for the GSM module, many websites including the official one claims a need for a 2A supply (testing I couldn't get it to consume more than 0.1A).

I followed the advice nonetheless and powered both the Arduino and GSM module from a 5V 3A supply (the smallest I had in the cupboard above 2A) - just remember that the serial comms rely on having a common ground so if you power the Arduino from USB and the GSM module from a supply the serial seems to be a complete failure.

Hope the above helps someone not pull out as many hairs as I have...

Wednesday, 21 May 2014

ADS-B Virtual Radar Lab Project

If your like me and have always wanted your own "virtual radar station" your in luck!

I recently managed to get my hands on an awesome RTL2832U+R820 powered USB dongle. Although it's intended for DVB-T reception this dongle will open a new world for you between 24 - 1766 MHz

Back to the aircraft... basically many planes are equipped with ADS-B (many more in the future will also be) and send out great nuggets of information on 1090 MHz, including identification, altitude, velocity, GPS location.

If you have your own RTL2832U dongle you can give it a whirl using gnuradio (apt-get install gnuradio), and the downloading dump1090 (git clone git://github.com/antirez/dump1090.git) then cd into dump1090 and type: make <enter>

Once dump1090 has finished compiling your ready to give it a try: ./dump1090 --interactive (this should display a list of aircraft detected in your area - if any are available)

To run dump1090 in the background and enable the web based view:

dump1090 --net --net-http-port 80 --modeac --enable-agc

You can at this point also share data with sites like FlightRadar24 (our station code is T-FAWB4) or plane plotter - I'll dedicate a blog post to this.

Sample of dump 1090 raw output, the ICAO address is unique to the aircraft and doesn't change (not true for planes like Air Force 1 though, with good reason). You can use this address at AirFrames to find additional information about the aircraft if the registration is unknown.

CRC: 000000 (ok)
DF 17: ADS-B message.
  Capability     : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
  ICAO Address   : 00b026
  Extended Squitter  Type: 12
  Extended Squitter  Sub : 0
  Extended Squitter  Name: Airborne Position (Baro Altitude)
    F flag   : even
    T flag   : non-UTC
    Altitude : 29175 feet
    Latitude : -25.793839
    Longitude: 29.648132

It is also normal to receive output without a call sign or other details, it could be that these have simple not been received or arn't being transmitted.

The project turn out to be more like a hobby at the end of the day but very rewarding, the parts used also turned out to be a global collaboration:

1. Antenna from Bulgaria
2. Surge protector also from Bulgaria
3. Aluminium enclosure from China
4. Curtain rod as antenna pole from South Africa
5. Antenna bracket from South Africa
6. N-Type connectors from Germany
7. LMR-400 cable from India
8. RTL2832U USB dongle and hub from China
9. Raspberry Pi from the UK
10. Heat sink from some trashed amplifier
11. Old Cisco power supply for 5 volt

Please comment if you'd like any more information on the project.

To view it online visit: Monitman and click on the Lab link.

Raspberry Pi Model B

N-Type Connector

Surge Protection
- Update to this post -
I used a Cisco 1720 power supply, it outputs 5V and I simply jumped the required cables to fool it to switch on. I power both the Raspberry Pi (now a model B+), USB hub and the dongle with it.

The extra cables were simply for some future expansion I had planned but never got to, the one antenna is for ADS-B and the other a normal WiFi one I use to play around with.

I'm adding a few more goodies into the box at the moment and will post more soon!

Friday, 14 March 2014

NTP the *#x+ does that mean?

Linux command ntpq should have defined it's columns within a man page but left it to the Internet to remember, so this page is dedicated to me staying sane:

The character in front of server hostnames from ntpq -p
" " Unresponsive peer, high stratum, Local
* The peer currently being used for time sync
# Fail over peers ready to take over in case one of the first six + peers fail
o Good peer using PPS
+ Good peer and has been included in the final set
Out of threshold, usage discarded
x Out of threshold, usage discarded

refid - how does the remote peer sync time? Popular options:

LOCL - This local host
GPS - GPS satellites, atomic clock source
PPS - Pulses Per Second, mostly from applicable GPS receivers
CDMA - Mobile phone networks using CDMA

st column - stratum of the remote peer

t column:
l = local time source
u = unicast (almost always this is true)
m = multicast
b = broadcast

when - last polled, default in seconds (h - hours, d - days)
poll – how often to poll peer
reach – 8-bit left-shift register - 377 for a perfect peer, 0 for a useless one
delay – Round trip time in milliseconds
offset – The difference for this peer between the local time and the weighted average of our set of peers
jitter – The variance in latency on the network to peer

Hope the above helps someone!

Wednesday, 5 March 2014

Load balancing interfaces on Debian/Centos using round Robin

Nothing like holding a IBM server worth more than your car in your hands (and thinking - do not drop it repeatedly... :-)

So basically we have two of these awesome servers ready for action, ample network ports, and a need to communicate directly with each other... which leaves only one geek option :-) - lets bond those free interfaces and kick some ass and speed and failover wise!

I know you can define the following in config files but with one server in production mode I couldn't afford a network restart going wrong (additionally I'm 50KM away from the facility in Johannesburg).

Instead I opted for the command route and adding them to /etc/rc.local in the rare event a server reboots. The commands (I was using eth2/eth3 so it may need tweaking for re-use).

If you experience any issues with more than 2 ports it may require a change to ALB mode (balance-alb) which load balances transceived frames using a MAC change method.

Application Server - Centos - installed by default?:
modprobe bonding mode=balance-rr miimon=100
ifconfig bond0 netmask up
ifenslave bond0 eth2
ifenslave bond0 eth3

Database Server - Debian - package: ifenslave-2.6:
modprobe bonding mode=balance-rr miimon=100
ifconfig bond0 netmask up
ifenslave bond0 eth2
ifenslave bond0 eth3
ip a add dev eth1
ip link set up dev eth1

The results:

[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  2.13 GBytes  1.83 Gbits/sec


Monday, 6 January 2014

Server uptime!

While going through my timesheet for this months billing I noticed the following blob I copied from a companies IBM server, pretty impressive:

12:27:22 up 707 days, 12:14,  2 users,  load average: 0.44, 0.45, 0.48

Ubuntu 8.04.2 \n \l

Linux www 2.6.24-23-server #1 SMP Wed Apr 1 22:14:30 UTC 2009 x86_64 GNU/Linux

Chain OUTPUT (policy ACCEPT 3868M packets, 4572G bytes)