[ANSS-netops] K2 interface with GX-440 modem: k2ew_tcp
Meremonte, Mark
mmeremonte at usbr.gov
Mon Jan 12 19:46:41 UTC 2015
Thank you Jacob & Paul!
Yes I did send same question to both lists figuring there may be a number
of EW users not on the ANSS_NETOPS list. I apologize too to those who are
on both.
I will follow yours & Paul's suggestions for our K2/GX440 to EW instance.
Best Regards,
Mark
On Mon, Jan 12, 2015 at 11:49 AM, Jacob Crummey <jcrummey at gps.caltech.edu>
wrote:
> I am resending my response here. I apologize to those who are on both
> Net-Ops and EW mailing lists:
>
> Hi Mark,
>
> As Paul said, we still have a station or two with a K2 connected to a
> GX440 though the serial port on the GX440. Below is how we have the K2 SDS
> configured. Followed by a screenshot of the configuration of the GX440.
> Followed by the config for the k2ew_tcp .d file (with the IP address x’ed
> out). Not saying this is the best or only way to configure a streaming K2,
> but this config has been working for us.
>
> As you may know, when streaming with the K2’s you must set the
> “auto-answer mode” in the K2 to off (and remove any internal modem). I
> also disable the auto-baud setting on the K2 because sometimes it will
> start cycling through baud rates when you don’t want it too (or it at least
> eliminates that as a possible problem).
>
> If you have any other questions please let me know.
>
> -Jacob
>
> K2 SDS config:
>
> * dis ser
> *** SERIAL DATA STREAM PARAMETERS
> 6 Channel(s) Selected: 1 2 3 4 5 6
> Stream Format = 1
> Stream Timeout = 0
> Stream Block Size = 100 scans
> Stream Buffer Size = 64 blocks, 1048576 bytes
> Stream Sample Rate = 100 samples per second
>
>
>
>
>
> {jcrummey at import1:k2s} cat k2ew_tcp_CI_MIS.d
> TcpAddr x.x.x.x
> TcpPort 10001
> ModuleId MOD_K2EW_CI_MIS
> Network CI
> StationID MIS # Mira Catalina School, Palos Verdes
> ChannelNames HNE,HNN,HNZ,HN3,HN2,HN1
> LocationNames 00,00,00,01,01,01
> InvPolFlags 0,0,0,0,0,0
> RestartFile "/app/aqms/ew/run/params/k2s/restart_files/CI.MIS.k2"
>
> # Source the shared configs
>
> @k2s/k2ew_tcp_shared.d
> {jcrummey at import1:k2s} cat k2ew_tcp_shared.d
>
> RingName K2_RING # transport ring to use for input/output
>
> LogFile 2 # If 0, don't output to logfile; if 1, do
> # if 2, log to module log but not
> stderr/stdout
>
> HeartbeatInt 60 # Heartbeat interval in seconds
>
> BasePinno 1001 # Earthworm pin numbers are assigned by
> # adding this base number to the stream
> # number (0 - 5) of each packet
> # default: 0
>
> LCFlag 1 # use default loc code if none specified
>
> MaxRestartAge 60 # Maximum age of the restart file, in
> seconds
> # If the restart file is older than this
> # when k2ew restarts, a normal start will
> # be used
> # Should be less than WaitTime (below)
> # default: 0 (seconds)
>
> CommTimeout 10000 # If unable to communicate with K2 for X
> # milliseconds, then terminate
> # default: 5000 (milliseconds)
>
> WaitTime 120 # Maximum number of seconds to wait for a
> # packet to be resent from the k2
> # default: 60 (seconds)
>
> DontQuit # Optional command; if present, k2ew will
> # not quit on timeouts. K2ew will quit on
> # errors in any event.
>
> StatusInterval 15 # Interval in minutes between requests for
> # K2 status (if 0, then no status requests)
> # default: 30 (minutes)
>
> OnBattery # Report when K2 loses external power and
> is
> # running on battery power.
> # default: do not report
>
> #LowBattAlarm 110 # In tenths of volts, threshold for low
> # battery alarm (if -1, then no alarm)
> # default: -1
>
> #MinDiskKB 500 -1 # Low disk alarm threshold in Kilobytes,
> for
> # disk A and disk B (if -1, then no alarm)
> # default: -1 -1
>
> ExtStatus # Request extended status with normal
> status
> # Comment this out for no extended status
> # default: no extended status
>
> #LowTempAlarm 150 # Low temperature alarm threshold, in
> tenths
> # degree, C; default: -1000
>
> #HighTempAlarm 350 # High temperature alarm threshold, in
> tenths
> # degree, C; default: 1000
>
> GPSLockAlarm 36 # hours after an unlock to sound an alarm
>
> InjectInfo # a new v2.33 directive to inject K2INFO
> # messages into
> # the RING...these are picked up by TNW
>
>
>
>
> On Jan 12, 2015, at 10:09 AM, Paul Friberg <p.friberg at gmail.com> wrote:
>
>
> Mark,
>
> k2ew_tcp uses TCP protocol so stick with TCP. The k2ew_tcp program, if I
> recall correctly since its been quite a while since I looked at that code,
> tries to set the K2 into the proper mode for streaming....but that may have
> been the k2ew_tty version which worked over serial.
>
> Caltech has (probably had) a number of k2ew_tcp implementations so it
> wouldn't hurt for you to contact someone there who is responsible for
> keeping these suckers alive (till they can be replaced).
>
> Cheers,
>
> Paul
>
> On Mon, Jan 12, 2015 at 11:35 AM, Meremonte, Mark <mmeremonte at usbr.gov>
> wrote:
>
>> We have set up:
>>
>> -- a K2 Altus for serial datastream at 100 sps on 3 channels, using Mode
>> 1, baud of 38400, default buffer size, and looks like the default packet
>> size is "dynamic 2048". (Not sure what dynamic 2048 really means though.)
>>
>> -- The K2 is serially connected to a GX-440 with a static public-IP.
>> Its serial configuration is set for 38400, 8, N, 1 with no flow control, IP
>> protocol is set to TCP, and port set to 16030. Thus the modem (similar to
>> Lantronix devices which others have used) wraps an IP wrapper around the
>> serial packets and transmits them to destination IP or our Earthworm host
>> system which is purposely located not behind a firewall at this time to
>> simplify testing and too connected to a GX-440 modem with a static
>> public-IP.
>>
>> -- K2ew_tcp has the source IP set to GX-440 modem's public IP and the
>> port is set to 16030.
>>
>>
>> At first the k2ew_tcp module was "dead" but then in a couple of minutes
>> after K2 started sending data it switched status -- alive. However, a
>> sniffwave showed no data. a packet sniffer showed packets from the source
>> IP and port arriving at EW host but packets sizes were small < 80 bytes and
>> there were numerous re-transmissions arriving. I expected packet sizes on
>> the order of 1024 - 2048 bytes. The re-transmissions seem to indicate
>> that there is no handshaking between source IP and EW host IP. Eventually
>> the k2ew_tcp module went "dead" again.
>>
>> Thus I am wondering if K2 set up using wrong mode where mode 3 uses full
>> handshaking, possibly protocol should be UDP rather than TCP to allow
>> packets to stream without handshaking, or simply have k2ew_tcp.d configured
>> wrong.
>>
>> Hope I have described the scenario with sufficient detail to understand.
>>
>> Mark
>>
>> --
>> *********************************************************
>> Mark Meremonte Geophysicist
>> U.S. Bureau of Reclamation: Seismotectonics & Geophysics Group
>> Denver Federal Center Work: 303-445-3298 Cell: 303-808-3894
>> POBox 25007, 85-833000 Email: mmeremonte at usbr.gov
>> Denver, CO 80225 Web: http://www.usbr.gov
>> Ship: U.S. Bureau of Reclamation, DFC, Bldg. 67-10th Floor, Denver, CO
>> 80225
>> **********************************************************
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Earthworm Community Forum" group.
>>
>> To post to this group, send an email to earthworm_forum at googlegroups.com
>>
>> To unsubscribe from this group, send an email to
>> earthworm_forum+unsubscribe at googlegroups.com
>>
>> For more options, visit this group at
>> http://groups.google.com/group/earthworm_forum?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Earthworm Community Forum" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to earthworm_forum+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> ===================================
> Paul Friberg p.friberg at isti.com
> ISTI==Instrumental Software Technologies, Inc.
> Phone 845.256.9290 FAX 845.256.9299
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Earthworm Community Forum" group.
>
> To post to this group, send an email to earthworm_forum at googlegroups.com
>
> To unsubscribe from this group, send an email to
> earthworm_forum+unsubscribe at googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/earthworm_forum?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Earthworm Community Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to earthworm_forum+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Earthworm Community Forum" group.
>
> To post to this group, send an email to earthworm_forum at googlegroups.com
>
> To unsubscribe from this group, send an email to
> earthworm_forum+unsubscribe at googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/earthworm_forum?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Earthworm Community Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to earthworm_forum+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> On Jan 12, 2015, at 8:56 AM, Ogie Kuraica <ogie at kmi.com> wrote:
>
> Mark,
>
>
> The K2 has been obsolete product for about 7 years and I will try to do my
> best recollection:-)
>
>
> Dynamic 2048” applies to file transfers in in block mode. When enabled,
> this mode adapts the packet size to the largest packet size that will
> transfer reliably – up to 2048 bytes. Larger packet sizes increase speed of
> file transfers on TCP connections.
>
>
> - In the K2’s streaming mode (which is what you are trying to use),
> packet sizes will be 1 second of data compressed to 2 or 3 bytes per
> sample. So data packets will be between ~200 and ~300 bytes. There are also
> other packets included such as message, status and parameter packets that
> vary from very small to very large.
>
>
>
> - Mode 1 is what is typically used for K2 streaming. It sends data
> without a handshake required, and the host can talk back to the K2 to
> request any missing packets. 99% of all streaming K2’s use Mode 1.
>
>
>
> - Basically, th2 K2’s streaming parameters are typically set to:
>
> a) Mode (typically 1)
>
> b) SPS (much match recorded SPS)
>
> c) Compressed or not
>
> d) Selected streamed channels
>
> e) Buffer size (on disk)
>
>
>
> - I would suggest use of the TCP rather than UDP (between the two
> GX-440 modems) and allow the TCP protocol to take care of error correction.
> Using UDP will likely work too, but just pushes error correction up into
> the K2’s protocol.
>
>
> - We would suggest that you simplify this whole thing a bit to
> try and isolate where the problems are. At the moment you have GX-440
> modems that we certainly know nothing about, an EW module (ISTI may help
> you) , and uncertainty about the streaming parameters of the K2. I would
> eliminate the GX-440 (just use a serial port or direct TCP connection) or
> EW (just use Altus File Assistant to display waveforms for example) and get
> each pieces of the system working before trying to tie it all together.
>
>
> Cheers,
>
>
> Ogie
>
> From: <Meremonte>, Mark <mmeremonte at usbr.gov<mailto:mmeremonte at usbr.gov
> <mmeremonte at usbr.gov>>>
> Date: Friday, January 9, 2015 at 4:40 PM
> To: "anss-netops at geohazards.usgs.gov<
> mailto:anss-netops at geohazards.usgs.gov <anss-netops at geohazards.usgs.gov>>"
> <anss-netops at geohazards.usgs.gov<mailto:anss-netops at geohazards.usgs.gov
> <anss-netops at geohazards.usgs.gov>>>, Glenda Besana-Ostman <
> gbesanaostman at usbr.gov<mailto:gbesanaostman at usbr.gov
> <gbesanaostman at usbr.gov>>>, Rocky Pelfrey <RPelfrey at feeneywireless.com<
> mailto:RPelfrey at feeneywireless.com <RPelfrey at feeneywireless.com>>>
> Subject: [ANSS-netops] K2 interface with GX-440 modem: k2ew_tcp
>
> We have set up:
> -- a K2 Altus for serial datastream at 100 sps on 3 channels, using Mode
> 1, baud of 38400, default buffer size, and looks like the default packet
> size is "dynamic 2048". (Not sure what dynamic 2048 really means though.)
>
> -- The K2 is serially connected to a GX-440 with a static public-IP. Its
> serial configuration is set for 38400, 8, N, 1 with no flow control, IP
> protocol is set to TCP, and port set to 16030. Thus the modem (similar to
> Lantronix devices which others have used) wraps an IP wrapper around the
> serial packets and transmits them to destination IP or our Earthworm host
> system which is purposely located not behind a firewall at this time to
> simplify testing and too connected to a GX-440 modem with a static
> public-IP.
>
> -- K2ew_tcp has the source IP set to GX-440 modem's public IP and the
> port is set to 16030.
>
> At first the k2ew_tcp module was "dead" but then in a couple of minutes
> after K2 started sending data it switched status -- alive. However, a
> sniffwave showed no data. a packet sniffer showed packets from the source
> IP and port arriving at EW host but packets sizes were small < 80 bytes and
> there were numerous re-transmissions arriving. I expected packet sizes on
> the order of 1024 - 2048 bytes. The re-transmissions seem to indicate
> that there is no handshaking between source IP and EW host IP. Eventually
> the k2ew_tcp module went "dead" again.
>
> Thus I am wondering if K2 set up using wrong mode where mode 3 uses full
> handshaking, possibly protocol should be UDP rather than TCP to allow
> packets to stream without handshaking, or simply have k2ew_tcp.d configured
> wrong.
>
> Hope I have described the scenario with sufficient detail to understand.
> Mark
>
>
> --
> *********************************************************
> Mark Meremonte Geophysicist
> U.S. Bureau of Reclamation: Seismotectonics & Geophysics Group
> Denver Federal Center Work: 303-445-3298 Cell: 303-808-3894
> POBox 25007, 85-833000 Email: mmeremonte at usbr.gov<
> mailto:mmeremonte at usbr.gov <mmeremonte at usbr.gov>>
> Denver, CO 80225 Web: http://www.usbr.gov
> Ship: U.S. Bureau of Reclamation, DFC, Bldg. 67-10th Floor, Denver, CO
> 80225
> **********************************************************
> _______________________________________________
> ANSS-netops mailing list
> ANSS-netops at geohazards.usgs.gov
> https://geohazards.usgs.gov/mailman/listinfo/anss-netops
>
>
>
--
*********************************************************
Mark Meremonte Geophysicist
U.S. Bureau of Reclamation: Seismotectonics & Geophysics Group
Denver Federal Center Work: 303-445-3298 Cell: 303-808-3894
POBox 25007, 85-833000 Email: mmeremonte at usbr.gov
Denver, CO 80225 Web: http://www.usbr.gov
Ship: U.S. Bureau of Reclamation, DFC, Bldg. 67-10th Floor, Denver, CO
80225
**********************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20150112/56c601a8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.png
Type: image/png
Size: 119150 bytes
Desc: not available
URL: <http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20150112/56c601a8/attachment-0001.png>
More information about the ANSS-netops
mailing list