Friday, August 8, 2014

GSM Click + Arduino

I'm working on a hobby project that involves sensing environmental data and uploading it to the Internet using Arduino and a GSM/GPRS receiver. There is a range of GSM shields and standalone modules to choose from. For this particular project I went for the GSM Click module from Mikroelektronika. It's probably not the most affordable GSM module out there but I like it because it has a nice protoboard friendly layout and a smallish footprint. It's also widely available (I've got it from Newark CA).

Mikrolelektronika actually has two modules that are similar, the GSM Click and the GSM2 Click. Each one is based on a different GSM chipset (Telit on the GSM, Quectel on the GSM2), but both are quad-band and support GPRS.

The interesting thing about these modules is that they have a full TCP/IP stack built-in, and they even support high level protocols such as HTTP and DNS. Imagine implementing all that in an Arduino with 32K of flash and 2K of RAM... So the workflow for an HTTP request in these modules is actually very simple:

  1. Unlock the SIM via PIN
  2. Wait for network registration
  3. Start a GPRS connection
  4. Open up a connection to your server:port (ie.
  5. Send / receive data
  6. Close the GPRS connection
Steps 1 and 2 are done during initialization, and as long as the module stays registered, new requests would only require 3..6. Most of the steps can be done with single AT commands.

Electrically, I/O pins in the GSM Click support both 3.3/5V levels, but it does require a 3.3V power source. It took me an hour of frustration before I realized this. According to the datasheet of the GL-865 chip, the module can draw a maximum average ranging 140-330 mA (depending on the band and GPRS class), however they state the power supply must be designed to withstand a peak demand of 2A. This means you can't use the 3.3V source from most Arduinos because they are rated for much lower current, you need to provide your own 3.3V regulator.

The module comes preconfigured for 3.3V I/O operation. If you want to connect it to 5V devices you need to unsolder an SMD jumper and then resolder it across the 5V label.

In addition to the 3.3V power source you also need 5V (you can take this from the Arduino, it's used just for level conversion), GND and TX/RX. The module's TX goes to the Arduino RX and viceversa.

I've used SoftwareSerial on pins 2/3 to talk to the module so that I have the hardware UART free for debugging. However, when using both ports at the same time, incoming data from the GSM module gets massively corrupted. I believe either of them alone would work fine, but it's still early to say.

In the next post I'll show a more detailed connection schematic and some test code to do basic HTTP communication.

Monday, April 7, 2014

Changes in firmware 1.5

Version 1.5 of the Trackuino firmware is out! It fixes some bugs reported mainly through email and the hab-ham forums.

One of the longest-standing issues was compilation with Arduino 1.0+. This has been fixed in many forks out there, so it was about time it made it to the official code. The 1.5 firmware has been tested with the following IDEs:
  • Arduino 1.0.5 (build tested on an Arduino Duemilanove)
  • Arduino 0023 (build tested on an Arduino Duemilanove)
  • Mpide 0023-20130715 (build tested on a Chipkit Uno32)

Another issue was regarding readability of the signal. You can read this thread for background, but in essence some TNCs have problems decoding the signal when there is a significant amount of imbalance between the 1200 and 2200 Hz tones, no matter how clean the signal is in SNR terms. This problem has been thoroughly described by John Ackermann N8UR in this article.

The problem boils down to the following: usually FM transmitters emphasize the high frequencies of the base band. They do so to improve the immunity to noise and overall SNR of the signal. To counteract this effect, receivers, in turn, de-emphasize the received signal so that the end result is a spectrogram that closely resembles the original.

HX1 modules, however, don't have such a pre-emphasis network. Thus, the power of the 1200 and 2200 Hz tones is distributed equally over the air, but receivers will attenuate the 2200 Hz tone largely, resulting in a signal that some TNCs can't decode. Here is a an example of a Trackuino transmission received by an Icom IC-229H, then fed to my poor man's oscilloscope (Audacity). See the amplitude difference between the two tones?

Now, when you transmit from a balloon, the coverage area will be huge even for 300 mW, so chances are that some receiver or another will successfully decode the signal. On the ground, however, your packets might struggle with local receivers.

The solution is to de-emphasize the 1200 tone, which translates into an emphasis of the 2200 one in relative terms... It's impossible to boost the 2200 either in circuitry or in software because the HX1 is already being driven through its full 0..5V range. This will bring other issues like FM undermodulation (the received amplitude will be lower), but it should improve the overall equalization of the signal.

The same transmission with relative emphasis of the 2200 tone:

Pre-emphasis can be turned on in config.h by setting the PRE_EMPHASIS flag to 1, and is now the default setting.

The other issues addressed by this version are:

Baud rate accuracy

Due to accumulation of rounding errors in the modem code, the baud rate was actually 1201.92 bps on 16 MHz Arduinos. This is within the tolerance of all the receivers I've tried, but it could get worse depending on the actual CPU clock. Version 1.5 uses fixed point arithmetic to achieve a baud rate that is consistently closer to the nominal 1200 bps regardless of the clock speed (1200.03 bps @ 16 MHz).

Simpler modem ISR

I've slimmed down the modem ISR so that the chances of interrupt overrun are lower. The AFSK code now runs asynchronously in the main loop and the samples are fed to the ISR via a FIFO queue. This makes the AFSK code easier to debug, too.

If you have any question or bug report, you are welcome to post it in the hab-ham forums.

Tuesday, August 28, 2012

New shield (2.2 BETA) and firmware (1.4) are up

If you have tried to build a Trackuino board, you will have noticed that the Venus GPS part from Sparkfun (GPS-09133) has been retired and replaced with GPS-10921, which has in turn been replaced with GPS-11058.

Unfortunately, the engineers at Sparkfun have deemed necessary to reshuffle the pinout and make the newer board incompatible with existing designs that used the older boards, including Trackuino. I'm still puzzled at this decision, this is like the 7805 reversing in and out just because it "makes more sense".

If you already have a board designed for GPS-09133 or GPS-10921 and want to use GPS-11058, there are two solutions: either run small cables instead of pin headers, or build a small adapter board to rearrange the messed-up pins.

The GPS chip has also been replaced (634FLPx becomes 638FLPx), but this should not be a problem.

Although I plan to run away from this problematic part, I have uploaded the Eagle files of a new design that is compatible with GPS-11058. Look for in the downloads area.

I have not tested this design yet. I will remove the "BETA" label as soon as I get some boards tested.

Since I haven't built any 2.2 board yet, all I can show is this nice 3D rendering from mayhem labs:

The complete feature set of the Trackuino Shield 2.2 is:

  • Replaced Venus GPS 634FLPx (sparkfun #9133) with newer 638FLPx (sparkfun #11058).
  • Auto 3.3/5.0v operation for Chipkit Uno32 compatibility
  • Eagle files converted to 6.x format.
  • Use Arduino's own 5V regulator to power the HX1.
  • Replaced TO220 3.3V regulator with SMT + board sink.
  • Added bleeder resistor for passive piezo speakers.
  • Battery (Vin) sensing (through a resistive voltage divider).

Matching this new shield, there is also a new firmware version: in the downloads area. The new features are:

  • NEW: Support for PIC32 / Chipkit Uno32 platform
  • NEW: Support for active or passive buzzers (DC or PWM driven)
  • NEW: Battery voltage sensing
  • NEW: Slotted transmissions for multilaunch events
  • REMOVED: Support for the MX146 radio

Find more information in the project page at google code, and enjoy!

Saturday, December 17, 2011

The amazing flight of K6RPT-11


This was about 3 days ago. The California Near Space Project (CNSP) team launched 4 balloons. Two of them were short-duration, high-altitude flights. The other two were long-duration floaters (K6RPT-11 and K6RPT-12). First, the announcement:


Our goal is to reach neutral buoyancy at a very high altitude and fly as far across the United States as possible.


The balloon not only made it through north america. It completely crossed the Atlantic, entered Spain through Jerez de la Frontera and exited towards Italy. After a 57 hours flight, it eventually descended on the Mediterranean sea off the coast of Algeria.

Captura de pantalla 2011 12 16 a las 09 33 40

Look at the green portion of the trajectory after the balloon passed New Jersey. These were quiet hours of uncertainty until the signal was picked up again from the Azores:

Captura de pantalla 2011 12 16 a las 09 35 37

Launch time was 2011-12-12 00:40:31z. The last packet was heard on 2011-12-14 09:46:30z:

Captura de pantalla 2011 12 16 a las 09 34 29

You can see the full trajectory on while it's recent:

Update: Below is a video of the launch:


Sunday, September 25, 2011


¡Gracias a todos los asistentes a mi charla sobre fotografía espacial en la conferencia OSHWCON 2011 y sobre todo a los organizadores por darme la oportunidad de exponer el proyecto! Espero que se repita y nos podemos ver con más proyectos el año que viene. Para cualquier duda me podéis localizar en el correo javi en trackuino punto org. ¡Un saludo!

(ENG: Thanks to all who attended my talk at OSHWCON 2011 and especially to the organizers for the opportunity to present my project! Keep it up and hope we'll see more projects coming next year!)

Tuesday, August 2, 2011

Important fix in version 1.31

Version 1.3 of the Trackuino firmware had a bug by which altitudes over 32767 feet would be rolled over to negative values. A new version fixing this issue is available in the downloads area. No extra features have been added, so your "config.h" from previous version 1.3 can be reutilized verbatim.


Saturday, July 30, 2011

How NOT to launch a balloon

The neck snapped when the balloon turned upside down. We were planning to release the load line slowly so that the strings would not rip through the payload box, completely oblivious that the weakest point was the neck of the balloon :(