- Getting Started
- Software Products
- SNAP RF Modules
- IoT Gateways
- SNAPconnect E12 Gateway
- Getting Started
- E12 Software Specifics
- LEDs and Button
- Working with the SNAP Module
- Using USB Accessories
- Accessing the microSD Slot
- Factory Restore
- Technical Specifications
- Regulatory Information and Certifications
- E10 Migration
- SNAPconnect E20 Gateway
- SNAPconnect E12 Gateway
- Legacy Products
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/snap1 connected to
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.
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.
In This Section
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:
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:
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).
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
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 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
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.