# Parsing TCP Data Packet **URL:** \ **Category:** Ignition\ **Created:** [January 28, 2019, 10:10pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173 "2019-01-28T22:10:34Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 28, 2019, 10:10pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/1 "2019-01-28T22:10:34Z")
I’m looking into connecting some NCD wireless sensors that can output over TCP. The data packet will come in as hexadecimal bytes. I’ve learned all about their packet structure and how to perform the necessary math to convert it to real world numbers. I want to get a sense of parsing the data once Ignition has it before I make any purchases. Can anyone tell me where in Ignition I should parse the data (and how 🙂) This is what I’ve done so far… ![PacketDataDescription](https://us1.discourse-cdn.com/inductiveautomation/original/2X/d/ddfeee188788bd45cbba7182fbf8e45a33c22347.jpeg) ![SamplePacket_Parsed](https://us1.discourse-cdn.com/inductiveautomation/original/2X/6/6ad9d4be2a9c8df66361d11d646c8b27d3106514.jpeg) ![SampleScreen](https://us1.discourse-cdn.com/inductiveautomation/original/2X/f/ffcd0eacb04402572ff2fc37917aa2416b160231.jpeg) ![MathOps](https://us1.discourse-cdn.com/inductiveautomation/original/2X/f/f080d7e756039d19281c1c81ecbdb09277ea864c.jpeg) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [January 28, 2019, 10:22pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/2 "2019-01-28T22:22:48Z")
I looked at some docs for that thing real quick and it seems like it’s not TCP, but rather some lower level protocol over wireless, and that you’ll need that little receiver dongle and drivers hooked up to the receiving PC at which point you can access the incoming data via a serial port. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 28, 2019, 11:54pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/3 "2019-01-28T23:54:02Z")
Hmmm, I see what you are saying. They do have a [gateway](https://ncd.io/receiving-wireless-sensor-data-over-ethernet/) that receives the wireless data and relays it via Ethernet. It looks like the data packet is unaltered from what I originally posted. What do you think? I’m in new territory here. Thanks Kevin ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 29, 2019, 2:48pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/4 "2019-01-29T14:48:53Z")
I asked NCD about this, and they said the data packet would be the same as what I posted. So, I just need to figure out how/where to parse it as it comes in. ---
**Author:** ![ryanjmclaughlin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryanjmclaughlin/32/4318_2.png) [@ryanjmclaughlin](https://forum.inductiveautomation.com/u/ryanjmclaughlin)\ **Post date:** [January 29, 2019, 2:56pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/5 "2019-01-29T14:56:05Z")
What is the rate the data is coming in? You could setup a TCP device to receive the packets, then processing the incoming data with a Tag change script to process the hex into real value and write out the data you care about to other tags. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 29, 2019, 3:14pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/6 "2019-01-29T15:14:39Z")
I believe the data rate is variable, meaning that I can change the rate. I would probably set them to something like a 3-5 min scan rate. One question though, the sensor gateway can handle multiple sensors at once, and the data packet has information about which sensor it is coming from. Is there a way to setup the tcp driver with multiple tags according to the source address, or setup a device per sensor. They would all listen to port 2101 so I would have to figure out how to filter the messages from only on sensor. Thoughts? ---
**Author:** ![ryanjmclaughlin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryanjmclaughlin/32/4318_2.png) [@ryanjmclaughlin](https://forum.inductiveautomation.com/u/ryanjmclaughlin)\ **Post date:** [January 29, 2019, 3:23pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/7 "2019-01-29T15:23:31Z")
That’s plenty slow, I’d only be worries if you were going faster than like every 100ms. Just parse out the data to extract the source address. You might have a tag structure like this: - GatewayData - 0A0A0A0A0A0A0A - 0B0B0B0B0B0B0B When data is received on GatewayData, you could parse the data, then write the value to the resulting value tag. system.tag.write(sourceAddress, ‘123.123’) ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 29, 2019, 3:28pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/8 "2019-01-29T15:28:02Z")
That makes perfect sense. I believe I can make them work. If I can get the purchase approved, I will set them up and post the process in case anyone else would like to try NCD wireless sensors. Thanks Ryan. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 29, 2019, 3:42pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/9 "2019-01-29T15:42:25Z")
IIRC, the TCP device munges all incoming data that is \>7bit. Consider using direct java networking to open a listening socket and a thread to read bytes from it. Then use NIO ByteBuffers to read your raw data from the bytes. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 29, 2019, 3:46pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/10 "2019-01-29T15:46:57Z")
I hope not, that sounds like more than I can handle. I guess I’ll just have to add it to the list of things to learn. The only problem is the list is getting longer, not shorter 😓 ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 29, 2019, 4:44pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/11 "2019-01-29T16:44:00Z")
> [@pturmel](#): > > IIRC, the TCP device munges all incoming data that is \>7bit. @Kevin.Herron Can you confirm this? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [January 29, 2019, 5:01pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/12 "2019-01-29T17:01:52Z")
The TCP driver is written to deal with ASCII data, not arbitrary binary, and information is lost when non-ASCII binary is read into the String tag the driver exposes. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 29, 2019, 6:26pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/13 "2019-01-29T18:26:42Z")
@AlThePal I’ve seen you have dealt with this somewhat in other posts. Do you have any updated code or advice for opening a TCP socket/port listener? I would greatly appreciate it. ---
**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\ **Post date:** [January 29, 2019, 7:14pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/14 "2019-01-29T19:14:20Z")
There’s a TCP driver for binary data on GitHub [Generic TCP driver](https://github.com/chi-Ignition/generic-tcp-driver/releases). It should fit your needs, but as it’s free and open source, there is no support. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 29, 2019, 7:22pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/15 "2019-01-29T19:22:36Z")
Nice, I will give it a try. Thanks ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [January 29, 2019, 9:13pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/16 "2019-01-29T21:13:03Z")
Can somebody point in the right direction on how to simulate, if possible, a data packet coming in over TCP, so I can test receiving and parsing it? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 29, 2019, 9:26pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/17 "2019-01-29T21:26:52Z")
I use [socat](http://manpages.ubuntu.com/manpages/trusty/man1/filan.1.html) for such tasks. Start with a binary file or files containing your encoded packets. ---
**Author:** ![Sanderd17](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/sanderd17/32/8735_2.png) [@Sanderd17](https://forum.inductiveautomation.com/u/Sanderd17)\ **Post date:** [January 30, 2019, 11:02am UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/18 "2019-01-30T11:02:20Z")
> [@Kevin.Herron](#): > > The TCP driver is written to deal with ASCII data, not arbitrary binary, and information is lost when non-ASCII binary is read into the String tag the driver exposes. I often use this driver to send data to printers. That data is regular text, but depending on the region, may contain special characters (accents). It's a coincidence that for my projects in France, I had to use other protocols for communicating with printers (file drop and printing via a client interface). But if I read that correctly, I wouldn't be able to use that driver for projects with TCP-driven printers when accents are involved. No matter what measures are taken in the printer or on the Ignition side? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [January 30, 2019, 12:54pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/19 "2019-01-30T12:54:35Z")
Sorry, I should have said UTF-8 there instead of ASCII. The only problem is when people try to turn the String payload back into binary data. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 30, 2019, 1:41pm UTC](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173/20 "2019-01-30T13:41:52Z")
> [@dkhayes117](#): > > I hope not, that sounds like more than I can handle. I guess I’ll just have to add it to the list of things to learn. Might as well get to it. You're going to need a socket-level interface that yields raw bytes. And interfaces like [DataInputStream](https://docs.oracle.com/javase/8/docs/api/java/io/DataInputStream.html) and [ByteBuffer](https://docs.oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html) will read multi-byte fields as integers and other data types for you. Don't re-invent the wheel. [Next page](https://forum.inductiveautomation.com/t/parsing-tcp-data-packet/22173.md?page=2)