Decode off-the-air Winlink message - request for programming help

Discussion in 'Working Different Modes' started by KX4O, Aug 6, 2019.

ad: L-HROutlet
ad: l-rl
ad: l-BCInc
ad: Left-3
ad: abrind-2
ad: L-MFJ
ad: Left-2
ad: L-Geochron
  1. KX4Z

    KX4Z Ham Member QRZ Page

    KX4O likes this.
  2. KX4O

    KX4O Ham Member QRZ Page

    Did you try this compile command?

    gcc -DMAIN -DENCODE -DDECODE -DVERBOSE lzhuf.c -o lzhuf​
  3. KA9JLM

    KA9JLM Ham Member QRZ Page

    What kind of data buffer are you using ?

    Is it FIFO ?

    Seems that it would be easier to make DLL calls to the Winlink DLL.
  4. KX4Z

    KX4Z Ham Member QRZ Page

    No I did not, but when I get the chance next I’ll do that probably tonight or tomorrow morning
  5. KX4Z

    KX4Z Ham Member QRZ Page

    Laugh ! Well it probably would —if I actually knew what the heck I was doing!

    Of course you could tie this all together in one application ( once it works ) ; but to make it much easier on me in the development work, I split it into three.

    1. Capture routine grabs signals off here & stores packets in a file, So development can try different routines and keep trying until something works

    2. Readcapture grabs those and reformats into the correct (or what I hope is the correct format) for Lzhuf. The time sequence remains unchanged, “ first captured” is first delivered to LZHUF

    3. Lzhuf takes the file produced by program number two and theoretically produces the uncompressed output ....

    Doing it in that fashion allows me to uncouple the timing and fix portions independently

    Part one took over a week to get working, Part two took well over a week and I’m not sure it works perfectly, and I thought part III already work but that took several hours today
  6. KX4Z

    KX4Z Ham Member QRZ Page

    But it dawns on me that there is a *chance* that I have the original text of one of the emails with me, and if so I can try to compress and compare and see if I can find my error
  7. KX4Z

    KX4Z Ham Member QRZ Page

    Progress -- using those commands I'm able to get lzhuf.c to compile. However, it still will not decode ztemptest.bin I'm attaching the output that I got.

    Attached Files:

  8. KX4O

    KX4O Ham Member QRZ Page

    Looks like it got compressed again perhaps? Please post the exact command string used to decompress the file.
  9. KX4Z

    KX4Z Ham Member QRZ Page

    Ah, good to hear from you! I spent *hours* on this again last night, trying every possible permutation I could think of, and still couldn't make even your own decomression work, so clearly there is some issue, either of a mistake I am making, or of some bit/byte/char/int difference that the raspberry pi is making. For starters, let me answer your question and simply work with ztemptest.bin, since on your side that DOES work, and on my side it does not.

    I have used as many as four different versions of lzhuf that are out there (I even found an executable that runs on a PC and I believe I tried that around midnight) --
    lzhuf compiled from YOUR code (using the compiler directives that you listed)
    lzhuf_1 from the 199 work of Jean-Paul
    lzhufse from the .se web site where I found a very simple version with no #ifdef or #endif inclusions in the cose

    Cannot get it to work with ANY of these.

    All of these work very similarly, -- put a "d" in the command and they decode; put an "e" in the command and they encode. I think the se version asks for d[1] or e[1] but can't remember perfectly

    for for example,

    /home/pi/monitor/lzhuf/lzhuf d /home/pi/monitor/lzhuf/ztemptest.bin /home/pi/reconstruct.txt

    command [files are attached as .txt ending versions] gives this output

    If you can explain this, THAT WOULD BE WONDERFUL!!!

    Attached Files:

  10. KX4Z

    KX4Z Ham Member QRZ Page

    Now that I have the code written, I'm able to modify it very easily. I have tried several different items. You are much better at working with and visualizing binary / hexadecimal files than I am.

    In studying your published success, I detected that you discarded the first six hexadecimal characters (or 3 8-bit char binaries) from the received file, which you did NOT send to the lzhuf routine. Specifically, in addition to tossing 02 fa from the opening packet, you additionally tossed the e2 64 00 00 and ended up with the unencoded file size, and enough 0 characters to pad to 8 binaries (8 2-char hexadicmals) before the opening characters of the data of ed f5 7a 1c 6d....

    Specifically, your file to send to lzhuf looked like THIS:

    87 03 00 00 00 00 00 00 ec f5 7a 1c.....

    So it is easy for me (now) to do the same thing in C-code and I have duplicated that many times and it still does not seem to decode.

    So I studied how the lzhuf routines COMPRESS and they have fewer 00's -- I don't know if they are putting out a 4 byte CRC code or what, but they tend crate compressed files that look like
    87 03 00 00 12 34 56 78 9A AB .....
    so I've done THAT also in my code --- still can't be decompressed properly.

    and I've tried the above tricks with all three routines (yours, the .se fellow's, and Jean-Pauls) -- and I think I managed to try it on a PC using an executable I found somewhere -- still no luck.

    I'm going to include here some .txt versions [just with .txt added to them so they will upload to QRZ] of some of the files I've captured and formatted supposedly ready to decompress

    MY PROGRAM requires its input file to be precisely:
    and produces exactly this output file:

    both of which are attached, with .txt added to them to be uploadable to QRZ
    the compile command on a raspberry is
    gcc readcapture824c.d -o readcapture

    If someone can spot the error I'm making......that would be fabulous!!!

    Attached Files:

Share This Page

ad: cq2k-1