How to input received bytes to gs_parse_standalone.py ?

[K4KDR]

Looking forward to receiving data from your satellites! Congrats on getting to this point.

I have tried, but can't figure out how to input received data to the gs_parse_standalone.py script.

Could you please provide the syntax of how to use that properly?

Thanks!

-Scott, K4KDR

[maholli]

Hi Scott!

Head over to https://mybinder.org/v2/gh/maholli/VR3X-decoder/main?filepath=notebook.ipynb (wait for the top portion of the page to load the interactive notbook) and follow the steps for the dummy packet I've included there.

If you're wanting to use gs_parse_standalone.py in another script, the above example illustrates what the syntax might look like. Let me know how it goes 🙂

[K4KDR]

Thank you for the reply!

Yes, the interactive binder port of your script works perfectly. That example is much appreciated!

I was trying to understand how to use it on a stand-alone computer, but not being a Python programmer it is/was a challenge.

While not ideal, I did assemble a script to import gs_parse_standalone and was finally able to pipe the raw sample to it to produce output. However, I'm sure that there is more elegant way. So, I'll keep working on it but any guidance would be appreciated.

... on a related note, I have searched & searched but cannot find the meaning of the "3<" at the beginning of the test data. Would you be kind enough to explain what that does?

Many thanks!

[maholli]

@K4KDR looks great! Elegance gets in the way most the time, anyways :)

It sounds like you're wanting to automate the parsing step, am I right? One simple way would be to write your beacon packets to a file and have your vr3x-telem.py script parse the file afterwards:

from gs_parse_standalone import parse_beacon

# read file, treat it as binary
with open('vr3x-beacons.txt','rb') as file:
    line=file.readline()
    while line:
        parse_beacon(i)
        line=file.readline()

of course this depends on how you store the binary data into that vr3x-beacons.txt file. Depending on what you're driving your (presumably?) Semtech radio with (arduino, cirucitptyhon?) it may just be easier to decode the packet on the microcontroller. Let me know what your setup and workflow looks like and I'll whip up a quick solution for you.

Regarding the b'3<' data at the front of the beacon:
The packets are compliant with radiohead's "reliable datagram" mode, meaning there's a 4-byte header indicating [To] [From] [ID] [Flags] at the start of each packet. For VR3X, I chose the following designators for the various stations:

ground_stations = 0x33 #(b'3')
VR3X_A = 0x3A #(b':')
VR3X_B = 0x3B #(b';')
VR3X_C = 0x3C #(b'<')

Therefore, b'3<' means we heard FROM VR3X_C (b'<') speaking TO a ground station (b'3'). You can see where gs_parse_standalone.py cuts off the 4 byte radioheader here

P.S. my gs_parse_standalone.py script is NOT pretty. I wanted to make sure folks had something that works. I'll find time to make it readable and more usable in the future. It should probably return JSON or something with the beacon details.

[K4KDR]

Thank you SO much for the coding tips and especially for clarifying the "3<" characters. No wonder I could not find any Python reference to their meaning... they are part of the actual raw telemetry!

I can't speak to how we will handle actual downlink data because I don't know what to expect. By chance do you have an I/Q file that you could share either from development of the project or even from a bench spare (that will duplicate the satellite's downlink)? If we had a valid I/Q file of exactly what the satellite will be transmitting, then we can test locally in-house to verify that our devices are receiving & decoding properly.

Without a test file that can be used as a surrogate, the only option is to wait until a live downlink is received from orbit. As you can imagine, it's extremely helpful to know that all of our ground hardware & software is working correctly BEFORE trying to process live downlinks.

Many thanks for any help with an I/Q file to mimic the downlink.

[maholli]

@K4KDR I don't have my linux ground station set up at the moment, so I used a windows machine to record a quick beacon for you using SDRsharp. Download from here (link will expire in 48 hours)

I'm very interested in your success with this. So please let me know how it goes and whether there's a different method you'd like me to use to grab IQ data for you.

[K4KDR]

Thank you very much for providing those test files so quickly!

Could you please confirm what byte sequence was transmitted?

I see a .WAV file with sample rate = 20M. Is the .BIN file a raw 32-bit float with the same sample rate, or something different?

Thanks!

[K4KDR]

Follow-up: I'm having difficulty decoding this recording (using the same setup that other LoRa I/Q files provide valid decodes).

Looking at the transmitted waterfall, by any chance were you using an SDR that presents a DC spike at the center of the tuned passband (such as an RTL-SDR or SDRPlay)?

I hate to be a bother, but if so, would it be possible for you to make another recording but tuned MORE THAN 40 KHz away from that center spike?

That would allow one side (i.e., "one half") of your 62.5 KHz bandwidth to be 'in the clear' and not adversely affected by the receiving SDR's center spike.

Of course I am speculating based on what I see transmitted here from your recording. I did manage one decode that I'll be very interested to see if it matches your transmitted bytes. So, thanks again when you get a chance to answer that question.

Thanks for all the help. I know from past missions that the more we can nail down with certainty BEFORE deployment, the better the Amateur Community can assist you with data reception.

[maholli]

@K4KDR I'm back and will work on generating another dataset for you. You're exactly right, I had it centered and was using software to correct the IQ. I'll work on getting one "in the clear." I'll also make sure to the encoded data for crosscheck as well.

I'm interested to hear more about your demodulation setup. Are you feeding the audio back to a semtech chip or using GNU radio?

.BIN file should have been at the same 20M sample rate unless I goofed something up. I generated it from the .WAV in case you were used to working with binary data in that form.

[K4KDR]

Thanks for taking the time for another recording! Much appreciated.

I converted the .WAV file to a 32-bit float .RAW for use in GNU Radio (see image below). The .BIN file didn't produce the same output, so I wasn't sure if it was also 20M or what.

My test transmit setup is in GNU Radio with an ADALM PLUTO. Since (as far as I know) LoRa can't simply be transmitted as FM demodulated audio the way things like FSK can. So, the only way I know of to test a LoRa transmission is either from an actual LoRa device or as I'm doing here with your I/Q file. I have known-good I/Q files from other LoRa satellites so I'm able to verify that my test setup can produce valid decodes. That's why I reluctantly asked if I might be able to get a cleaner file from you, time permitting.

Here's my I/Q file test setup:

[maholli]

@K4KDR I realized it might not have been obvious with the previous dataset. But that included the CW message in front of the beacon. So sorry for not making that more clear.

I've circled the CW portion below:

I've cut those portions off this next set of WAV files. I additionally saved the audio (96k) and offset the beacon (I think?) away from the DC spike.

See the dataset attached. I've included a text file with the transmitted data in a python bytes format.
SDRSharp_20210113__915035000Hz_IQ.zip

One other important detail I wanted to mention is that these packets are transmitted using the Semtech "low datarate optimize" setting enabled. For the RFM95PW (Semtech SX1276) modules, LowDataRateOptimize (register 0x26 bit: 3) must be set.

[K4KDR]

That's amazing - thank you so much!

Downloading now and will see what I can do. Will report either way.

[K4KDR]

Great looking I/Q file - thank you!

I'm not sure why I am not getting LoRa decodes. I can see on an SDR waterfall that the bandwidth is clearly 62.5, but could you please confirm that the SF=7, CR=8, Preamble=8, & SyncWord=0x12 are in fact what was used in this recording?

Many thanks!