Working with the SNAP Module

) The SNAPconnect E12 contains a Synapse Wireless RF200SU 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 is one GPIO pin from the E12 that is tied to the module for controlling and signaling.

E12 Pin

RF220SU Pin

Purpose

GPIO 48

RESET

You can use this pin to reboot the SM220.

By default, the SNAPconnect E12 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 E12 sleep, and then be woken by the E12’s processor. You can easily do this by defining GPIO_12 on the SNAP module as a wake pin, like this SNAPpy script:

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

@setHook(HOOK_STARTUP)
def onStartup():
    setPinDir(GPIO_12, False)
    setPinPullup(GPIO_12, True)
    wakeupOn(GPIO_12, True, True)

Now, whether your SNAP module is in a timed sleep or an untimed sleep, having the code on your E12 invoke this command will wake the SNAP module:

/usr/local/bin/wake-snap-node

The Bash script must be invoked as sudo or by a process invoked as sudo. You can examine the Bash script to see how the GPIO value is controlled for use in your own scripts, should you wish to use the pin as a one-bit signal to the SNAP module.

Resetting the SNAP Module

Just as you can wake a sleeping RF220SU, 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:

/usr/local/bin/reset-snap-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 RF200SU

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 RF220SU

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

Note

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 E12 — 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 E12. You’ll need to download the firmware appropriate to your SNAP module by typing:

sudo -H python2 -m pip install snap_firmware_2.8.2 -i https://update.synapse-wireless.com/pypi/

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

snap recover firmware RF220SU 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.