- Getting Started
- Software Products
- SNAP RF Modules
- IoT Gateways
- SNAPconnect E12 Gateway
- SNAPconnect E20 Gateway
- Hardware Setup
- Getting Started
- E20 Software Specifics
- LEDs and Buttons
- Working with the SNAP Module
- Wi-Fi Setup
- Using USB Accessories
- Accessing the microSD Slot
- Factory Restore
- Mounting Instructions
- Technical Specifications
- Regulatory Information and Certifications
- E10 Migration
- Release Notes
- Legacy Products
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/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 are two GPIO pins from the gateway that are tied to lines on the SM220 for controlling and signaling.
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.
In This Section
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 * @setHook(HOOK_STARTUP) 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
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 https://update.synapse-wireless.com/pypi/
SNAPtoolbelt can be used to update the firmware on the SNAP module:
snap recover firmware SM220UF1 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.
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:
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 * @setHook(HOOK_STARTUP) 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 fi while [[ `cat /sys/class/gpio/gpio32/value` != 0 ]] ; do sleep 1 done echo "Got interrupt!"