PSN-L Email List Message
Subject: Re: System Configuration
From: "tdick" dickthomas01@.............
Date: Tue, 10 Jun 2003 09:35:38 -0500
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
----- Original Message -----
From: "Karl Cunningham"
Sent: Monday, June 09, 2003 4:17 PM
Subject: Re: System Configuration
> --On Monday, June 09, 2003 2:20 PM -0600 Henry Bland
> >> This is probably a question for Larry, but thought it might have
> >> 1. Computer A is located near the seismometer, running the A/D card
> >> 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
> > this to 4000 SPS). Our logger works well, particularly with
> > 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?
> >-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
> 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
> 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
> 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
> 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.
> 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)
[ Top ]
[ Back ]
[ Home Page ]