Quote:
Originally Posted by byteit101
To overcome the 50 hz limit of the dashboard packets (since it was TCP or DB packets this year, no udp)
|
Err... Firstly, isn't 50 Hz fast enough? You know the average monitor displays at a max of 60 Hz and that cinema movies are 24 Hz? If 50 Hz is fast enough to sample input
to the robot, one would think it would be fast enough to sample output as well, especially since anything faster than 50 Hz isn't very useful to a human reading the display. Also, you know the DB packets are UDP, yes? The bit in the parens confuses me.
Quote:
Originally Posted by byteit101
And the TCP stream can also update each control as it comes in, instead of all at once after the data has come in, been processed, etc, so (minor) improvement in that regard
|
Processing a group of controls all passed in as a single packet is faster than each control at once coming through a TCP stream since you spend less time waiting (if only for a very short time) for data to filter through the network stack before you do something with it - a single blocking receive call would obviously be faster than multiple ones. You're still ignoring the importance of using UDP - it allows you to just ignore bad data, not wait for it to be resent. Even if there are few transmission errors, you still have to wait on those in TCP.
There's a reason WPI chose UDP and implemented the dashboard data packets in the manner they did. Besides, even if using TCP did increase performance a small bit, 50 Hz is a more than ample refresh rate for a human.