PSN-L Email List Message

Subject: Fwd: Re: System Configuration
From: John or Jan Lahr johnjan@........
Date: Wed, 11 Jun 2003 20:00:45 -0600




>The USGS Earthworm system includes a standardized Internet
>protocol that might be used.
>
>See:
>http://orfeus.knmi.nl/newsletter/vol5no1/earthworm.html
>
>Cheers,
>John
>
>------------- Begin Forwarded Message -------------
>
> >Date: Mon, 09 Jun 2003 14:17:34 -0700
> >From: Karl Cunningham 
> >To: winsdr@..............
> >Cc: psn-l@..............
> >Subject: Re: System Configuration
> >X-Mailer: Mulberry/2.1.1 (Win32)
> >X-Virus-Scanned: by AMaViS perl-11
> >Reply-To: psn-l@..............
> >Sender: psn-l-request@..............
> >
> >--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)
> >
> >To leave this list email PSN-L-REQUEST@.............. with
> >the body of the message (first line only): unsubscribe
> >See http://www.seismicnet.com/maillist.html for more information.
>
>
>------------- End Forwarded Message -------------
>
>
>
>------------- End Forwarded Message -------------

__________________________________________________________

Public Seismic Network Mailing List (PSN-L)


[ Top ] [ Back ] [ Home Page ]