RFM98PW in space, any mods needed?

[sukjinkang]

Hello,

Wanted to ask if RFM98PW on PyCubed was used in space, as is, without any mods. What radio did V-R3x use? RFM98PW at max power of 100mW seems low (though I understand LoRa helps increase the link margin), and wanted to ask if any modifications will be necessary for RFM98PW to close the link securely in LEO, say 400 to 500 km altitude.

Thanks!

[maholli]

Hi @sukjinkang

Yes we've successfully used the RFM98PW as-is in LEO with decent link margins at 915MHz. 433MHz is even easier to close. Note that the max output power of the RFM98PW is 1W (not 100mW).

There were two transmitters on V-R3x:

• UHF: RFM98PW
• S-Band: SX1280 module.

[maholli]

yep pretty much.

This line in the rfm9x library describes what's configured on the radio. Make sure to call the tx_power function as well to make sure things get set.

Something like this:

cubesat.enable_rf.value = True # PyCubed's RF regulator
cubesat.radio1.idle() # just in case
cubesat.radio1.max_output = True
cubesat.radio1.tx_power = 23

There's a line above that turns on PyCubed's RF regulator, which should be on when using the radio in high power mode. The flight (U21) RF regulator is enabled as expected (True is on, False is off). The proto RF regulator is the opposite (cubesat.enable_rf.value = True is off, False is on). This is a result of the global chip shortage, as the flight parts became harder and harder to find.

EDIT: updated enable_rf syntax to reflect properly setting the pin state. Should be enable_rf.value=

[sukjinkang]

I'm trying to decode the downlink using GNUradio, and am having trouble with the sync word. Looks like it's not set on the PyCubed side. Is there a default, or is there a way to set it myself?

[maholli]

@sukjinkang the default LoRa sync word is 0x12. If memory serves, Semtech doesn't address setting the LoRa sync word in their datasheet and they advise against end-user changing it, but the appropriate registers are known. Let me know if this is of interest to you and I'll dig up my notes.

There's various approaches towards demodulating LoRa in GNUradio. I've had good success with this gr-lora_sdr implementation as well as the original rpp0/gr-lora repo. HOWEVER, in my experience, demoding SF11 and SF12 packets never worked as well as I would like.

Some LoRa parameters to be aware of for GNUradio:

• Set cubesat.radio1.low_datarate_optimize = False unless you explicitly have an option for this in your demod. The default setting for low data rate optimization is False for PyCubed's RFM9x library.
• PyCubed's default LoRa settings are listed here: Frequency: 433 MHz, SF7, BW125kHz, CR4/8, Preamble=8, CRC=True

Let me know how it goes!

[sukjinkang]

Yeah, I'm trying to decode with gr-lora_sdr. Nothing was coming through, so I thought it may be the sync word. Mine's HopeRF, not Semtech, but I believe they are pretty much the same. I'm using the standard setting of SF7, etc. so I'll keep trying things and report back. Thank you for your help!

[maholli]

Same chip architecture and behavior between the HopeRF RFM9x and Semtech SX1272.

One other tip I remember from my GNUradio experiments is to

• offset the center frequency of the SDR from 433 MHz (default PyCubed freq) by at least the bandwidth of the chirp (default 125 kHz), but still have GNUradio set for the target frequency. On the bench, my HackRF had too much interference from the DC bias at center freq and this was the quick fix.
• Make sure the sample rate on the SDR plays nice with the sample rate of gr-lora_sdr.