Added separate tcp server for uhf beacon #75
Conversation
There was a problem hiding this comment.
As I understand it, this is now the first simulated component that is not optional, is that correct? And all commands, responses, and bulk up/downloads are going through it, right? I guess this should run on the Zybo, since that's where the Endurosat lives, but it could also run on the ground station which a) might make it faster, and b) makes sense in that the GS can send configuration commands (e.g. enter Pipe mode). My point in all this is that the IP addresses will seldom all be localhost. Probably all three should be command line arguments, although you could default them to localhost and you could always set beacon IP to UHF IP.
@rcunrau Yes that is correct, Its on the critical path of communication between the gs and the coms handler, all Acks, commands, bulk msgs go through it. Can you clarify what you mean by the simulated UHF running on the groundstation? I thought the point of having the simulated UHF was that it was a separate entity (different zybo then the fsw code and gs code) from both the groundstation and the coms handler. If by non-optional you meant that this code would actually be run during the mission operations, then no its not essential, this code is essentially just a placeholder for the UHF. Once we get the resources to make code that handles the UHF, the simulated UHF is then irrelevent. And I can certainly add the functionality to take the hostname as a cmd line arg. |
|
RE: where does the simulated UHF run - currently we can run all the components/payload on one machine, because the communication paths are abstracted. Adding more functionality in the simulator doesn't really change where it runs. We're starting to do more testing on the Zybo, so if the UHF must be in the path it has to be on either the Zybo or the GS (host). Note that in real life the GS does talk to the Endurosat directly, to set Pipe mode/baud rate etc. so we'll eventually have to implement and test that functionality. Of course, we could have two UHF modules: one on the GS and one on the satellite; or we could have 0 UHF modules: the GS talks to COMS directly. I had never thought of running UHF on a 2nd Zybo but why not? We're just going to need to specify all the IP addresses of all these machines to hook this crazy thing up. |
Okay, I understand now. I always imagined the sim UHF would be on the zybo (with flight software) and not the groundstation, but as you mentioned it really doesnt matter we would just have to change the hostname depending where it is run. As far as sim UHF on a second zybo goes, I remeber Devin telling us the goal would be to have all simulated subsystems be run on separate devices (raspberry pi, or a zybo) thats why I thought to have it on a separate device. But obviously using 6 zybos is not super portable so I understand just using a single zybo for now. |
In this PR I added an additional TCP server to broadcast the simulated UHF's beacon as per Ron's Advice.