--On Monday, June 09, 2003 2:20 PM -0600 Henry Bland
 wrote:
>> This is probably a question for Larry, but thought it might have interest
>> 
>> 1.  Computer A is located near the seismometer, running the A/D card and
>> SDR Server, powered from an UPS.
>> 2.  Computer B, sitting next to Computer A running WinSDR, powered from
>> the same UPS as Computer A.  A short serial cable connects the two.
>> WinSDR is set to act as a server over TCP/IP.  This comptuer has a
>> moderate-size hard disk and only keeps a few days of record files.
>> 3.  Computer C, sitting in the house is running WinSDR, which is
>> configured as a client to receive data from Computer B.  This comptuer
>> has a big hard disk for a month or two of record files and serves as my
>> main WinSDR display.  It also serves replay requests to WinQuake.
>> 4.  Router/Firewall forwards TCP/IP request from WinSDR clients to
>> comptuer B.
>> 
> At the University of Calgary we've developed our own datalogger hardware
> which works with the same microcontroller (a Rabbit) as Larry Cochrane's
> datalogger.  Our version uses a simple internet protocol for
> communication rather than serial lines.  Specifically, we transmit data
> in short UDP packets. Our 4-channel datalogger is run-time configurable
> using SNMP. Initial network addresses are obtained using DHCP so all
> configuration can be done over the network. We currently can handle 4
> channels of  24-bit samples at a rate of 2000 per second (we hope to push
> this to 4000 SPS). Our logger works well, particularly with off-the-shelf
> wireless access points. This configuration avoids the need for a
> serial-network computer (and associated fan noise). The additional
> hardware cost is negligible (see the ethernet-enabled core modules at
> www.rabbitsemiconductor.com).  So yes, it can be done.  I am definately
> interested in a low-cost commercial equivalent.  Are there any existing,
> open standards for *simple* continuous seismic data communication over
> the internet? It would be great if dataloggers such as Seismowin, WinSDR
> and Seislog could support an open standard for simplistic network
> dataloggers. I know that Mauro Mariotti has shown interest in adding
> streaming network support to Seismowin.  I've written a driver for
> Seislog to handle our network dataloggers. Is this a well trodden path?
>
>Cheers,
>-Henry Bland
>University of Calgary


Henry --

I'm CCing the main PSN list as I think this may have wider interest.

I think a standardized Internet protocol for distribution of seismic data
has a lot of merit, and I have not seen any standardized format although I
have not done any kind of thorough search.  It's possible that the owner of
a seemingly-proprietary protocol that meets the general need could be
persuaded to release it for general use.

Just to brainstorm for a minute or two on the subject:  I forsee bandwidth
demand outstripping supply early on.  This would necessitate limiting
connections to authorized users and perhaps some other mitigating measures.


The following features may be of benefit in a proposed protocol...

1.  Non-lossy data compression.
2.  Support for various sample rates and resolutions (# of bits per sample).
3.  The ability to cut back on sample rate or announce to the client the
inability to support a requested sample rate or resolution.  The
distinction between a temporary vs. permanent limitation may be important
to the client.
4.  The ability to request data for any arbitrary time period.  As a
request such as this may involve a large amount of data, serving this
request might have to be done slowly over a long period of time due to
bandwidth limitations.  This would naturally include the ability to
announce to the client that data is not available for the requested period.
5.  Error detection/correction.  I'm no expert here, but I think this
mandates a non-streaming format.  TCP may be better than UDP for this.
6.  Authentication of the client attempting to connect.  If done with
passwords, this should be done over a secure channel (SSL?).
7.  I presently don't see the need for encryption of the data itself,
although this may be a desireable feature.
8.  Include time stamps with the data.

I can see a lot of demand for this.  Do I see an RFC in the future.

Regards.
Karl Cunningham

__________________________________________________________

Public Seismic Network Mailing List (PSN-L)