Can't Connect to GDS 2.0 #1280
-
Hello all, My goal is to use the new FPrime GDS with the old GroundInterface component to relay commands, events, and telemetry. I'm having trouble connecting to the GDS with my deployment, and I'm not quite sure how to proceed from where I am. Let me break down the setup and what I have done so far. I am working with fprime v2.0.1. I installed the GDS by cloning the fprime-gds repository here, checking out the 2.0 tag, and running On the GDS end of things, I started the GDS with the following command: When sprinkling print statements throughout the GDS source code, I've verified that the data is being received through the UART adapter, successfully getting deframed, passing the checksum, and being sent to the TCP server. However, I've determined by adding print statements that the packets are never reaching the distributor. This is where my knowledge gets shaky, because I know very little about networking. If my understanding is correct, the data is either not making it from the TCP server to the TCP client, or it is not making it from the TCP client to the distributor. I've traced my way all the way through the code until reaching the
I used wireshark to determine that there are indeed packets flowing between 127.0.0.1 port 50050 and 127.0.0.1 port 53630. At this point, I've done a lot of work to diagnose the problem, but I feel like I'm missing something simple. Is there some documentation I can be looking at? Thanks for the help. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
@legounicycler Try setting |
Beta Was this translation helpful? Give feedback.
-
If the call is getting to the TCP server, then it is past the stage where check summing is done. I've never seen an issue with the Did you see any issues in the log files for the GDS? There might be an error in there somewhere. I am guessing there was trouble allocating port 50050 and the error is in the log files somewhere (e.g. REf/log//) In addition, you can use the latest GDS with older versions of F´. Have you tried The next place to place a print statement if those don't help is: To show the on_recv method is called within the GDS. |
Beta Was this translation helpful? Give feedback.
-
It's been a while since I came back to this post, but just wanted to update that I indeed did get this issue resolved. It turns out that the packets WERE traveling through the TCP connection as expected, and I was just missing the debug print statement I had used to verify this as it got burried under lots of other debug print statements. The ultimate error I had made was that I changed the packet header types from F32 to F16 in my FPrime deployment, but hadn't changed the configuration of the GDS to accept these smaller packet headers. |
Beta Was this translation helpful? Give feedback.
It's been a while since I came back to this post, but just wanted to update that I indeed did get this issue resolved. It turns out that the packets WERE traveling through the TCP connection as expected, and I was just missing the debug print statement I had used to verify this as it got burried under lots of other debug print statements. The ultimate error I had made was that I changed the packet header types from F32 to F16 in my FPrime deployment, but hadn't changed the configuration of the GDS to accept these smaller packet headers.