936
edits
User:Callahanp: Difference between revisions
Jump to navigation
Jump to search
Hackathon 2023 Proposal Draft
(Better Description of ongoing work) |
(Hackathon 2023 Proposal Draft) |
||
| Line 8: | Line 8: | ||
* Simulator Cockpit C++ Coding | * Simulator Cockpit C++ Coding | ||
* Flightgear Documentation | * Flightgear Documentation | ||
* 2023 Hackathon Proposal Refactor subscribing to property values via the WebSocket interface. The problems in this area of the flightgear codebase are: - Subscriptions to a property with an index such as Comm and Comm[1] frequencies will return changed values for Comm, but none are returned for Comm[1] - The web socket interface operating at the default speed with a .05 second transmission window can only send about 120 unique property values per second. A defect in the current code resets all subscribed properties to unchanged after the first six or seven properties are sent This means that many changes are entirely missing while others are significantly delayed. - Property values for many cockpit instruments are recalculated at twice the frame rate. Most of these calculations cause infinitesimal changes with values flipping back and forth in a range that is invisible on the instruments. Repeatedly transmitting these small changes for even a few properties, floods the websocket with noise, blocking or delaying the transmission of changes that are actually significant. A minimum change threshold is needed for such properties. I've done some investigating, but need to write it up better. The websocket interface is used for property subscriptions requested from clients, and is also used by PHI. I need to understand how PHI is using the HTTP service and WebSockets | |||
'''<big>Metal Shop</big>''' | '''<big>Metal Shop</big>''' | ||