The report

While its still fresh in my mind, here's an abbreviated report on my EBD visit
to UCLA. More detail if anyone wants it - I've quite a few notes in my logbook.

The Experiment: 
---------------

UCLA (and a couple of other groups) have access to an office building that was
badly damaged in the 1994 quake. It's been abandoned for ten years, and they got
access in May. Since then, they've instrumented the structure with lots of
sensors: DCDTs (displacement) for column displacement and drift, strain gages
for direct measurements from the concrete, and accelerometers.

There's no power, so there are generators in the truck and on the roof. Network
is satellite-based, max T1 speed, defaults to 128kbits/sec.

Equipment: 
----------

They have three different DAQ systems onsite:

1) A consultant-designed LabVIEW system for strain gages. This is three small
racks, with a PXI chassis PC in each. It has a 16 channel DAQ card, being used
in diffential mode to yield 8 channels. These are 4-way multiplexed to read 32
strain gages using a sample-and-hold buffer in the SCXI chassis. The plan was to
add the NEESGrid DAQ distribution to the consultants' code for data streaming.

2) dSpace. This is a MATLAB-based system that drives the linear shaker. Creare
provides a matlab interface, so this has a fairly simple interface to stream
directly into the data turbine.

3) Antelope. This is a commercial product, a networked ring buffer very similar
to the data turbine. They used this to read the accelerometers. For this, a UCLA
person took my fake_daq code and modified it to communicate with the Antelope
system.

Tasks:
------

In addition to getting these to stream, we also needed to

1) Fix slowdown problems with the Axis 2401+ units
2) Put a nees-pop on the truck
3) Setup the turbine, OGSA, etc and turbine apps
4) Figure out data transport other network-based issues

Results:
--------

The Axis problems were solved by a firmware update; that was the easiest to solve.

The nees-pop wasn't too bad, once we figured out the network design. All local
gear is on 172.23.39.*. This is run through a commodity NAT router, a Linksys
BEFRS41v3. The linksys protects all the site gear from offsite access; the only
inbound connection is ssh which is forwarded to the nees-pop. We did not install
the nees-pop distribution, as they need v3. Instead, I installed the precursors
required to work from CVS:
- Java 1.4.2_05
- Ant 1.6.1
- JMF 2.1.1e
- Data turbine 2.3.1 and 2.4b110
- Turbine code

The last two are in my home directory, as they will be replaced with the
distribution. The rest is is /usr/java/.

Here's a rough schematic of the network:

The idea is two use two data turbines: A 'parent' on a world-reachable machine
at UCLA, and a 'child' onsite. In the RBNB system, the child initiates the
connections, which works very well in this NAT-d configuration. The parent
turbine can have access control to only allow writing from the child. The only
question in this arrangement is this: can we limit which sources travel from
child to parent, to limit the satellite bandwidth used?

I was not able to get full functionality working with the parent-child setup.
Setting it up is very easy:
- Run the parent normally
- Run the child with a -p {machine address}
and that's it. They figure out who's who, and the child handles reconnects on
errors. This part was fine, and channels streaming into the child showed up in
the Admin tool when connected to the parent. Also, video fed into the child was
viewable from the parent. Numerical data didn't work, though this looks like a
simple failure in the Plot tool. I've asked Creare about this and will follow up
to see what's the problem.

The turbine apps got a good workout, and we found some bugs. (Good for us, less
so for UCLA). There's still a problem with DaqToRbnb and timestamps that we're
working on - timestamps are losing precision somewhere; Terry is working on it.

The labview DAQ systems had unrelated problems just acquiring and saving data,
so we never got to the point of adding neesgrid capabilities to them. However, I
did give the consultant our code and a walkthrough of how to add it, so he
should have little difficulty doing so once the other issues are resolved.

The dspace system passed basic tests for streaming data, but the linear shaker
was not used this week, so we did not get a complete test. We modified it to
connect to the turbine on the neespop and run as much of the code as we could
(connect to turbine) without the shaker itself.

The antelope driver, orb2NSDS, has problems. It was code that appears to have
been coded quickly, and broke badly when we increased from three channels to 140
or so. I've done some cleanup and fixes on it, but it needs further attention to
be useful. As Antelope is a popular product, I think we will need to spend some
time on this soon.

Conclusions:
------------

Steve, Dan - any comments/corrections/additions?

It was a fun week; quite surreal and post-apocalypse. Ben Clifford from ISI came
along on the last two days to help with code, Unix and network issues. Ben's
pictures are at 

I'll post my pictures in the next few days.

They have another few weeks of access before they have to pack up, and there's
much left to do; it's worth considering a second EBD visit after next weeks'
13WCEE preparations.

Cheers,
-Paul

Navigation links

Support