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: abrind-2
ad: Left-3
ad: Left-2
ad: L-Geochron
ad: HRDLLC-2
ad: MessiPaoloni-1
ad: L-MFJ
  1. KX4Z

    KX4Z Ham Member QRZ Page

    I now have 2 or 3 test files captured off the air and I can produce additional output supposedly ready to decompress. But since I cannot even decompress Huggin's file -- which decompresses FINE for him --- it isn't that sufprising that I cannot decompress the ones I've created also. Something that I'm missing here.......

    Perhaps someone will see my error......I've already had to fix a zillion errors in the c code that I had to write, and typically it took me an HOUR on each error to figure it out, and fix it. My copy of K&R is falling apart slowly but surely, but wow!, I re-learned a ton of c-programming in the last week! I may teach some of this stuff to students in my retirement some time, so this was great for me.
  2. KX4Z

    KX4Z Ham Member QRZ Page

    I may have begun to find the solution here. We’re still traveling, so I can’t try it yet, but I found an article that Dan Planet ( Of chirp fame) about how LZHuff will fail on machines not written for a specific integer sizes:

    And he also gives a reference to a version that is machine independent.
    KX4O likes this.
  3. KX4Z

    KX4Z Ham Member QRZ Page

    I still can't get MY stuff to work, but for the first time, I have a version of lzhuf which can decompress YOUR ztemptest.bin

    I found an article by Dan Planet where he explained that a lot of versions of lzhuf were machine-integer-size dependent. And he pointed to a version that was better-written, so it was not dependent on the particular machine:

    When I finished traveling, I downloaded THAT version and compiled two versions of it --
    1. handles 4 character preambles -- lzhufuniv.c
    2 handles 8 character preambles -- lzhufuniv8.c

    Using the appropriate one of those, I am now easily able to recover your example file ztemptest.bin on a raspberry pi.

    My capture files? Not so much. BUT NOW at least I have debugged the final output, and I can now work to send a KNOWN MESSAGE through this system and also through my capture system, and using what you taught with hexdump -C.... I can compare them. That should provide some CLUES to my next error.

    Ah...the life of a novice c programmer.

    Files are attached.

    Attached Files:

    KX4O likes this.
  4. KX4Z

    KX4Z Ham Member QRZ Page

    IT NOW WORKS!!!!
    I had made a mistake in how I counted the bytes to be discarded at the start of the entire message. I was supposed to be discarding 6, I was accidentally discarding 18. I figured that out by sending a file by winlink to myself, and compressing the file with the now-working LZHUFUNIV8 , and comparing to the outputfile that I get from my readcapture program. The offset was fairly obvious once I compared. Then it took me a bit to fix, and had to also do the honey-do work of putting the lawnmower deck back on her mower.

    Attached are several files involved in this. Note that I can't really put executables here, and all files have to have .txt of the qrz won't upload them. So you may have to take off that postscript to get them to work, etc. compiler is gcc, whatever flavor I got with a sudo apt-get. All of this was done on a $35 raspberry pi 3B Not a 3B+ or four.

    I'm sure there will be further improvements, and now the whole thing could be bundled together. I am NOT an expert at capturing the files yet; all my print statements etc for debugging may be unnecessarily slowing down the entire process. There is no handling of "requested packets" yet -- this is just barebones to show that it is quite possible, and was accomplished in a matter of weeks by a semi-retired doc with a copy of K&R in front of him at all times, to read how each function worked.

    Gordon KX4Z

    Attached Files:

    DL6MAA and KX4O like this.
  5. KX4Z

    KX4Z Ham Member QRZ Page

    A bit more work got done yesterday (September 3):
    1. It seems FAR easier to capture pactor when I monitor my home station calling a more distant station. Captures were far better. Still not perfect, not sure why of course, by again my primary modem is perhaps 30 years old....
    2. I am still not yet taking advantage ofREQUEST packets. That would take a bit of coding to keep track of, but obviously it can be done and offers improvements.
    3. Found 2 bugs last night, one of which has been fixed already, the other not. These were found (generally) as a result of the system using a much lower speed level to contact the farther station, meaning the packets had FEWER CHARACTERS and it took MORE RADIO PACKETS to get across the same information --- causing information I needed to parse, to be in split across multiple radio packets.
    4. If the FC EM proposal is split across two radio packets, the very simple code that I used to advance a certain number of characters from the FC... fails spectacularly, leading to a segmentation fault. (I simply edited the ascii file to temporarily get around this, putting the entire proposal on one line. Files are appended with "EDIT" or similarly.) That will need to be fixed!
    5. Turns out that PMON HEX 1 does not place an ending COMMA after the sequence of comma-delimited dual-hexadecimals! My code dumbly expected one and therefore got OFF by one position at the end of a RADIO packet. This has been fixed by the simple expedient of inserting a comma in an array it was building with a couple additional lines of code. After this was done, readcapture0903a.c worked flawlessely on two captured files, returning good emails.
    6. I sent the Gettysburg Address and the system did well up until about the end of the first paragraph --- at which point to my eyes, I have a string of about 3 radio packets that have NOTHING in their PAYLOAD2. I don't understand the meaning of that quite yet. Did they fail the CRC test? Were they actually sent that way? This will require investigation but I presume it is a problem in the radio capture until proved otherwise. I'm still not taking advantage of the REQUEST (repeated) packets --- the farther station was asking for a TON of them, and all that fertile information was literally being ignored by my novice code running last night. But again this points out the myth of the claim that missing one bit fouls up the whole thing: the Gettysburg Address, and all the header information came across perfectly UP UNTIL THE POINT OF LOSS.

    Later today I will file a simple "express comment" on the FCC site to note these continuing software creation sagas. The directory with the code and texts of Sept 3 is notated below. Folks, a competent programmer could sure do this more quickly!!!

    Files from the work of 09/03/2019 (MMDDYYYY) are archived here:
    KX4O likes this.
  6. KX4Z

    KX4Z Ham Member QRZ Page

    Through the generosity of SCS, a loaner modem is being shipped to me so i can compare modems and try and remove that variable from the picture. None of us quite know why certain packets weren't caught last night -- but copying my home transmitting to a distant gateway was FAR easier than what I had been doing with all three stations here in my house!!!! Huge improvement. There will be more, particularly with some other people begin to WORK on improving this. Much fertile research awaits.

    And while I was at it, I sprung for a new cable to icoms so I can switch out my icom-725 for a better icom-718 in my portable station.
    it was the least I could do.
    K2NCC likes this.
  7. KX4O

    KX4O Ham Member QRZ Page

    I've pushed through another round of scripting and now have a way to turn PMON output from the SCS DR-7400 to decompressed Winlink or DTN (NTSd) message(s) if I get enough frames during monitoring.

    I'll run this experiment through January after which the equipment will return to its original VAPN purpose.
    K2NCC likes this.

Share This Page