Pinging a Touch Panel - Typical packet size?

TaxiDriver

Hey guys,

interesting problem experiencing, using client Wireless network, and im experiencing very clunky touch panel activity, with moderate amounts of missed responses in connection utility. Now conducting a standard command prompt ping to the touch panel, when I vary the packet size can get substantial changes in packet loss. if standard 33 bytes ping, 1% loss. 400 bytes packet - 13% loss, 40 000 bytes - 62% loss.

So what is a typical packet size of data for a button event, page flip command, level event, etc that touch panel transmits and receives from netlinx controller? Even if can ascertain ball park figures, i can do appropriate ping sized packets to prove network issues for certain packet sizes is critical to touch panel smooth usablity.

PhreaK

Have a read through the ICSP patent. It has a full break down of the messaging structure and packet sizes. Technote #250 also has the network utilization side of things summarized somewhat.

In addition to the button events etc you also have all the system comms which will be taking place regardless of touch panel activity (master UDP broadcast and response etc).

Your max packet size will then be the lesser of either the largest ICSP packets or the MTU of the infrastructure you're running on.

If all else fails / you fall asleep one page into that doc capture a bit of traffic and have a look at what's actually happening in your situation.

ericmedley

TaxiDriver wrote: »

Hey guys,

interesting problem experiencing, using client Wireless network, and im experiencing very clunky touch panel activity, with moderate amounts of missed responses in connection utility. Now conducting a standard command prompt ping to the touch panel, when I vary the packet size can get substantial changes in packet loss. if standard 33 bytes ping, 1% loss. 400 bytes packet - 13% loss, 40 000 bytes - 62% loss.

So what is a typical packet size of data for a button event, page flip command, level event, etc that touch panel transmits and receives from netlinx controller? Even if can ascertain ball park figures, i can do appropriate ping sized packets to prove network issues for certain packet sizes is critical to touch panel smooth usablity.

You might be following a red herring by going after the packet loss from the data side of things. I've found that when a wireless network is setup correctly things seem to work pretty okay.

One of the most common things I've found in situations where the signal strength was 'strong' but communications were flaky ended up being interference with the analog side of the WiFi signal. We've all heard this phenomenon when driving in the country between towns where our FM radios were picket-fencing back and forth between two FM stations competing for the same air space. When they're going back and forth you hear each station very clearly but their program is interrupted by the other. In the data world this is going to translate into missed packets.

I'd look for WAPs that are on the same channel. (Perhaps another in the house, or a neighbor) Things like microwaves, refrigerators, wine cellars or anything with a processor chip in it can cause interference.

I'd highly recommend getting WiFi Spy or something to look at the RF spectrum in the installation space.

Your laptop's wireless bar graph or the panel's signal level meter are not going to tell you what's really going on.

DHawthorne

Some locations simply wreak havoc on all kinds of wireless. I had a client where nothing wireless would work except his cell phones. WAPs only worked in the room where they were located, and even then it was spotty. I never did figure out if it was something in his wall paint, or house wiring, or the fact that he had some enormous high tension power lines in his south forty.

Beachfront properties are another one ... my theory is all the dissolved minerals in the water cause all sorts of funky RF reflections as the water moves around, but I have never done a beach hose that I didn't have RF issues. I even had one where an in-wall sensor (glass break sensor, back when we still did alarm system) had it's indicator light flashing all the time. It didn't trip, the light just flashed. Only one in the house did this, and replacements did the same thing. I discover if I just shielded it with my hand, the flashing stopped. Had to be some funky signal bouncing off the water, and I wound up telling the customer they just had to live with it, and nothing was wrong. Good thing it was in a staircase, not a bedroom.

I had another case with an AMX RF panel (an old two-way Viewpoint) would drop it's connection whenever my helper used his cell phone. My phone was fine, only his killed it.

The point is, environment matters a lot, and now that we are all forced to be WiFi experts, we need to be aware of it. Tossing a bunch of extra WAPs in for more coverage is not always the best idea.

Jorde_V

TaxiDriver wrote: »

Hey guys,

interesting problem experiencing, using client Wireless network, and im experiencing very clunky touch panel activity, with moderate amounts of missed responses in connection utility. Now conducting a standard command prompt ping to the touch panel, when I vary the packet size can get substantial changes in packet loss. if standard 33 bytes ping, 1% loss. 400 bytes packet - 13% loss, 40 000 bytes - 62% loss.

So what is a typical packet size of data for a button event, page flip command, level event, etc that touch panel transmits and receives from netlinx controller? Even if can ascertain ball park figures, i can do appropriate ping sized packets to prove network issues for certain packet sizes is critical to touch panel smooth usablity.

I sniffed some packets with wireshark and what I've seen pass was 96 bytes. Network traffic wasn't that bad at all. But I'm guessing it didn't sniff everything.