Using Telecom Design's TD120x as a SIGFOX gateway with a Z1 mote

As mentioned in an earlier post, I recently got a demo kit from SIGFOX and finally I had some time to start playing with.

I had a head start and told that the starter kit was based on Telecom Design TD1204, which provides a serial AT-based modem to allow communication over a serial link, so it made easier testing using software tools like PuTTY, Hercules and then moving to a Zolertia Z1 mote to drive the TD1204 over its serial port (at the end of the post!).

Note: You need to have a device registered in the TelecomDesign cloud or the SigFox backend for some of the following steps, but nevertheless is is interesting to watch and to take a peep inside.

 

SIGFOX Back-end

I started by browsing the web-based SIGFOX backend, by clicking on the Device tab (as shown below) we can see the devices associated to our account, my starter kit device appears listed there.

I work in Barcelona, so I was interested in checking if my workplace is under SIGFOX coverage area, so by clicking the Location tab at the left it is shown an approximate coverage map.  (btw, I have tried pushing a message while at home in Cerdanyola del Vallès, but it didn't reach the network, but generally in Barcelona the coverage is OK).  At first glance it made more sense to me to represent the light blue area as a circle rather than using a square, but as I'm not sure of how this is modeled, it is fine as it is at the moment.

 Then the moment of truth, let's see what happens when I long-press-and-hold the button... once or twice to be sure, the message board is updated showing the content of the test message... I don't understand what the data means (180c62, 190c62), but I have a good idea about the rest of the fields...

• Delay: Time (in seconds) elapsed since the message was triggered and then received by the network station.
• TAP: Station receiving the message, as these stations are fairly identified you can get the estimated location of your device (a way estimated location).
• RSSI: Received Strength Signal Indication: as shown we have values ranging from -124/-128dBm, as it was already discussed in my previous post, the sensitivity value is expected to be quite low, as the wireless range is favored by the low data rate and bandwidth.  In the  TD1204 EB page the sensitivity value is stated to be close to -126dBm, as we are using a 5dBi external antenna we can expect a boost (in one occasion I got a RSSI value of -132dBm, so this approximation seems to be OK).
• Signal (dB)
• Freq (MHz): channel used in the transmission, as shown above the channel is changed for every retransmission attempt.
• Rep: Numbers of retransmission attempts needed for the packet to actually arrive to the network.
• Callbacks: Event triggered upon receiving the packet, below is an example of the callback generated by the user-button event (an email is sent every time to a given email address):

          [OK] - TAP 0146 - 1 second

     200 -
     {device} (name@mail.com)

The maximum transmission power of the radio transceiver is 14dBm (for the TD1204 DK), but it would be interesting to check if SIGFOX allows devices to be on the ETSI G3 sub-band (869.4-869.65 MHz 500mW), one thing pending to confirm (in my previous post I assumed so).

 

Hands-on: connecting SIGFOX to a Z1 mote 

So OK, enough of using the user button and the backend (we will return to this later when setting callbacks and stuff), now let's move to the meaty part of the testing: sending a custom string message.  After checking the TD 1204 reference manual, I found the required serial settings to connect the starter kit to the PC:

• Speed 9600 bps.
• 8 data bits.
• 1 stop bit.
• No parity, no hardware/software flow control.

I first tested the serial communication using Hercules and the result was OK as expected (remember to add a carriage return at the end of the string, more information about the command/response expected format is found in the TD1204 reference manual, section 2.4).

.

After verifying the serial communication then I moved to wiring the starter kit to the Z1 mote.

At first It seemed a good idea to cut-off the male USB connector of an USB male to mini-USB cable, strip the wires and solder those to the Z1 mote, wiring D+/D- to the UART1's RX/TX (P3.7/P3.6), and power the starter kit by soldering GND/VCC to the Z1's USBGND/USB+5V (requiring to power the Z1 through its micro-USB port)... but this was a rather bad idea, as I noticed when connecting the TD1204 to the PC that it uses a FTDI chip, which are normally slaves thus requiring a master to communicate.  The Z1 mote has a CP210x serial-to-USB converter too, but my original intention was to use raw serial communication using a free UART port of the Z1 mote, so its USB port (wired to UART0) can be kept as a programming/debugging port, avoiding to use the JTAG port instead.

So the next logical step (off course, without a doubt) was to void the warranty and take a peek inside the demo kit... I love voiding warranties :-)

Finding the FTDI reference (FT232R-L package) chip was easy, as suspected there's a battery charger/Modem enabling circuit, a 1000mAh LiPo battery and the user button on one side, on the other we can see a TD1202 radio transceiver and AT-modem (sending an AT&V command is also a good way to find out about board-specifics).

Next I needed to locate the serial RX/TX lines going to the TD1202 transceiver to bypass the FTDI, following the FTDI pin-out and the PCB trace I noticed there were 2 0Ohm resistors standing between the FTDI and the modem, a nice gesture as it only required to apply a little heat and lift-up the resistors instead of cutting the PCB.  

The location of the RX (red), TX (white) and GND (black) pads are shown above, as well as the location of the resistors.  We cross-wired the Z1 and TD1202 RX/TX lines, and the DGND pin of the Z1 to GND.

I could also directly power the TD1202 using the Z1's 3.3V power reference, but honestly I was more interested in testing the communication between the Z1 and the board, than worrying about how to power the device, so I kept using the mini-USB port to power up the TD1202 through the 5V delivered by the Z1 connected via USB as shown below... a work to be done later is to replace the LiPo battery with one that has a larger capacity, and hook it up to a solar panel, but that's material for another post.

 

I used a logic analyser to verify the communication between the Z1 and the TD1202 was OK, and programmed the Z1 mote using TinyOS with a simple serial test sending an AT\n command every second, hoping to receive the AT command echoed back and an OK from the AT-modem, the result is shown below.

Here's the snippet of code used for the test.  The TMP102 temperature sensor callback event is shown on purpose, it will be used later to forward temperature readings from the mote.

Maybe someday I'll write a driver in Contiki/TinyOS to allow a more flexible and API-like way to communicate with the TD120x, or just port my sub-1GHz based mote to native support SIGFOX, but for preliminary testing sending raw strings is acceptable.

As the serial communication is asserted I can dump now the logic analyser and just print out the responses from the TD120x to console by modifying the code, adding a first print after boot to check out device information such as version.

Z1 with a SIGFOX interface

After checking the TD120x documentation the command to send data is quite straightforward:

AT$SS=[HEX1][HEX2]... [HEX12]

As mentioned before, up to 12 bytes can be sent in any transaction, more than enough for sending a 16-bit temperature reading from the Z1's built-in TMP temperature sensor.

The sending command expects a number of even hexadecimal "symbols" to be sent, meaning if you have 0x123 the modem will return an error, as it expects something like 0x0123.  All data should be sent encoded as hexadecimal, and leading zeroes might be needed depending on your data format.

After wiring my temperature sensor callbacks to be forwarded to SIGFOX the following messages were received, showing the mote was close to 28.5ºC at the moment of the test.  Most of my messages are being sent close to the 868Mhz frequency, maybe SIGFOX operates solely on the G1 sub-band?

The code used for testing is available at Github.

Wrapping up...

If you like to outgrown the demo, you could add more motes and add radio communication, and use the TD120x-enabled mote as a Gateway with dual wireless interface: sub-1GHz and 2.4Ghz, allowing to forward messages to SIGFOX while locally using other network topologies and protocols, not limited by SIGFOX packet size/throughput, only pushing important data and events such as alarms, periodic readings and others.

So this is the end of the post, I still need to test the callbacks and customising the TD120x using the SDK ,but this post has grown too much already, so I'll leave more for later.

Discovering Sigfox

Image taken from www.sigfox.com

A few weeks ago We were invited to a workshop hosted by Abertis Spain, introducing SIGFOX: a cellular/mobile provider offering no less than connectivity for the Internet of Things through its star-based cell infrastructure, acting as a transport channel, even for devices running on batteries.

In a telecommunication market vastly competing for higher bandwidth and high data rates, SIGFOX proposal is quite simple yet appealing: lower data rates and low power consumption equals lower rates/prices (€1-€14), which is good as you can plan ahead what billing plan fits your expected data traffic, giving you exact numbers when having to dimension your network and its possible growth.

Abertis Telecom is SIGFOX operator in Spain, allowing to use its telecommunications infrastructure (broadcast, satellite and mobile communications) to support applications built on top of SIGFOX.  This is a good thing to have in mind when planning a network and its possible growth over time, specially in Smart Citiy applications in which new devices have to be added to either expand the service coverage or add new features, to zones that may lack the proper infrastructure, thus avoiding extra civil work.

But of course, coverage can still be a problem for any RF-based solution :)

As most IoT/WSN applications at the end can be simplified to a basic origin/sink approach, the SIGFOX model can be embraced and ported to existing applications, keeping the power consumption as low as the transceiver allows, as taken from the SIGFOX page:

"Typical emission consumption of a SIGFOX Ready™ modem varies from 20mA to 70mA and they consume next to nothing when inactive"

Which is possible of course by restricting data traffic to one-direction only with low updating rates :)

Now the technical part:

What I found atractive about SIGFOX was the fact that they use sub 1-GHz RF transceivers, thus anyone can port its existing application and adapt to its protocol, not having to purchase a specific radio model or closed HW, as SIGFOX bussiness is focused only on being the carrier, however a certification process is required as expected.

SIGFOX operates in ISM bands (license-free frequency bands), it currently uses 868MHz on Europe (as defined by ETSI and CEPT) and the 902MHz in the USA (as regulated by the FCC), offering different profiles or classes, 0-3, being 3 the worst, mostly for well-covered zones.  I imagine the difference between classes is the transmission power levels, which is expected as to avoid self-interference the wisest thing to do is to confine devices into its cell, avoiding overhearing and interfering with each other and others.

As said earlier, SIGFOX focuses on low throughput devices, restricted to send up to 140 messages per day, each message of maximum 12 bytes (payload data).  Altough this may seem as too low compared to most byte-hungry messages going on the airwaves (up to 128 bytes for most RF transceivers), it actually fits most existing applications, leaving just enough space for data and sensor readings (up to six sensors each with 16-bits measures).  The slow data rate is expected (RSSI are close to -130dBm, so I'm guessing >1Kbps), and in fact is what SIGFOX is promoting, so you will need to think your application towards these constrains, fortunately there are quite a few possible scenarios in which this will work.

My main concern is of course self-interference, as it is right now with fewer radio stations installed all around, reaching to an existing one may require transmitting at a higher power, which in CEPT region places us below the 500mW limit of the 869.400-869.650MHz band, where you can have channels up to 25KHz or even use the whole bandwidth as a high-velocity channel.  The AFA/LBT/duty cycle requirements of the regulation mitigates to some point the self-interference, SIGFOX devices do not use a fixed frequency channel but a random one so there is lesser chances to being interfered twice, also as update rates are quite low, retransmissions attempts can be sky-rocketed as no close to real-time responses are expected, but not all applications are as relaxed.  As we already know, with proper network planning and infrastructure deployment, cells can be adjusted and dimensioned to restrict this effect and the class concept plays an important role in this, but this is a known and expected problem needed to be addressed eventually (surely it is already on their mind!).

The folks at Abertis were kind enough to give free SIGFOX demonstrators, here's ours:

SIGFOX demonstrator with short antenna and user button (back)

The next step will be testing the kit myself and try to sniff some traffic, adapt my sub-1GHz node (a CC1120-based device running on top of a TI MCU) to SIGFOX and develop a simple demo, some colleagues at the office have interesting ideas about what to connect to.

 Documentation available Here