-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time Sync Question #1741
Comments
What's the actual question here? I can point you to https://docs.photonvision.org/en/v2025.1.1/docs/contributing/design-descriptions/time-sync.html Otherwise I'd have to see a wireshark capture or similar. |
Did I describe the protocol correctly? If I did then a further dive is needed because it isn’t working on the 2025rc raspberry pi. I’m imaging a pi now with the newest image. If that doesn’t work I’ll grab data if possible. ( wireshark on a separate pc won’t work unless I can did up a hub instead of a switch )On Jan 20, 2025, at 12:45 PM, Matt Morley ***@***.***> wrote:
What's the actual question here? I can point you to
https://docs.photonvision.org/en/v2025.1.1/docs/contributing/design-descriptions/time-sync.html
https://github.com/PhotonVision/photonvision/tree/main/photon-targeting/src/main/native/cpp/net
Otherwise I'd have to see a wireshark capture or similar.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Is the raspberry pi connected to a roborio running a robot program with the same version of our vendordep, and does the robot program construct a PhotonCamera? |
This is for the LabVIEW photonvision library. I was able to figure out that only the client sends data out port 5810. The server sends data out to the port that is the source port of the received packet. I was expecting that all data sent out would be on port 5810. So the documentation is a little imprecise (incorrect) when it says this: (That being said, the documentation is nice!) While having the server send data back out to the source port of the client works, it may not be very firewall friendly, depending on the firewall, as UDP is not a connection oriented protocol. I have wireshark screen captures if that helps. I won't pose them here unless you want them. I'll leave this open in case you want to change this to a documentation thing or whatever. I have what I need, so close this whenever you want. Thanks! |
Clients let the OS bind them to whatever random free port the OS wants, but the server only listens on port 5810. Please update the docs to clarify my wording there |
I have a question about time syncing protocol. Here the way it appears to work.
Server runs on the robot and waits for requests from clients on UDP port 5810
The format of the request is (10 bytes in all):
Version = 1 byte
ID = 1 byte (ping)
client time int64 (8 bytes)
The server responds with send a reply UDP message directly back to the sender IP address on port 5810
The format of the response is (18 bytes):
Version = 1 byte
ID = 2 byte (pong)
as received client time int64 (8 bytes)
server time from FPGA int64 (8 bytes)
Is this correct ? If not could you correct the protocol packets.
When trying this on a raspberry PI image (unrelated but so many things work, like identification of the co-proc as a raspberry pi) the pings are received and responded to but they appear not to be read or processed. There aren't any error messages and the NT variables from the co-processor indicate no PONGs have been received. (I've tested the protocol with a PC based client without issue.)
The text was updated successfully, but these errors were encountered: