Working with the SNAP Module

The SNAPconnect E20 contains a Synapse Wireless SM220 surface-mount SNAP module, which it can access via serial ports /dev/snap0 and /dev/snap1 connected to UART0 and UART1 on the module, respectively. By default, SNAP-powered modules communicate serially over UART1, so when making your SNAPconnect or SNAPtoolbelt connection to the module, you should use /dev/snap1 unless you have modified your modules’s default UART settings.

For detailed instructions on SNAPconnect, please consult the SNAPconnect Users Guide.

In addition to the serial connections, there are two GPIO pins from the gateway that are tied to lines on the SM220 for controlling and signaling.

E20 Pin

SM220 Pin




You can use this pin as a signaling semaphore or to wake the SM220 when it is sleeping.



You can use this pin to reboot the SM220.

By default, the SNAPconnect E20 ships with SNAPtoolbelt installed. SNAPtoolbelt can be very handy when needing to perform simple operations or maintenance on the SNAP module.

Waking the SNAP Module

At times it may be helpful to have the SNAP module in your E20 sleep, and then be woken by the E20’s processor. You can easily do this by defining GPIO_F1 on the SNAP module as a wake pin, like this SNAPpy script:

from synapse.pinWakeup import *
from synapse.platforms import *

def onStartup():
    setPinDir(GPIO_F1, False)
    setPinPullup(GPIO_F1, True)
    wakeupOn(GPIO_F1, True, True)

To wake the SNAP module you will need to pull the E20s GPIO 33 high, pause a second, and then pull the line low.

Resetting the SNAP Module

Just as you can wake a sleeping SM220, there is a pin you can use to reset your module should you need to.

Invoke this Bash script to briefly pull the reset pin low and then release it to high, resetting the node:


Recovering the SNAP Module

Several things can make a module unresponsive, including: setting an encryption key that you then forget, or a script that sends the node to sleep with an invalid wake pin defined, or even a script that sends the node into an infinite loop.

SNAPtoolbelt provides help here, with the snap recover options.

If you find that your SNAP module is unresponsive or unreachable over the air or serially, the first suspect is typically the user script on the module. So, the first thing to try in module recovery is forcibly removing the SNAPpy script from your SNAP module:

snap recover erase-script SM220UF1

This leaves your SNAP module’s NV parameters untouched, but removes the existing SNAPpy script from the node. You can then load an appropriate script over the air or serially.

If this does not restore your access to the node, the most likely reason for your inability to communicate is mismatched configuration (NV) parameters on the node. This could be the result of different encryption keys or encryption types, misconfigured UARTs, differences in how many CRCs are expected, or some other configuration setting. The easiest thing to do next is to have the node default its NV parameters:

snap recover default-nvparam SM220UF1

This clears the encryption settings (no key, no encryption), sets UART connections to their default settings (UART1, 38,400 baud, 8N1), and clears other settings to their default levels. (Refer to the SNAP Reference Guide for other defaults.)

Typically it is best to start with clearing the script in your node before resetting its parameters, because it is possible for the script to reset (away from default values) parameters that you just reset (to default values).


Resetting your SNAP module to default settings does not automatically mean that other devices can talk to it, over the air or serially. It does mean that you now know how to configure those devices to talk to it. If you have another radio device on channel 13 using network ID 0xABCD, you will have to set that device to channel 4, network ID 0x1C2C to talk to your defaulted SNAP module. You can then use that radio connection to move the gateway’s SNAP module to your preferred network settings. Or, you could change those settings serially from your SNAPconnect E20 — if your gateway is set to communicate serially the way that your SNAP module is (considering encryption keys and types, serial rates, etc.). The point is: defaulting a device doesn’t mean you have it where you want it, only that you now know where to go look for it.

Upgrading the SNAP Module Firmware

Synapse Wireless is always working to improve the experience with SNAP-powered networks, and that means new firmware every now and then. If you find that you want to upgrade the firmware in your gateway’s SNAP module, you can do it over the air or serially from the E20. You’ll need to download the firmware appropriate to your SNAP module by typing:

sudo -H pip install snap_firmware_2.8.2 -i

SNAPtoolbelt can be used to update the firmware on the SNAP module:

snap recover firmware SM220UF1 2.8.2

Where 2.8.2 is the SNAP Module firmware version. Loading new firmware erases the script previously in the node but does not change any NV parameters.

Controlling the E20 from the SNAP Module

Just as there are lines from the E20’s i.MX6 processor to the SM220 Series as a wake pin and a reset, there are corresponding pins back to the i.MX6 from the SM220 Series:

SM220 Pin

E20 Pin




You can use this as a one-bit signal from the SM220 even when SNAPconnect software is not running on the E20.



This pin is tied to the system reset line on the E20, active low. You can use this to reboot the i.MX6 processor without interrupting service on the SM220 Series.

The reset line will force a reboot of the E20’s i.MX6 processor. This may cause the loss of unsaved data, and as with any uncontrolled shutdown of a computer it is not recommended that you use this often. It is intended only to recover an unresponsive E20. The following sample SNAPpy script demonstrates rebooting the i.MX6 processor from the SM220:

from synapse.platforms import *

def on_startup():
    setPinPullup(GPIO_C4, True)
    writePin(GPIO_C4, True)
    setPinDir(GPIO_C4, True)

def resetE20():
    pulsePin(GPIO_C4, 1, False)

In contrast, the GPIO_F2 pad on the SM220 Series can signal the GPIO 32 line on the i.MX6 without any danger to either system, and the signal can be processed or ignored by your E20 program as you choose. The following sample Bash script demonstrates how to watch for the pin change from your gateway’s perspective:

if [[ ! -d /sys/class/gpio/gpio32/ ]] ; then
    echo 32 > /sys/class/gpio/export
    echo in > /sys/class/gpio/gpio32/direction
while [[ `cat /sys/class/gpio/gpio32/value` != 0 ]] ; do
    sleep 1
echo "Got interrupt!"