[ANSS-netops] K2 interface with GX-440 modem: k2ew_tcp

[Ogie Kuraica]

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