<html>
<body>
Hi Folks,<br><br>
If you are interested in using cellular comms for your seismic telemetry,
read on. This is what I sent to Mark Meremonte in response to
several questions he had. Hopefully this is helpful to you
to. Some responses, particularly those related to IT security, may
not affect your organization. The USGS, for good or bad, is really
getting anal about its IT system. And thanks to Rayo at CIT for
getting us started down the cellular path in the first place.<br><br>
Note: As we delve into the world of using the Internet for comms
(via either cellular, vsat, or borrowing somebody's service), we at Menlo
Park are not totally thrilled with relying on it in the event of a large
earthquake. We still prefer our own dedicated comms. However,
when expenses and other issues are factored in, we see a small place for
it. Furthermore, if we take advantage of the ability to send data
from the datalogger to two different acquisition systems (say, Menlo and
Golden), Internet comms start to make more sense. The issue of IT
security and, worse, the possibility of limited future IP gateways, is
another looming issue.<br><br>
The one thing I did not spell out clearly enough for Mark was bandwidth
depending on service. If your station is outside of EVDO
service--which is expanding rapidly, but still not widely available
outside of metropolitan areas--you will only see 1X service.
Real-world upload on the 1X network seems to be about 140kbps, which,
again, should be plenty for most 6-ch seismograph stations. All the
testing we did in Menlo was on this service.<br><br>
Cheers!<br>
Dave<br><br>
<br>
<blockquote type=cite class=cite cite="">Hi Mark,<br><br>
Sorry for the long delay. I was swamped this week. But, yes,
you are correct. We have had a 6-ch Reftek 130-ANSS-II datalogger,
with STS-2, attached operating since about June 5. It took awhile
to work up to the point we were satisfied enough to install the station
with cellular telemetry, but in the end, since the site had been off the
air for about 2 years, getting something installed was better than
nothing! Anyway, I'll elaborate via answers to your questions below
in blue.<br><br>
<br>
<blockquote type=cite class=cite cite="">-- service provider and Federal
contact person at Veriazon or ATT;<br>
According to Bob, Verizon was the better company
to work with seems like I remember </blockquote><br>
<font color="#0000FF">We use Verizon primarily because it is our contract
service provider. I had my rep at ATT rebuke that saying that he
could meet the price Verizon was giving us. However, here in
California, Verizon really does have the edge in available service, so I
probably would have gone with them anyway. My contact is a fellow
out of Sacramento by the name of Steven Neu. His number is
916-677-6060 and email is Steven.neu@verizonwireless.com. He is as
reliable as a studebaker. I think he is assigned way too much work
and just forgets about my requests. I've been waiting for a static
IP for our second system for almost 2 weeks. When he gets focused,
then he actually gets stuff done. You'll probably want to find a
"local" rep in your area, but Steven might be a good place to
start. I'm sure he'd love to pawn you off to someone else.<br><br>
</font><blockquote type=cite class=cite cite="">-- type of service and
estimate of cost</blockquote><br>
<font color="#0000FF">We are on the "BroadbandAccess" plan,
which costs $59.99, with a 19% discount for federales. The total
comes out to $48.66 (cheep!). Surprisingly, this account is good
for unlimited MB or throughput per month. I've heard rumors that
they get edgy when you exceed 5GB per month, but we're pretty sure we're
only going to need about 2.5GB per month. I haven't yet got the
first full month's bill to know just exactly how much we are using.
I had Steven re-verify that we indeed had unlimited MB. If you need
to refer some other rep to an account to help get set up, our's is
371099168-00001.<br><br>
</font><blockquote type=cite class=cite cite="">--
bandwidth</blockquote><br>
<font color="#0000FF">With the broadband access, we get--in theory--up to
1Mbps, although in testing we never saw anything more than about 700kbps
upload. The service at this level is called EVDO (Rev A). It
took awhile for us to figure all this out. I had only asked for the
lower speed 1XRT (cdma) service thinking the 1M was overkill and we
didn't need to spend the money. Well, apparently, us feds get EVDO
for the same price as the 1X. Go figure. I'm not complaining,
because I also found out that it's better to have the EVDO service
anyway. Turns out if you are only on the 1X network, it is shared
with the voice channels, so if call volume spikes (like after an
earthquake), you may see a reduction in throughput (you probably won't go
off the air because you would already be connected). If you are on
the EVDO frequencies/service, its bandwidth is separate from the voice
channels. That means it's likely volume won't spike high enough to
affect data throughput. And, if the EVDO channels fail for some
reason, it will transfer you over to the older 1X channels. If
you're on 1X, you have no back up with failures.<br><br>
See below for our experiences with bandwidth, however.<br><br>
</font><blockquote type=cite class=cite cite="">-- type of cell modem (I
have been looking into Raven XT modems)</blockquote><br>
<font color="#0000FF">We are using the RavenX. Seems like a pretty
robust modem, and I didn't hear too many complaints from the techs.
We like the build quality for being out in a vault in the
boonies.<br><br>
</font><blockquote type=cite class=cite cite="">-- type of antenna (I
believe Bob uses some little hemispherical antenna, not sure of
db)</blockquote><br>
<font color="#0000FF">We have tried 3 types of antenna: 800Mhz
yagi, 1900MHz yagi, and a dual-band 800/1900MHz omni whip. I
don't think we've seen a whole lot of difference between them. Part
of that may be that everywhere we've taken the modem we could get a
pretty good signal even just using the whip--even from the site where it
is in use which seems like it is pretty far out of town, where EVDO
service can be obtained. What Dave Reneau ended up leaving at the
site is two antennas: the 1900 yagi and the dual-band whip. He
likes the flexability of the RavenX to allow two antenna inputs which
seemed to give a more reliable signal. Our theory: if we
relied only on the yagi pointed at a particular cell site and the site
failed, we wouldn't necessarily be able to pick up another tower.
If we also have the omni on, then for a failure, we have a better chance
of picking up another site. Don't know, but it sounded
good.<br><br>
Models: 800 MHz yagi (which is only good if you can only get 1X service
in the boonies)--Antennex Y8066<br>
</font><x-tab> </x-tab>
<font color="#0000FF">1900MHz yagi (for EVDO service)--Telewave
1920Y9-WRU<br>
<x-tab> </x-tab>Dual-band
omnis: Maxrad Bmax 824/1850 and Larson NMOC/P3E (we bought both, seem to
be equals)<br>
Of course there are several options in these bands.<br><br>
</font><blockquote type=cite class=cite cite="">-- whether continuous or
not and sample rates achieved</blockquote><br>
<font color="#0000FF">At a minimum of 200kbps, that should be plenty of
bandwidth to get a fully continuous 6-ch seismic station through at
200sps. We typically operate our 6-ch stations at 100sps, which
should require only about 18-20kbps (with compression). See below
for actual experience.<br><br>
</font><blockquote type=cite class=cite cite="">-- whether using static
IPs and how many; or are you using dynamic</blockquote><br>
<font color="#0000FF">As a network, like yours, that uses USGS networks,
we are required to have static IP addressing. Lynn Dietz is the
best person to talk to when you get to the part about integrating it into
the network. Essentially you have to submit a request to open a
firewall hole for a specific address and port number. They ask a
bunch of questions, then you get your hole. The RavenX is
essentially a mini-router, so you set it up to control a little
LAN. The datalogger, in this case a Reftek, is set to some
arbitrary address (like 192.168.0.1) and the RavenX does the translation
and routing. If you had another device, like a web cam, it would be
part of the LAN. It only requires one static address from Verizon
(and subnet mask and gateway) to handle the whole site. Verizon
Wireless seems a bit reluctant to hand them out, but you're paying for
it, so you just have to keep bugging them. In the case of Reftek
acquisition software, we were required to set it up in the DMZ, outside
our private network otherwise it wouldn't work. Then, the server in
the DMZ exports to our acquisition computers on the private seismic
network. Call Lynn if you have questions about how that part
works. I barely understand it.<br><br>
</font><blockquote type=cite class=cite cite="">-- what about complying
with advanced encryption standards</blockquote><br>
<font color="#0000FF">We have not yet complied with any specific
encryption standards, and I don't know if the Raven is capable of
it.<br><br>
<br>
</font><blockquote type=cite class=cite cite="">I would like to setup a
test station here in Golden sometime this Fall.<br><br>
Also, I will be installing one of the new vaults I showed at last
Netops meeting (with a few design changes) at one of our sites in Wyoming
soon. I hope to put some info out onto the new anss-netops list
server for all to peruse. Are you guys interested in using a
watertight vault system with a 1/2" glass base? Thought I put
out some "feelers" to get an idea of interest in regional
seismic community.</blockquote><br>
<font color="#0000FF">We might actually have a site where that could be
useful. We'll have to keep in touch about it. Right now we're
not sure whether the landowner is really going to give us permission or
not. We prefer to install sites that, as an old colleague of mine
would say, you could put the tailgate on. But this one could be
different.<br><br>
<br>
Our experience: it works, sort of. At 100sps continuous x 6
channels, the supposed throughput of the radio and VW network should have
no problem. However, in practice we see horribly long latencies,
and we're not quite sure why yet. It could be the Reftek software;
Reftek acquisition software; DOI networks and the DMZ export; VW network;
or a combination of things. We have done extensive testing and we
still don't know yet. Everytime we run a speedtest, we get values
no less than 100kbps (when we're limited to the cdma network), which
still should be plenty for continuous telemetry. Bob Busby never
saw a problem, but that's because he only ran 3 channels at 40sps.
When we throttle the rates back to 6-ch at 50sps, it seems the latency
improves. If we turn off 3 channels, so we only send 3 channels at
100sps, the latencies improve. When we test with a Kinemetrics K2
(4-ch, 100sps), we had no latency, but it doesn't need the extra step of
funneling through the DMZ. Points towards a bandwidth issue.
So we ran a throughput test with sendfile and getfile and repeatedly sent
a 10MB file for an hour, we experienced no latency and throughput held
solid at 140kbps (we only get a 1x signal in Menlo Park-in the heart of
Silicon Valley-go figure). So much for bandwidth on the VW cell
system. So, now we are sending a second RavenX to Reftek.
They agreed to try out a RavenX with a 6-ch RT-130. That's why I'm
waiting for a second static IP. They have done tests with a
different modem, but never on a 6-ch unit, only 3-ch. Unfortunately
the latency varies unexplainably throughout the day. I've attached
a plot we made of latencies from two different Reftek 130 stations: AFD
uses the cell telemetry and JBNB uses direct spread-spectrum telemetry
(thru a repeater) to our office. Note the scale on the
Y-axis. The lower chart shows how complete the data packets were
for any given 10 minute period over the same period of time. You
can see that when the latency gets really long, we often see dropped
packets. The second figure shows a month-long representation of
that. We happen to also be setting up our first satellite ISP
telemetry in the office (thanks to your help) that we want to use at
another site. We planned on using a Reftek 130 there too, and since
it will be acquired by the same server in the DMZ, that will give us a
comparison to see if the latencies come up there. Anyway, I'd like
to see data come in better than what we're getting now, so that's why
we're still trying to work out the bugs. If you don't want to push
as much data, you should be fine.<br><br>
I'll go ahead and tweak this email and send it to the netops group since
I know there was quite a bit of interest in cellular telemetry. For
the price, it's hard to beat. Hope this helps!<br><br>
Dave<br><br>
</font>__________________________________________________________<br>
USGS - Earthquake Hazards Team - NCSN Field Operations Manager<br>
David S.
Croker
office (650) 329-4697<br>
345 Middlefield Rd, MS
977
fax (650) 329-4732<br>
Menlo Park, CA
94025
cell (650) 465-4334<br>
email: croker@usgs.gov<br>
Quake info:
<a href="http://quake.wr.usgs.gov/" eudora="autourl">
http://quake.wr.usgs.gov/</a><br>
USGS URL:
<a href="http://www.usgs.gov/" eudora="autourl">http://www.usgs.gov/</a>
<br><br>
</blockquote></body>
</html>