Flashing GL865-QUAD's firmware

If you bought a GSM Click board from MikroElektronika, chances are that the GL865-QUAD modem comes with older firmware. That might work for you, but my board came with version 10.00.144, which doesn't support SSL.

The GL865-QUAD chip can be easily upgraded via its AUX serial interface. Note that the AUX port is not the same serial port we use to operate the modem normally via AT commands, and it's actually not broken out to external pins so a bit of soldering is required.

Set up

A quick look at the datasheet reveals the location of the TX/RX pins:

I used a couple of breadboard jumper cables soldered directly to those pins:

To communicate with the GL865-QUAD I used this FTDI USB-serial converter from Sparkfun. According to Telit's datasheet, the AUX port is 2.8V CMOS logic, so I bridged across the two pads next to the 3.3V mark on the FTDI board with a bit of solder:

The GL865 hardware guide states that the absolute maximum input on 2.8V CMOS pins is 3.1V. I found the output of the FTDI chip was slightly over 3.1V, so I simply tied the TX/RX pairs together and hoped for the best. It turned out okay, but if you want to be extra careful, I suggest you use a simple level converter like this:

GL865 pin 45 (TXD_AUX) -------------- FTDI RXD
GL865 pin 44 (RXD_AUX) ----+---|<|--- FTDI TXD
                           |  1N4148
                           /

                           \ 4K7

                           /

                           |

GL865 any GND pin      ----+--------- FTDI GND

The diode will provide the necessary ~0.6V drop so that the FTDI output is within safe levels while the resistor pulls the CMOS input down to 0V when the FTDI TXD outputs a logic 0.

My whole setup looked like this:

Besides the RX/TX cables, I tied both the GL865 and FTDI grounds together (blue cable), and of course you need a 3.3V source to power the whole board. I used some batteries and a 3.3V regulator for this (not shown in the picture above).

Get the firmware

As of today, the latest firmware version is 10.01.140. It's not publicly available neither on Telit nor MikroE's websites, but you can request it directly through MikroE's contact page. Ask them for the XFP tool, too. They answer within 24 hours. The XFP tool runs on Windows, if you are on Linux or OS X you can run it from a Windows virtual machine.

Flash the firmware

With the GSM Click powered off, load up Xfp, select the firmware and hit program. As soon as Xfp says "Linking", power on the GSM Click. It has to be done in that very order. If you hit the program button after the Click has booted, Xfp will stay in a never ending "Linking" loop. It takes about 10 minutes to finish:

Test it!

To check the firmware version you can use the AT+CGMR command, which should output something like this:

--> AT+CGMR
<-- 10.01.140\r\n

And... done!

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. google.com:80)
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.

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.