PHOTO 3. This Access Point has seen a couple of MASTERs classes
and has logged many an hour on the bench.
sleeping. Again, an external stimulus from a controlling
device must be present to bring out the sun, moon, and
stars for the ZG2100M module.
Since even the smallest microcontroller can execute an
instruction in less than a microsecond, it is important to
know how much time it takes for the ZG2100M to awaken
from a power-up and move between states. The ZG2100M
needs 300 mS to stabilize after power-up. When
transitioning to and from hibernation, it requires the
controlling microcontroller to allow 50 mS for the transition
to complete. The latency for enabling the ZG2100M’s
receive circuits is 0.2mS. Receive to transmit and transmit to
receive switching latency is 0.01 mS. The ZG2100M wakes
up and enters a standby state in 0.2 mS. The standby state
SCREENSHOT 1. The ZG2100M configuration requires that our
Access Point provide a DHCP server function. This is the screen
that turns on the Access Point’s DHCP server.
44 SERVO 03.2010
is a transitional mode only. Thus, when the ZG2100M
wakes up, it takes 0.2 mS to enter standby mode and
another 0.2 mS to enable the receive circuitry.
Power consumed by the ZG2100M in sleep mode is
250 µA. The sleep power mode is managed by the ZG2100
and allows for keeping in touch with the access point to
which it is associated using the least amount of power.
During hibernation, the ZG2100M draws a miniscule 0.1 µA
of current. These very low power consumption figures make
the ZG2100M perfect for battery-powered applications.
Outside of the realm of the Explorer 16 development board,
the ZG2100M can operate on voltages between 2. 7 and
3. 6 volts.
The ZG2100M’s SPI portal is configured as a slave.
From the viewpoint of a SPI slave, the SPI master is
responsible for providing the clocking that is necessary to
move data between the slave and master devices. The SPI
clock speed is limited to 25 MHz. The master SPI device also
has the responsibility of activating the target slave device if
other slave devices are under its control. To alert the master
of data availability, the ZG2100M includes an interrupt
output line that is driven logically low when the slave
ZG2100M contains data it needs to forward to the master
device. Once the master empties the ZG2100M’s data
buffer, the interrupt line is driven logically high by the
ZG2100M. Another look at Schematic 1 reveals that the
SPI master portal on the Explorer 16’s PICtail Plus interface
includes a ZG2100M slave select line (CSN), a ZG2100M
reset output (RST_N), and a CE_N state/mode control
output.
Another very important feature of the ZG2100M
hardware is the inclusion of a valid IEEE MAC address which
is factory coded into every ZG2100M module. According to
the ZeroG datasheet, each ZeroG module MAC address is in
the range of 001EC0xxxxxx.
Okay. You’re trained on the ZG2100M. Let’s move on
and start setting up a ZeroG wireless network.
Configuring the AP
The AP (Access Point) you see in Photo 3 is a babe in
the woods as it knows nothing about the ZeroG network
we want to build. So, we’ll begin our Access Point’s
education by teaching it how to serve IP addresses via its
internal DHCP server module.
The AP defaults to an IP address of 192.168.0.1. That
piece of IP information allows us to use Internet Explorer as
our educational portal. Simply entering http://192.168.0.1
in the Internet Explorer address frame gives us access to the
AP’s internal configuration engine. There is another
network on the bench running in the 192.168.0.1 domain.
So, I modified our ZG2100M network’s AP to use the
192.168.1.0 IP segment. Screenshot 1 is representative of
the configuration page that we used to enable the DHCP
server. Note the new LAN IP address and that our pool of
IP addresses now begins at 192.168.1.100 and ends at
