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.
.
