Being an amateur radio buff -- be careful what you ask for-- radio waves may
create problems for you that you don't have now. I have a Davis weather
station that has an incurable RF problem from ten meter transmissions from
the repeater I operate here at my house. The local police transmitters here
have interfered with data collecting at a local manufacturing company. So
far, Larry's boards are not being bothered. Changing wiring might open a
Pandora's box!
----- Original Message -----
From: "Karl Cunningham" 
To: 
Cc: 
Sent: Monday, June 09, 2003 4:17 PM
Subject: Re: System Configuration


> --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.
>

__________________________________________________________

Public Seismic Network Mailing List (PSN-L)