Colorado: Accessing to 802.15.4 networks from Raspberry Pi. Hardware

This document describes the integration between a Raspberry Pi and a Digi Xbee 802.15.4 module from a hardware perspective. The document is completed with the notes about the needed operations from a software perspective available here.

The objective of the Colorado project is developing a STEAM concentrator based on Raspberry PI accessing to a 802.15.4 network by using a Digi XBee module. To do that, it is necessary to connect the Raspberry with the Xbee module using a RS232 link, since both devices integrate at least one 232 serial port.

This document takes as base a Raspberry Pi board with a 40 pin connector (specifically RPi B+) and a Digi Xbee Pro S1 802.15.4 module. The description is suitable to be applied to any Digi Xbee module (S1, S2x, S3, standard or PRO) whenever the module specific power requirements were taken into account (see Powe Supply notes)

Serial connection

The modules connection can be simple, ie just by connecting the Tx-Rx lines, or can be more complex by connecting the hardware synchronization lines (RTS and CTS). In the first case a serial hardware control flow will NOT be feasible. Both wiring methods are covered in the next scheme, in which these connections can be seen:

• Raspberry Tx output (pin 8) is connected to the Xbee DIN input (pin 3)
• Xbee DOUT output (pin 2) is connected to the Raspberry Rx input (pin 10)
• In order to provide hardware flow control support:
• Raspberry RTS output (pin 11) is connected to the Xbee CTS input (pin 12)
• XBee RTS output (pin 16) is connected to the Raspberry CTS input (pin 36)

If the hardware flow control option is being implemented, it will be necessary to allow Raspberry Pi to use its pins as RTS/CTS (disabled by default). To do that, follow the instructions defined in the VMW Productions site.

Power supply

Apart of the serial connection, it will be necessary to power the Xbee module from a supply generating, in case of using a Xbee S1 module, a voltage in the range 2,8V-3,4V and a max. current that will depend on the S1 module used, but that ranges from 50 to 340 mA (see power requirements on page 13 of the Xbee S1 User Manual) .

The Raspberry Pi uses four of its pins as power outputs (check full Raspberry Pi pinout here):

• Pins 1 and 17 outputs 3,3V with a max current of 50mA. Though the voltage is in the Xbee voltage input range, the current is in the higher limit of the smallest module, so using this option is not recommended. Note, however, that in case of using a Xbee S2C (the standard version, NOT the pro version) the max current would be between 33 and 45 mA and therefore taking the power supply from these pins would be feasible.
• Pins 2 and 4 outputs 5V with a max current up to 1500mA (depending on the RPi power supply). This current is suitable to power the Xbee module, but requires a voltage regulation.

In order to perform a voltage regulation, a TI TPS7A4700 regulator configured to output 3,3V is used. As can be seen in the previous schematic, the Raspberry Pi pin 2 output (+5V) is connected to the TPS7A4700 input, and its output (+3,3V) is connected to the Xbee module pin 1. To know more about the TI TPS7A4700, click here.

Read More

Elbert: CC26x2 Launchpad + XBee 802.15.4 integration

The first tests for integrating a TI CC26x2 Launchpad as 802.15.4 end node in a PAN coordinated by a Digi Xbee Pro S1 module have been performed with relative successful results: Though the integration is feasible, there are still some stability issues that must be solved.

The tests have been performed taking as base the TI CC26x2 SDK 802.15.4 "sensor" example program, that implements an end-node able to join to a coordinator and send periodically temperature samples (among other data). On the original code, these changes have been performed:

• Application/2_4g/config.h: macro CONFIG_SECURE set to false to disable network encryption
• Application/2_4g/config.h: macro CONFIG_PAN_ID set to 0x0001 to match the PAN id set on the Coordinator side (Xbee ID parameter)
• Application/2_4g/config.h: macro CONFIG_CHANNEL_MASK bytes 1 & 2 (first byte is byte 0) set to 0xF0 and 0xFF to allow end node using all the channels in which the Xbee Pro module can work (from channel 12, or 0x0C, to channel 23, or 0x17). Note however that this channel usage must match the channels enabled on the Xbee coordinator side (parameter SC)

In the other side, a Xbee Pro S1 module with firmware 10EF (last version available) performs the tasks of PAN coordinator, both being installed on a Connectport X2 with the radio forwarded to a serial port or on a XBIB-U-DEV board. The relevant parameters modified in the Xbee module are:

• Coordinator association (A2) mask set to 0x6, indicating that the coordinator will establish the network in the best of the enabled channels (read on) and that the coordinator allows association of end nodes
• Coordinator enable (CE) set to 1: Module working as coordinator
• Encryption enable (EE) set to 0: Encryption disabled
• Mac Mode (MM) set to 2: Module working on legacy 802.15.4 with ACKs enabled
• Network address (MY) set to 0: The coordinator address will be the address 0
• PAN identifier (ID) set to 0x0001
• Scan channels (SC) set to 0x1FFE, meaning that the coordinator will try to establish the network only on all the XBee Pro available channels (from channel 0x0C, or 12, to channel 0x17, or 23).

With these settings, the CC26x2 joins as end node to the PAN created by the Xbee coordinator and a third party is able to receive the temperature data sent by the CC26x2 via the coordinator. Some issues have to be considered, though:

• It is highly recommended to open a Monitor session to the CC26x2 serial port (on Code Composer Studio, via the JTAG interface) to know exactly what is happening on it. The network changes are reported using these numeric codes:
• 0: Module not started, waiting for user to start
• 1: Module trying to join to a network
• 2: After a reboot, the module has found network information on non-volatile memory and it is trying to join the network it was joined before the reboot
• 3: Module successfully joined to a network
• 4: Module successfully rejoined to a network
• 5: Module has lost the network and right now is orphan
• The CC26x2 will always try to rejoin a previously known network. To avoid it, it is necessary rebooting erasing the non-volatile memory by holding button 2, then pressing and releasing the reset button, then releasing button 2.
• If the CC26x2 channel mask is broad, ie, if it has to search a coordinator in many channels, it is possible that the joining was not instantaneous after rebooting: Finding the coordinator channel will take some time (in the order of tens of seconds).
• If the Xbee module serial port is not open, the module locks after receiving 3-5 frames from the CC26x2. It is the explanation to the fact that, if the Xbee module is set on the XBIB-U-DEV board just powered, but with the USB port not mapped in the computer side, it becomes locked. However it does not happen if the same board is connected to a computer that maps the USB port.
• Even being joined, the X2 coordinator does not show the CC26x2 in the list of detected devices. It is possible that only Xbee devices were shown in that list, with information obtained from the Digi extra header added to the 802.15.4 header when the Xbee MM parameters is set to 1 (that is not this case).

At this point it has been confirmed that the connection is feasible. However some stability issues must be investigated:

• In some circumstances, the CC26x2 is not able to find the coordinator network. This usually happens after resetting/reflashing the CC26x2, with the module staying in state 1 (trying to join) permanently. It is necessary to check if, in these circumstances, a reset with nvmem erase (by holding button 2, as explained before) solves the problem.
• In some circumstances, the CC26x2 joins the network and sends samples, but the coordinator is unable to receive data: Neither data is output in X2 gateway mode, nor the X2 counters increment in non-gateway mode, nor the radio signal strength leds in XBIB or X2 show activity.

Read More

Litems based on ESP32 processors

ESP32 is a series of low-cost, low-power SoCs integrating Wi-Fi and dual-mode Bluetooth that have become the reference when talking about IoT (Internet of Things) devices, what means in a broad way low cost devices with Internet communication features.

The ESP32 devices offer better features than the famous Arduino (native Wi-Fi/Bluetooth dual communication, size, processor, memory, price) while using (among others) the same programming environment (Arduno IDE), putting together better performance and easy programming.

The ESP32 becomes a really interesting option for developing Litems:

• using BLE both overcomes the Classic Bluetooth piconet size (max. 7 bluetooth slaves connected) and allows developing the concentrator as a software layer on a BLE enabled device (Raspberry Pi 3, any modern tablet or laptop), 
• it offers enough processor power for developing virtually anything, 
• its cost and size are reduced, 
• being based on Arduino IDE, the programming learning curve is really short (there are thousands of examples and tutorials in Internet).

For a "Getting started" guide, visit Random Nerd Tutorials site.
For full information, visit the ESP 32 site.

Update (01/21)

An interesting option regarding small footprint is the SiP (System in Package) ESP32-PICO-D4: it is really small and it keeps most of the features of the bigger ESP32 options.  It is available as kit starting from 5$ with a footprint of 52x21mm.

Compared with the Arduino Nano 33 BLE, the ESP32-PICO-D4 is considerably cheaper (starting from 5$, average 8$ vs 17',5€), it offers WiFi and more Flash (4Mb vs 1Mb), though the Nano 33 footprint is smaller (45x18mm).

Read More

Colorado: Voltage regulator for XBee Pro 802.15.4 module

In order to access/manage the 802.15.4 network, a Digi XBee Pro module is being integrated with a Raspberry Pi, the device where the STEAM gateway will run.

This module has a typical voltage input of 3.3V, with a consumption that depends on many factors (versions, PRO features and running modes). In the case of the Xbee Pro S1 international version with RPSMA antenna connector (Digi part number XBP24-ASI-001J), the consumption when transmitting is 150mA, far from the 50mA that the Raspberry Pi GPIO-40 pin 1 outputs.

Is therefore necessary relying on a external power supply or taking the voltage from the Raspberry Pi GPIO-40 pins 2 or 4, that outputs 5V with currents up to 1,5A (depending on the Raspberry Pi PSU). In this last case, a voltage regulator is necessary.

For that purpose, a good option is using a versatile low noise TI TPS7A4700 that, depending on the pin configuration, can output different voltages with a wide input voltage range (3-36V) and a maximum output current of 1A.

The board shown in the photo supports that flexible output voltage configuration by shorting the numbered solder pads and adding to the default 1.4V the value shown in the pad. For instance, shorting the pads 0.4 and 3.2 you get 1.4 + 0.4 + 3.2 = 5V, or shorting the pads 0.1, 0.2 and 1.6 you get 1.4 + 0.1 + 0.2 + 1.6 = 3.3V. The maximum output voltage is 20V.

The shown board can be bought in the TekDevice online shop or eBay.

Read More

Colorado projects started

A new branch in the project repository addressed to develop two new subprojects has been created. The new subprojects are:

• Litem (Mount) Elbert project, addressed to develop a set of Litems based on the Texas Instruments CC26x2 Lauchpad evaluation board (see evaluation board clicking here), using 802.15.4 as network protocol for communicating with the gateway. The code is localted in the subdirectory SteamProject/software/litems/802.15.4/ti-cc26x2-lp/elbert/ of the GitHub repository (direct access clicking here). Given that Elbert works will be developed on a evaluation board, all the results will be considered as experimental.
• Gateway Colorado (river) project, addressed to develop a gateway running on Raspberry Pi (Raspbian OS) implementing 802.15.4 in the underlying network by integrating a Digi Xbee module as interface. The code is located in the subdirectory SteamProject/software/gateways/802.15.4/raspbian/colorado/ of the GitHub repository (direct access clicking here). Colorado source code will be developed in Java and the expected result will be potentially feasible to be put into production.

These two projects will run in parallel, since it is necessary their mutual integration to have a practical result (litem without gateway and viceversa is nonsense). However, even being closely related, it is important to state that the individual results will be compatible with the STEAM specification, ie, Elbert will be compatible with any STEAM 802.15.4 gateway and Colorado will be compatible with any STEAM 802.15.4 litem.

Since both the Colorado river and the mount Elbert have strong relationship with the Colorado state, the above icon is selected to represent graphically these two projects.

For detailed Elbert project information (description, planning and current status) click here. For detailed Colorado project information (description, planning and current status) click here.

Read More

GitHub repository created

A repository for becoming the project cooperative sourcecode base has been created and is available on GitHub (link here).

A skeleton directory structure is being created as first step,  and the works on the wiki with the project documentation  are in progress.

The skeleton structure contains readme files in each level, indicating what is its purpose, ie, what is expected to be stored there.

A project naming methodology has been defined to allow multiple project coexistence while simplifying the selection of project names. In that way, the naming methodology states these rules:

• Litem project will take the name of a world mountain.
• Gateway projects will take the name of a world river.
• Controller projects will take the name of a world lake.
• Manager project will take the name of a world sea.

Read More