Uplink troubleshooting

[CoreySco]

Hello,

I'm working on the ground station for the upcoming KUbeSat mission at the University of Kansas.

we have been working on the ground station for a bit and have been able to get downlink to function correctly, but have had issues with working on the uplink and were wondering if anyone here had any ideas.

Specifics of the Radio Module
-UHF
-2GFSK
-Basic AX.25 with a little extra encapsulation (Preample,Sync word, Postamble)
-9600 bps
-CRC16 on the end (CCITT false)

We have a working downlink using mostly gr-satellites blocks seen below. The check AX.25 address block does exactly what it says and checks that the call-sign matches what is expected, PMT to ascii, does 2 things, converts the input to ASCII, and fixes a bit shift in the callsigns.

for transmitting I believe our main issue is handling the packet formatting. should we try to handle the formatting inside gnuradio or use external scripting to convert whatever command we want to send into a proper packet? we have been looking at some example diagrams for transmitting such as this:

but have not had any luck finding or making an ax.25 header_format object.

Thanks!
~Corey

[K4KDR]

Greetings! No doubt Dani will have excellent advice for you. But in the meantime, the first question that comes to mind is, "What should a valid uplink packet look like"?

Does your satellite expect a standard AX.25 packet or something else? If so, are particular AX.25 To/From callsigns required? I realize you don't want to post any of the details that secure your uplink channel, but I think you understand my question... we would have to know what format is required to be able to provide guidance on how to achieve that.

Thanks & best of luck with your project!

-Scott, K4KDR

[CoreySco]

it is not exactly standard ax.25, but there is a full ax.25 frame inside of our packet.
it looks something like this:
[Preamble] 5
[Sync word] 1
[Payload Length] 1
[Payload] 0-128
[CRC16] 2

inside the payload
is an ax.25 frame and another constant value preamble/postamble

[K4KDR]

Thanks! Creation of the AX.25 packet and then the addition of the other final packet components should certainly be do-able.

One common question that you might want to provide here is exactly which parts are used to calculate the CRC. I'm sure that I'm wrong but it seems like every mission calculates the CRC from some different combination of the transmitted packet's contents.

[CoreySco]

Payload length, and Payload are used to calculate the outside CRC, the CRC in the ax.25 frame is calculated normally.

[daniestevez]

Hi,

Scott's question about how should a valid packet look like is the most important. Without this, the uplink won't work, usually with no indication from the satellite radio of what went wrong. So I'm going to follow up with some more detailed questions about the packet format, with the hope of trying to tackle potential pitfalls. From what I see, this looks like an AX.25 frame embedded inside a frame supported by the built-in packet engine of a CC110x, Si4032, or similar chip. Often, mixing AX.25 and something else can be tricky.

• Is the AX.25 frame included in the payload just a "link layer" frame or does it also include all the "physical layer" features from HDLC (NRZI encoding, scrambling, bit stuffing, LSB byte ordering, CRC16-CCITT, flags, etc.)? Equivalently, would a regular AX.25 receiver be able to receive the AX.25 frame inside the packet?
• Does the AX.25 frame need to contain some particular header data (callsigns, ports, PID, etc.)?
• Is the byte ordering for the syncword MSB or LSB? How about the byte ordering for the rest of the packet? Some of these chips have weird choices regarding the endianness.
• What is the endianness of the CRC16 CCITT? There are also several possible choices here.
• Is the preamble supposed to be 0x55 or 0xAA? Does the choice matter?
• Do the radio packets use any kind of scrambling?

These are all the things that come to mind now, but maybe there are other details that can prevent the satellite radio from decoding a packet.

Regarding how to implement it, I would suggest the following steps:

1. Assemble a known good packet by hand, use a Vector Source to produce the bits corresponding to that packet in GNU Radio, and modulate the packet to RF. This will validate that the understanding of the packet scheme is correct.
2. Decide whether in the final solution you want to implement the packet formatting in GNU Radio (this is easy to do with a custom Python or C++ block) or outside of GNU Radio. The best choice will probably depend on how the rest of your groundstation software looks like. Here you should also consider how the flowgraph will communicate with external software.
3. Implement the final solution with packets (either fully formatted or only payloads) coming in from external software and being modulated to RF. Perhaps you'll have to deal with issues such as what to do when no packet needs to be sent (do you send zeros to the SDR, starve it of samples, or use burst transmission?), and how to avoid large latencies. These will possibly depend on the SDR hardware you're using.

[CoreySco]

sorry for the long delay, I'll try to answer the questions in order

• yes a regular AX.25 receiver is able to decode it no issue, there is minimal extra information added on by the Endurosat packet structure. An example of the packet structure can be found at https://smallsatgasteam.github.io/GASPACS-Comms-Info/ under the packet structure heading.
• yes we do use specific SSID,Control,PID and have preferred callsigns to use.
• Preamble is LSBit, Syncword is LSBit, rest of packet (data field 1,2 & are MSBit) the CRC16 not in the AX.25 frame is MSbit,MSbyte
• preamble is 0xAAAAAAAAAA (5 bytes)
• the ax.25 frame that composes data field 2 is scrambled using the standard G3RUH, encapsulation around the Ax.25 frame is not scrambled.

An additional question I have is about the transmission, I have created a python block that in combination with HDLC framer, NRZI encode, and the scrambler assembles the full Data field 2.
when setup like this it correctly decodes

to

(the callsigns are incorrect because I have not yet added the standard bitshift)

but when expanding to a the fuller diagram it is unable to decode

is there any help you can provide on why this system is not working?

Thanks,
Corey

[daniestevez]

Hi Corey,

Thanks for the additional details. I've now understood that for this uplink you need to generate a message according to the "Packet structure" and "AX.25 Packet structure" diagrams from the GASPACS documentation (namely an AX.25-compatible frame encapsulated inside an Endurosat frame).

Just a minor detail, to check that we're on the same page. AX.25 uses HDLC, which sends bytes in least-significant-bit first order. This is not explicitly depicted in the "AX.25 Packet structure" diagram from GASPACS, but if you skip this a regular AX.25 radio won't be able to decode the frames. Then it's true that the bytes of data field 2 are sent in MSB order by the Endurosat framing.

Regarding the last diagram you show, are you sure that the GMSK Demod block is working correctly? I would suggest not using GMSK Demod, since it uses the old Clock Recovery MM block which is not very good and is deprecated. Instead, I suggest to use the gr-satellites FSK Demodulator block (you can use the --deviation "command line parameter" of the block to set the deviation to that of MSK). This also gives a soft symbol output, so it is easier to check if the demodulator is working correctly, unlike the GMSK Demod, where you would need to check if your input bits are present in the output, because it only gives a hard symbol output.

[K4KDR]

Good day. I may have some info that will be helpful.

Since your original question was posted, I was approached by another Project Team requesting help with uplink commands to their satellite (already in orbit). Looking at my solution - and looking back at your first post here, is looks like they may be using the same radio.

The solution that allowed us to generate properly formatted 9600-baud Endurosat format packets to transmit (I needed wideband audio but .RAW I/Q files are produced as well) is accomplished by the team providing the EXACT and COMPLETE payload to transmit via a binary/hex file such as:

... please note that the checksum in this example will not be correct since I put FF characters over that team's payload.

With the desired bytes to transmit in-hand, I then used the following flowgraph to generate the wideband audio .WAV file that, when transmitted over-the-air, decodes perfectly:

... of course I realize that an image of a GNU Radio flowgraph does not provide all of the underlying info. So, please let me know if I can fill in any of the details or even share my very amateurish (but working!) flowgraph.

-Scott

[daniestevez]

Hi Scott, thanks for sharing this.

For KUbeSat I think that the frames will look somewhat different to the one you showed. According to the GASPACS diagrams that Corey linked, the 0x7e flags are scrambled and NRZI-encoded. In the example you've shared, they are sent literally as 0x7e's.

Or, you may be right and the data for KUbeSat needs to be formatted in the same way as in your example. What I think it's important to understand here is that the diagrams from the GASPACS documentation refer only to how the downlink is formatted. For the downlink, they took the care to format the AX.25 frame in field 2 including all the physical layer elements of AX.25, so that a regular AX.25 receiver can process these frames by ignoring all the encapsulation and seeing only the 100% compliant AX.25 frame in field 2. But the question is how does the uplink work. For the uplink they could have simplified and embedded the AX.25 frame without the physical layer elements (NRZI, scrambling, bit stuffing, etc.), which is what your example shows.

[CoreySco]

Hello, Scott
would you mind sharing the flowgraph, I have been able to create packets to endurosat format (so I think at least). I have attempted to recreate the flowsheet you provided like so:

and I tested it with a little ax.25 packet saying "Hello, world" and sucessfully got my expected output:


however, the signals looked a little weird to me, it could be they are fine and I'll find out when I test in the lab tomorrow, but was just wanting to see yours so I can try and debug mine if it is incorrect. for reference I intend to place my SDR sink right after the second low pass filter.

Thanks,
Corey

[K4KDR]

Hello! I think you have all the same blocks & settings there. Here is the GRC file I used, which should be nearly identical:

DAT_to_TX_ENDUROSAT_k4kdr.zip

[K4KDR]

I don't know if it's helpful, but here is the decode of my uplink command packet that was created using the raw hex bytes provided by the Project Team:

... I'm going to guess that if they had wanted an AX.25 formatted packet, the appropriate bytes could have been provided in the hex that was used to create the packet to be transmitted. (wasn't the case here - they just wanted specific bytes in the payload)

I've also noticed that both GNU Radio (gr-satellites) -and- the UZ7HO 'Gaspacs' Soundmodem show these decodes starting with the first byte after the preamble ('30', in this example). So, even though I'm transmitting the string of 5 'AA' bytes + the '7E' byte, they don't display in either of the decoders that I'm familiar with for this format.

[daniestevez]

This makes sense, because the preamble and syncword (see the GASPACS diagrams) are dropped by the decoder. We're keeping the "data field 1", which is a length field, for some reason I don't recall (with other framings we drop length fields). The CRC-16 at the end is also dropped.

[hcshires]

Hello,

I'm working on the ground station for the upcoming KUbeSat mission at the University of Kansas.

we have been working on the ground station for a bit and have been able to get downlink to function correctly, but have had issues with working on the uplink and were wondering if anyone here had any ideas.

Specifics of the Radio Module
-UHF
-2GFSK
-Basic AX.25 with a little extra encapsulation (Preample,Sync word, Postamble)
-9600 bps
-CRC16 on the end (CCITT false)

We have a working downlink using mostly gr-satellites blocks seen below. The check AX.25 address block does exactly what it says and checks that the call-sign matches what is expected, PMT to ascii, does 2 things, converts the input to ASCII, and fixes a bit shift in the callsigns.

for transmitting I believe our main issue is handling the packet formatting. should we try to handle the formatting inside gnuradio or use external scripting to convert whatever command we want to send into a proper packet? we have been looking at some example diagrams for transmitting such as this:

but have not had any luck finding or making an ax.25 header_format object.

Thanks!
~Corey

Have you been able to find a solution to this? I'm with Iowa States team using an Endurosat UHF as well

[daniestevez]

I don't know if @CoreySco got this working eventually. All the information that is public is the one you see above, but certainly it would be good to know what Corey's project ended up.

[CoreySco]

Hi, I have graduated and am no longer involved in this project. However, we did get this working using a modified version of endurosat’s flowchart. I encourage you to reach out to kubesat@ku.edu and someone might be able to help you.

[hcshires]

Got it no worries! Thanks for replying anyway, we'll reach out to them.