Generation-2 Wireless Sensor Network Users Manual

cpu_pps_times_file:    /root/bin/d/2.cpu_pps
driver_name:           SrParXch278
xch_model_name:        PAR4CH
port_mode:             bpp

parx_sps:              1000.
parx_naverage:         1
data_volume_limit:     80000000

parx_sleep_ms:         10
reads_per_timestamp:   1
sec_per_file:          120
parx_report_file:      /root/d/2.parx.report

Deploy mother to a location visible to all active WSN nodes.

10-Conductor Pinout
Pins A and B: North              Digitizer channel 1
Pins C and D: East               Digitizer channel 2
Pins E and F: Z-axis             Digitizer channel 3
Pins G and H: Independent        Digitizer channel 4
Pin I:        +Charging supply
Pin J:        -Charging supply

10-pin Amphenol bulkhead connector to digitizer analog input: 8 wires to 15-pin D-ring connector.
15 pin D-ring digital i/o connector: ground wire and PPS signal from GPS board.
Parallel ribbon cable: Parallel port on SBC daughter to parallel port on digitizer.
12-volt barrel-plug power cable to power board (underside).

Serial cable to SBC serial port ttyS0.
RCA-connector PPS signal to: SBC GPIO socket, digitizer DIO, spare wire for testing.
12-volt barrel-plug power cable to power board (underside).

12-volt pair to power supply daughter board (top right of SBC stack)
Serial cable to GPS board
GPIO (DIO) connector: Ribbon cable and various destinations
Parallel port ribbon cable to digitizer
Ethernet cable to wireless
Note: COM2 10-pin socket can be used for direct serial login e.g. using "minicom"

10-pin Amphenol bulkhead connector to charge controller Photovoltaic terminals.
Input 2-pin Amphenol connector 12Volts to charge controller battery terminals.
Charge controller load terminals to power board 12 volt input terminal.
Some wsn nodes take off an additional ground wire for WET-11 power.

5-volt barrel-plug power supply from power board.
Ethernet cable (non-crossover) to eth0 port on SBC.
Coax antenna cable connector to bulkhead N-connector.

The small WET-11 slide switch on the WET case should be on crossover (X).

• Wirecutters (for zip ties)
• VO meter
• Crossover cable
• External Ethernet cable
• Serial connection cable
• 3 x Rubber Ducky antennas
• Antenna cable for Grey Omni Antenna
• Spare voltage converters for 12 -> 5 (WET-11)
  

2a. Manager logs on to the wsn node and issues commands.
2b. Manager uses the wsn program to control the nodes via their on-board task manager.

# more /etc/sysconfig/network/ifcfg-eth0

BOOTPROTO='static'
MTU=''
REMOTE_IPADDR=''
STARTMODE='onboot'
UNIQUE='GA8e.RlzwFdb+Or5'
BROADCAST='192.168.1.255'
IPADDR='192.168.1.50'
NETMASK='255.255.255.0'
NETWORK='192.168.1.0'

anonymous-ftp files uploaded to mother should automatically be readable by User.
(i.e. User should not be obliged to be root to read the data!)

A backup directory of binaries might prove useful.

The drawback to reduced-CPU operation is that the gps program does not write its data buffer to disc until the program finishes its full acquisition period.

/etc/sysconfig/ifcfg-eth0 reads:

DEVICE=eth0
IPADDR=192.168.1.8
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
#BOOTPROTO=dhcp
BOOTPROTO=static
ENABLE=yes

/etc/sysconfig/ifcfg-eth1 reads:

DEVICE=eth1
IPADDR=192.168.2.8
NETMASK=255.255.255.0
NETWORK=192.168.2.0
BROADCAST=192.168.2.255
ENABLE=yes

The crucial core elements of a brick's directory structure are:
Home directory:             /root
Short-driver directory:     /root/.short
Bin directory:              /root/bin
Tmp directory:              /root/tmp
Data/Output directory:      /var/ftp/downloads
Control/Input directory:    /var/ftp/uploads
Symlinks to Data and Input: /root/d and /root/u

The crucial core programs a brick runs are:
/root/.short/short.o GPS interrupt handler (this is auto-run on boot).
/root/bin/gps        GPS data acquisition
/root/bin/seismo     Seismic data acquisition
/root/bin/smd        SendMotherData (contents of /root/d).

Use dmesg to determine how much memory a brick has.

Some PAR4CH digitizers can support a sampling rate of 2000+ samples per second.
PAR4CH on WSN nodes 7 and 8 currently support only up to 1200 samples per second.
The error messsage when the requested sample rate is too high:
ERROR: Could not open PARxCH (Err = A/D READBACK)
Solution: Reduce the brick.config requested samples per second 'parx_sps'.

At this time milo is not tested so all further milo-related remarks can be skipped over for now.

3.2 Acquiring Data: Tutorial
3.2.1 Basics and Diagnostics
The wireless sensor network command set always begins with 'wsn'; this is a simple C program that parses the command.
The simplest model for a data acquisition and recovery would go like this: The user would set up the bricks in wireless range and issue the command from mother:

% wsn acquire all 5 30

This will trigger milo to start both a gps process and a seismo process. The gps process will simply acquire data and write the results to an ascii output file once per second. The seismo process would sleep for 5 minutes and then acquire 30 minutes of seismic data. Before acquisition of seismic data the manager will want to verify that all bricks "see" GPS signals and have good timing available. Issue the wsn command:

% wsn gpslock all

The resulting diagnostic verifies that all bricks have good timing; the investigator then fires a seismic shot. Suppose that ten minutes later he wishes to recover the data. He should first halt the gps and seismo processes and then request a data retrieval. The latter is accomplished via another program run by milo called 'smd' which stands for 'send mother data'.

% wsn halt all gps
% wsn halt all seismo
% wsn retrieve all

Suppose that four nodes were running during this test and that each produced 2 file-pairs plus a gps output file. The resulting files in the ftp uploads directory would look like this (with 10-minute-duration data files):

% cd /var/ftp/uploads
% ls
10.5453848585.data
10.5453848585.stamp
10.5453849186.data
10.5453849186.stamp
10.cpu_pps.time.0
12.1234555100.data
12.1234555100.stamp
12.1234555700.data
12.1234555700.stamp
12.cpu_pps.time.0
14.4328770200.data
14.4328770200.stamp
14.4328770801.data
14.4328770801.stamp
14.cpu_pps.time.0
15.8420713150.data
15.8420713150.stamp
15.8420713750.data
15.8420713750.stamp
15.cpu_pps.time.0

This data is returned to the ftp/uploads directory. The investigator then creates a data directory

% mkdir $BRICK/data/Shot1.12.12.2005

and puts the data there, for example:

% mv ftp/uploads/*.*.* $BRICK/data/Shot1.12.12.2005

The diagnostic printout of any wsn command will be a status report from each brick involved in the command. If the command is:

% wsn acquire 4 20 50

the resulting report should hopefully read:

node 4: gps running. seismo running: sleep %d minutes, acquire %d minutes.

or it may return:

 node 4: command failed: no connection established

Suppose instead you issue

% wsn acquire all 10 100

and the reply returns like this:

brick 4: command failed: no connection established
brick 5: gps running. seismo running: sleep 5 minutes, acquire 30 minutes.
brick 6: gps running. seismo running: sleep 5 minutes, acquire 30 minutes.
brick 7: gps running. seismo running: sleep 5 minutes, acquire 30 minutes.
brick 12: gps running. seismo running: sleep 5 minutes, acquire 30 minutes.
brick 14: gps running. seismo running: sleep 5 minutes, acquire 30 minutes.
brick 15: gps running. seismo running: sleep 5 minutes, acquire 30 minutes.
brick 16: gps running. seismo running: sleep 5 minutes, acquire 30 minutes.

In this case you would assume brick 4 is not properly connected via wireless. You would then issue:

% wsn ping 4

to verify this connection is not working. If this is the case you would first power-cycle mother's WET-11 and try again. If node 4 was still not visible you would visit node 4 and power-cycle its WET-11, and proceed from there. Diagnosing wireless connection failure should always start with (a) power cycle the WET-11s and (b) reboot the wsn SBC.

The full wsn command list is described in Appendix A.

3.2.2 Very important summary: How to think like mother and how to think like a brick
Please bear in mind that at this stage in development it is helpful to think as both mother and as the wsn node.

To think as mother:
  The wsn program is run with a command; this typically produces a command file which is ftp'd to the node or nodes specified.
  The wsn program then waits for a reply and reports on the success/failure of the command issued for that node.
  The wsn program then proceeds to the next node if more than one are specified.

To think as a wsn node:
  Your task manager program is milo.
  Milo has a list of possible tasks that he can do.
  He cycles through that list in between sleep intervals.
  The sleep interval is "fast" (e.g. 1 second) if there is no data acquisition going on.
  The sleep interval is "slow" (e.g. 15 seconds) if there is data acquisition going on.
  There are two data acquisition programs: gps and seismo.
  When Milo receives a command from mother he typically takes the following steps:
    1. Delete mother's command file.
    2. Create a reply file.
    3. Perform the specified operation and indicate how it went in the reply file.
    4. Send the reply file back to mother.
    5. Delete the reply file from the local /root/tmp directory.
Finally to synthesize the two: Suppose the network manager wishes to acquire data, so we have:
- Network manager issues
% wsn acquire all 5 30
- wsn puts an acquire command file (containing '5' and '30') on all the nodes.
- Milo must be running!
- Milo notices the command file and immediately
      . halts any existing gps programs
      . starts a new gps program.
- Milo also immediately starts the seismo program.
- Milo checks that both processes exist.
- Milo reports back the results of his efforts.
- The wsn program relays the return result for each node to the network manager.

So far so good; now what happens next:

- Meanwhile the gps program is running. It will save cpu times and UTC times in its usual output file.
      . The gps program should have sufficient time to acquire a lock before any seismic test
      . This can be checked using the wsn gpslock all command.
- Meanwhile the seismo program is also running.
      . The seismo program will immediately go into a sleep for the requested time interval (5 minutes).
      . The seismo program will then acquire data and write output files to its /ftp/downloads directory.
      . Seismo writes file pairs: Time stamp files and data files: .data and .stamp extensions respectively.
- seismo output files are written with one write() call apiece.
      . Therefore if each file is 5 minutes of data: Let the last file finish writing.
      . This means after a test: wait a bit before halting seismo.
- Once the acquisition is complete, move on to data recovery, wiping the files from the brick, and verification of data quality.

The seismo program maintains two pointer files. One points to the most recently written data file, the other to the most recently written stamp file. Similarly the gps program maintains a pointer file which indicates the current gps output file. This changes once every 10 days or so, so there is a very good probability that the three files so-indicated will comprise a self-consistent dataset.

Either via milo or manually, the triplet of files can be returned to mother for analysis and viewing. There are two programs required plus some additional called programs that are not described. The first step in visualization is to produce utc-tagged data (1 data file for each of the 4 digitizer channels plus an accompanying time file, one time value for each sample). The next step is to look at the data or multiple datasets from more than one wsn node using a visualization progrm. These programs are dataprep and seiplot.py respectively.