[ANSS-netops] Fwd: Cellular Comm for stations
David S. Croker
croker at usgs.gov
Mon Jul 14 16:34:43 GMT 2008
Hi Folks,
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.
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.
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.
Cheers!
Dave
>Hi Mark,
>
>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.
>
>
>>-- service provider and Federal contact person at Veriazon or ATT;
>> According to Bob, Verizon was the better company to work with
>> seems like I remember
>
>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 at 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.
>
>>-- type of service and estimate of cost
>
>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.
>
>>-- bandwidth
>
>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.
>
>See below for our experiences with bandwidth, however.
>
>>-- type of cell modem (I have been looking into Raven XT modems)
>
>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.
>
>>-- type of antenna (I believe Bob uses some little hemispherical
>>antenna, not sure of db)
>
>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.
>
>Models: 800 MHz yagi (which is only good if you can only get 1X
>service in the boonies)--Antennex Y8066
> 1900MHz yagi (for EVDO service)--Telewave 1920Y9-WRU
> Dual-band omnis: Maxrad Bmax 824/1850 and Larson NMOC/P3E
> (we bought both, seem to be equals)
>Of course there are several options in these bands.
>
>>-- whether continuous or not and sample rates achieved
>
>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.
>
>>-- whether using static IPs and how many; or are you using dynamic
>
>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.
>
>>-- what about complying with advanced encryption standards
>
>We have not yet complied with any specific encryption standards, and
>I don't know if the Raven is capable of it.
>
>
>>I would like to setup a test station here in Golden sometime this Fall.
>>
>>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.
>
>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.
>
>
>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.
>
>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!
>
>Dave
>
>__________________________________________________________
>USGS - Earthquake Hazards Team - NCSN Field Operations Manager
>David S. Croker office (650) 329-4697
>345 Middlefield Rd, MS 977 fax (650) 329-4732
>Menlo Park, CA 94025 cell (650) 465-4334
>email: croker at usgs.gov
>Quake info: http://quake.wr.usgs.gov/
>USGS URL: http://www.usgs.gov/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20080714/15ae6dba/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cell test mode.pdf
Type: application/pdf
Size: 16987 bytes
Desc: not available
Url : http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20080714/15ae6dba/attachment-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JBN-AFD-latency-completeness1.JPG
Type: image/jpeg
Size: 159625 bytes
Desc: not available
Url : http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20080714/15ae6dba/attachment-0001.jpe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AFD latency vs completeness.jpg
Type: image/jpeg
Size: 320382 bytes
Desc: not available
Url : http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20080714/15ae6dba/attachment-0001.jpg
More information about the ANSS-netops
mailing list