Joshua Anderson

@LeStarch is there a reason we wouldn't pass `always`/`onchage` state to the tlm component on telemetry write? It adds a byte or so of internal message overhead, but would allow...

My goal would be to add a command to TlmChan and TlmPacketizer that would send out that last received telemetry from all channels, regardless of always/on_change state. Thinking about it...

That solves much of the issue - but a command for sending every packet would be nice. We would also need similar support in telemchan. I think what we really...

A bit of context on why the existing behavior is desired by some projects: FileUplink intended to be used for receiving file downlinks over unreliable links (i.e. radio). Because of...

The problem as I view it is that there's two different use cases for FileUplink: - Receiving critical files sent TO a deployment - Receiving critical data sent FROM a...

In the shorter term, I think it's probably worth adding a easy to use file checksum command to F' (maybe in FileManager?) to at least make it easy to validate...

> I don't really understand your point here, wouldn't file uplink only effect receiving critical files sent TO a deployment? FileUplink is also used for sending files between F' deployments

> Also, looking at the design, it seems that the CRC in the end packet is compared against the CRC computed from the file data. The FileUplink CRC is calculated...

> Add parameter for full-file CRC Instead of adding a full file CRC, why not add a CRC32 file command to file manager? In my view, FileUplink is responsible for...

> Send size in start packet and if file exists, truncate to that size if larger. This seems like it could get awkward when transferring files of unknown size (I.E....