Hi -
We want to build an Eclipse RCP dashboard program, and I am trying to figure out the underlying wire protocol that is used by all the pack code (which comes as an example project in NetBeans). I know all about the ‘SmartDashboard’ and NetWork tables - but I’m looking to latch on to the lowerlevel protocol going from the robot to the driver station itself. I’ve been down through the the WPILib code, and used Wireshark to capture what would appear to be the messages under UDP broadcast, but it’s not jumping out at me. I’m assuming someone who understands LabView programming can probably point me at something that makes this clear (we use Java) … since two years ago we had someone use LabView to make a dashboard that understood & displayed the data (and the ‘default’ LabView dashboard used to work - with the LEDs and little bar graph things). If I had until next build season to figure it out - I’m sure I could, but I’m looking for a quick nudge in the right direction.
Thanks in advance!
Stu
I don’t understand what you’re asking. You say you “…know all about the ‘SmartDashboard’ and NetWork tables…” Isn’t that exactly what is needed in order to make a Dashboard program?
For what it’s worth, the NT protocol is a client-server scheme with the robot as server and the Dashboard program(s) as client. It uses TCP to create the connection(s).
My advice is to use the smart dashboard or network tables protocol.
The low-level stuff you mention was a stop-gap protocol that sent serialized string buffers between robot and dashboard as payload of the UDP traffic. It still exists and you are welcome to use it, but it is low level and not an ideal candidate for multi language communications. It was pretty easy to use for LV since it was the LV serialized data format being used. So your teammate most likely just had a datatype defined and did the flatten and unflatten of the data. On the C or Java side, they would have needed to construct a buffer using the class for the serial data. Going between Java and C, there is absolutely no need to use the LV data format. If you are capable of it, you can use your own data format that the robot writes into the buffer and your C code reads out.
But again, that is a decent amount of work compared to using networkTables.
Greg McKaskle
Has it moved somewhere? Last time we did something like this it was running over UDP 1165 and 1170. We tried running that program and got nothing, presumably because it’s changed ports. The docs say there’s something on 1130 and 1140, but we didn’t pick up anything there either. Even if the packet format has changed some, shouldn’t we at least be able to receive and hex-dump them? Or has something else changed?
I know this is “obsolete”, but we’re just trying to put together a last-minute hack to look at a couple of things, leveraging something we thought we understood from previous experience. Or not, it seems. 
The dashboard data didn’t use an additional port, it sent data through the status protocol. The VI Receive DS Packet has two outputs on its lower edge. One is high priority and one low priority data. You cast the appropriate one to your datatype.
Greg McKaskle