I think that looks really useful.  Especially given someone else already did a Java port.

I think we would use this at the file level, reading from an uncompressed file and creating a compressed one.  

73
Chris

On Tue, Jun 18, 2024 at 2:03 PM Corey Minyard via pacsat-dev <pacsat-dev@amsat.org> wrote:
The most popular library seems to be heatshrink, at
https://github.com/atomicobject/heatshrink.  There is a Java
implementation at https://github.com/markrileybot/heatshrink-java/

However, the C implementation hasn't been updated in 9 years.  Not sure
what to make of that.  It has a moderate number of issues.  But it still
seems to be very popular.

Tons of other libraries are available, but this seems the most used.

-corey

On Tue, Jun 18, 2024 at 11:13 AM Chris Thompson via pacsat-dev
<pacsat-dev@amsat.org> wrote:
>
> I think this is worth pursuing.  If it's a simple algorithm then we could port to java. Or have a standalone C executable that the ground station runs.
>
> This would mainly be to compress logs, experiment data or telemetry before it is downloaded.  Uploading compressed data that the spacecraft can uncompress is a separate use case if we want patch configuration or code.
>
> In a third seperate use case we can already compress large  files and upload them for later download.  The spacecraft just treats them as binary data and the ground stations do all the work.
>
> 73
> Chris
>
> On Sun, Jun 16, 2024, 18:39 Corey Minyard via pacsat-dev <pacsat-dev@amsat.org> wrote:
>>
>> I spent some time looking at implementations of compression
>> algorithms.  As Bob pointed out, memory can be an issue with these
>> libraries.  I was hoping to say that zlib (gzip) would be suitable,
>> but its minimum memory requirement appears to be 128K.  There appears
>> to be a way to reduce that, but it's still probably going to be too
>> big.  Later, better algorithms like bzip are going to be even more
>> memory intensive.
>>
>> I searched around and there are a large number of compression
>> libraries that are free and designed for microcontrollers, with memory
>> requirements in the hundreds of bytes (or even less!).  None are as
>> good as even zlib, but they are better than LZW (compress) and would
>> be adequate.  Also, more critically, they are designed to compress
>> small amounts of data efficiently.  The trouble then becomes finding
>> one with a Java implementation, if we are planning to send the
>> compressed data over the download or uplink.
>>
>> Is this something worth pursuing?
>>
>> -corey - AE5KM
>>
>> -----------------------------------------------------------
>>
>> pacsat-dev mailing list -- pacsat-dev@amsat.org
>> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
>> To unsubscribe send an email to pacsat-dev-leave@amsat.org
>> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
>
>
> -----------------------------------------------------------
>
> pacsat-dev mailing list -- pacsat-dev@amsat.org
> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
> To unsubscribe send an email to pacsat-dev-leave@amsat.org
> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

-----------------------------------------------------------

pacsat-dev mailing list -- pacsat-dev@amsat.org
View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org
Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org


--
Chris E. Thompson
chrisethompson@gmail.com
g0kla@arrl.net