Bit at Index 64 is set to 0

[shihaocao]

[shihaocao]

git checkout gpstime-test

ws a time.gps, notice that after telem dump + parsetelem that all odd numbered wn don't parse correctly

[shihaocao]

[shihaocao]

[shihaocao]

python -m ptest runsim -c ptest/configs/hootl.json -t SingleSatDetumbleCase --clean

[shihaocao]

Moving time.gps to the front of the flow fixes it?

[shihaocao]

nevermind, there's some code that's setting the 2nd bit from the front of the flow to 0. when time.gps is at the front of a flow, 2045->2045, 2046->2044, 2047->2045, 2048->2048

[shihaocao]

Planned course of action is to move attitude_estimator.ignore_sun_vectors to the 3rd bit in front of GPS time. that means that field will always be false, but at least the other fields will be intact we thnk.

We have no idea if any of the other flows below flow 2 are affected.

[shihaocao]

with the 2nd flow and 3rd flow swapped positions, we note that velocity also happens to be negative when it should be positive...

This output was generated with the new FlowInpsect ptest case

[shihaocao]

As far as we can tell, this cursed bit effect also goes away when we changed the boot count serializer with #828

[shihaocao]

Actually, it moves it into the 26th bit of the second flow. Which is the in the time of week....

[afoarce]

In printing snapshots over time, it appears that the 'cursed' bit flips when the packet splits based on testing on branch cursed-testing

[afoarce]

I believe it is this

FlightSoftware/src/fsw/FCCode/DownlinkProducer.cpp

Line 100 in 5ed3ece

packet_start = bit_array::modify_bit(packet_start, 7, 0);

that clears the bit due to a miscalculation on

FlightSoftware/src/fsw/FCCode/DownlinkProducer.cpp

Line 99 in 5ed3ece

char& packet_start = snapshot_ptr[(downlink_frame_offset / 70)];

. When splitting packets, the downlink_frame_offset/70 gives 8 (bytes) and so the 64th bit is cleared instead of the first bit after 70 bytes. The packet header is still added successfully because snapshot is initialized to all 0s and the offset is incremented, so the 561st bit remains 0. Testing with the modify_bit line commented out shows no cleared bit.

Unfortunately, this means the combination of changing the serializer size for bootcount and adding the cursed bit in #838 moved the issue but did not mitigate it. Further testing needed to quantify the effects on the accuracy of time.gps.

@shihaocao @tanishqaggarwal @kylekrol

[shihaocao]

wow that's crazy

[shihaocao]

The bit that is being set is now in pan.cycle_no, therefore we are fine.

[shihaocao]

[shihaocao]

In the second half of the packet, the rwa_torque_cmd bit will be set to zero as it takes up 53 - 65

[knk38]

Resolution is to turn off cursed flows, and only toggle on these flows:

• 14, 15
• 17, 18, 19
• 25, 26

[shihaocao]

Or we change the downlink parser code to go as follows:
if a packet claims it is the first packet in a new frame, parse it immediately, check its flow_id values in the expected positions if they don't comprise the flow_id values we expect in the first packet of a new frame, conclude that it must be a packet a part of the previous frame.