Radio Data rates

[Mainestar]

Can anyone comment on what the usable downlink data rates are for the RFM series LoRa radios from low earth orbit?
Has anyone successfully interfaced a camera with the LoRa radio ?

Tnx!

[maholli]

Here's one way to think about it (there are plenty of other approaches).

LoRa Settings

• You can yell as loud as you want from the ground station, but you want to make sure you can hear the sat
• My most recent mission was V-R3X and I used the following settings very successfully for command/control at 915MHz (433 is even easier to close):
  • DOWNLINK SF7, BW62500, CR8, CRC=True, Low data rate optimized=True; data rate ~1800 bps
  • UPLINK SF9, BW250000, CR8, CRC=True, Low data rate optimized=True; data rate ~2200 bps
  • both achieve a link budget of 137dB

The above worked great and I always had 20+ dBm of margin so I could have pushed the data rate higher if I needed to. V-R3x also had an s-band LoRa radio (SX1280) that could really move some bits.

Ultimately, I'm of the opinion that the sat should start with (and default to) a setting that confidently closes the link. That's the most important part. Once you close the link, you can always configure the data rate higher (see beep-sat advanced example for demo of other-the-air commanding).

Sending camera data

⭐ After my description below, it became clear to me I should generalize my existing code for doing this and make it available. See the example code at the end of this post.

• I would keep the data in binary and save it to the SD card as such (beep-sat example illustrates this with the IMU task). When it's time to downlink an image, I would determine the size of the desired file with os.stat(FILENAME)[6] (which is in bytes) and pick a nice buffer size of 240ish bytes (no bigger than 252 for radio FIFO) and determine the total number of packets it'll take. Labeling the packet number ("2 of 200" etc...) is important in piecing together the file and knowing if you're missing any chunks.
• Next step is to read bytes out of file and fill the radio FIFO. To do this efficiently, I would use the cubesat.send_buff object, which is a python memoryview object that lets you access an existing bufferarray more efficiently than the usual slicing of python lists. First two bytes would be chunk number and total chunks (like "2 of 200" etc...). Finally I would use the send_fast() function I built into the pycubed_rfm9x library to expedite filling the FIFO without the typical overhead from the radiohead stuff.
• Some other things to think about that I don't have time to write up tonight:
  • Image compression, which would be helpful in reducing file size.
  • LoRa has packet-level forward-error-correction, but there are many packet redundancy schemes that intelligently interleave and optimize the recovery of dropped packets. This is a whole other rabbit hole to go down (some other time)

Below is some untested (but heavily commented) code that achieves what I've described above. Once I return from travel I'll be able to test it on hardware and confirm it works.

💻 untested example code (EXPAND ME)

def send_file(self,chunk_size,filename,start=0,stop=None,p=False):
    '''
    Send the specified filename starting at byte number `start` and ending at `stop`

    Typically `start` and `stop` arguments wont be specified, but it gives us the option
    of selecting regions of a file just in case some packets are missed during downlink 
    '''
    if p: print('send_file()',filename)
    try:
        filesize=os.stat(filename)[6]-start
    except Exception as e:
        if p: print('[send file] {} error: {}'.format(filename,e))
        return []
    if stop is not None:
        filesize=stop-start
    # packet length
    buff_end=chunk_size+2 # add two bytes for [chunk#][total chunks][...]
    # second byte of the buffer is the total number of chunks that make up the file
    cubesat.send_buff[1]=int((filesize)/chunk_size)
    # open the file as binary
    with open(filename,"rb") as f: 
        for i in range(cubesat.send_buff[1]):
            f.seek(start+(i*chunk_size))
            # set first byte of the buffer to be the current chunk number
            cubesat.send_buff[0]=i+1
            # read the bytes FROM the file INTO our buffer via the memoryview object
            # this pre-populates the buffer, so all we return with this function is 
            # the chunk#, total chunk count, and length of the packet
            f.readinto(cubesat.send_buff[2:buff_end])
            # we want to yield here (rather than return) so this function behaves as a generator
            yield (cubesat.send_buff[0],cubesat.send_buff[1],buff_end)

'''
The above send_file() function is a generator, allowing us loop through its output
and efficiently manage the SD card and radio access over the SPI bus
'''
for chunk in send_file(chunk_size=240,filename='/sd/data/IMG00012.bin'):
    '''
    note: NO RADIOHEAD HEADER!

    The send_fast() function from our rfm9x radio library takes two arguments:
        data: byte, bytearray, or memoryview object. In our case, it's a slice of our memoryview object
        l:    The precomputed length of `data` argument (this saves us from calculating it each time)
    
    This will fill the radio FIFO with our latest "chunk" or packet data and send it. 
    '''
    cubesat.radio1.send_fast(cubesat.send_buff[:chunk[2]],chunk[2])

P.S. I'm also developing a "Beep-Sat Advanced-2" example which demos: deep sleep + intermittent computing, rapid over-the-air commanding, and compartmentalized configuration loading. It's fully functional but I'm not satisfied with my handling of cubesat.cfg and other minor details, so be warned it'll likely change in the future. Here's the branch if you're interested.