Just a thought on multicast file distribution systems. There is a class of algorithms called erasure codes that take some chunk of data, run a transformation on it to break it up into blocks (the total size somewhat more than original.) Then a receiver need only receive K out of N blocks that were produced by the encoding algorithm to compute the original data. This sort of thing is used at small scale with Reed-Soloman coding and at large scale for storing files. Professionally, we used a product like this which would ingest files, generate blocks that were then stored at multiple geographically dispersed locations. By tuning K and N, you would get disaster recovery and the system overall in managing all the metadata was very scalable.
The application for amateur radio beacons and the like is to just transmit blocks and the receiver can start receiving them at any time and eventually reconstruct the original object. Some research reveals some commerical work for such a thing to be deployed on unidirectional broadcast satellite links where a reverse channel to ask for "fills" wasn't available. Missing a block means you don't have to wait for that one block to be retransmitted to you much later; you might still reconstruct the object sooner.
There appear to be some open-source libraries to do this encoding and decoding computation and that would then need a UI and data transport interface wrapped around it. This sounds like a great opportunity for combine ham radio and thesis work for the right person :-)
Louis - Thanks for contributing this and I'll mention it in next week's Zero Retries Part 2 of the repeater article. I don't know that flamp uses this sophisticated an algorithm, but with cheap compute power like Raspberry Pi, and an open source library, there's no reason something could be implemented to use erasure codes. There was an older implementation of the same idea called RadioMirror (that is now out of date and I'll guess lost to history - querying DLARC got no hits), and as that was explained to me, it was a very simple "transmit numbered blocks of a file, with a checksum" and if a block was received with a bad checksum, the "fill" was to merely to wait for the next time that block was transmitted and hopefully that block will be received with a correct checksum. It seems that this technique could be vastly improved with the "bit flipping" testing that's the secret to success of DIRE WOLF being able to decode more packets than hardware TNCs, and the use of Forward Error Correction, especially IL2P.
Just a thought on multicast file distribution systems. There is a class of algorithms called erasure codes that take some chunk of data, run a transformation on it to break it up into blocks (the total size somewhat more than original.) Then a receiver need only receive K out of N blocks that were produced by the encoding algorithm to compute the original data. This sort of thing is used at small scale with Reed-Soloman coding and at large scale for storing files. Professionally, we used a product like this which would ingest files, generate blocks that were then stored at multiple geographically dispersed locations. By tuning K and N, you would get disaster recovery and the system overall in managing all the metadata was very scalable.
The application for amateur radio beacons and the like is to just transmit blocks and the receiver can start receiving them at any time and eventually reconstruct the original object. Some research reveals some commerical work for such a thing to be deployed on unidirectional broadcast satellite links where a reverse channel to ask for "fills" wasn't available. Missing a block means you don't have to wait for that one block to be retransmitted to you much later; you might still reconstruct the object sooner.
There appear to be some open-source libraries to do this encoding and decoding computation and that would then need a UI and data transport interface wrapped around it. This sounds like a great opportunity for combine ham radio and thesis work for the right person :-)
Really enjoy Zero Retries, thanks!
Louis - Thanks for contributing this and I'll mention it in next week's Zero Retries Part 2 of the repeater article. I don't know that flamp uses this sophisticated an algorithm, but with cheap compute power like Raspberry Pi, and an open source library, there's no reason something could be implemented to use erasure codes. There was an older implementation of the same idea called RadioMirror (that is now out of date and I'll guess lost to history - querying DLARC got no hits), and as that was explained to me, it was a very simple "transmit numbered blocks of a file, with a checksum" and if a block was received with a bad checksum, the "fill" was to merely to wait for the next time that block was transmitted and hopefully that block will be received with a correct checksum. It seems that this technique could be vastly improved with the "bit flipping" testing that's the secret to success of DIRE WOLF being able to decode more packets than hardware TNCs, and the use of Forward Error Correction, especially IL2P.