[ANSS-netops] K2 interface with GX-440 modem: k2ew_tcp
Jacob Crummey
jcrummey at gps.caltech.edu
Mon Jan 12 18:49:46 UTC 2015
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>>
> 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<mailto:anss-netops at geohazards.usgs.gov>>, Glenda Besana-Ostman <gbesanaostman at usbr.gov<mailto:gbesanaostman at usbr.gov>>, Rocky Pelfrey <RPelfrey at feeneywireless.com<mailto: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>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20150112/749bd8ba/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/749bd8ba/attachment-0001.png>
More information about the ANSS-netops
mailing list