jlucas9
commented
6 months ago After running the provided script it seemed that multiple commands were being fed directing into cFS with no delays. I added set_line_delay(1) to the start of the script to slow things down. Additionally I reduced the TO wakeup to 50ms so that no data was lost in the output pipeline, was seeing overflow errors. This was accomplished by adding #define TO_WAKEUP_TIMEOUT 50 to ./fsw/apps/to/examples/udp/to_platform_cfg.h
While the existing CFDP tests that immediately uplink then downlink a file on their own, and the sub parts of those work when run on their own, even with another upload in between, for some reason in scripts of mixed spacecraft behavior, these scripts will break when run. Through several tests, I've found that while uplinks still seem to function, downlinks get corrupted and send what seems to be random data (based on md5sums that are different each time, even under the same conditions) after other things have been run. I have provided my scripts to the team internally. Having commented out the process to take a picture, it didn't seem to be that. The main commands running between the uplink and downlink are telemetry and data request commands and no-ops. I verified this bug works on the dev branch, whether I uplink, run the loop, then attempt a downlink later on, or if I uplink my RTS table, then try the standard combined uplink/downlink script after running the main loop, the downlink breaks in either case, while in isolation, the combined script, the two scripts in succession, or the uplink and downlink with the RTS uplink in between all work as expected. My best guess is something corrupting the data on the SB or the TO Pipe (since the CFDP Downlink is sent from the CFS Radio command set, and from the TO app, rather than from the CFDP apps, but I am not entirely sure.