It would almost certainly be faster to send the file uncompressed (even accounting for NETMF’s slow network options) than it would be to compress using a library implemented in NETMF. Gus’ option is a valid one, though, you might want to look into that.
Uncompressed sending is not an option. It doesn’t matter if the process to compress takes minutes on a background thread as the files are 1.5MB uncompressed and only sent daily after midnight. With most of the locations this will be installed only offering a 2G connection, I need to get them as small as possible before sending.
These locations have poor connectivity. Enough to send small bytes of data. The SCADA upload for instance with about 30 bytes is pretty solid but the email sending often takes a lot longer than it should due to the retries.
I’ll try a test with a 1.5MB file and see how it goes.
Yip. I’ve started to port the miniz one Gus pointed to. I followed Simon’s RLP guide and I have it compiling without changes. Now I need to add the code to receive the NETMF native stuff and I’ll be able to test it. No idea yet if anything will work.
I currently work on a infield update library for my G120 and G400 to cover the full remote update process (download, validation, updating firrmware, app, files on SD, preupdate procedure (eg updating database or file by a local procedure)), and for thatI code an RLP for the compression algorithm LZJB to reduce the downloaded size. With my test, I reach an average compression of 50%-60% of the original file. To limit the size in RAM, I compressed by block of 64kb.
If you think it is a good solution for you, I can already try to compress one of your file and tell you the compressed size I reach with my implementation.