Writing Telemetry Packet in JSON File

[lgnashold]

Outline

We need to actually specify what data we want to send in our telemetry packets (basically, packets we send from the satellite to the earth containing data about the satellite). We already have a rough idea of what data we want to send in this file. . We also have a packet class capable of serializing and deserializing packets based on a given format, specified in JSON.

Rough Steps

This will probably change as you go through it.

1. Copy the fields in the spreadsheet into telemetry.json, to define the structure of the telemetry packets we send. For each field, you will need to specify a name and a type (i.e. int, float, etc). For example, if you are defining something like temperature, you might write something like this:

   [
   ...
   {
   "name": "temp", 
   "type": "float"
   }
   ...
   ]

2. Write code to instantiate an instance of a TelemetryPacket using your field names. The values can be whatever, but preferably something unique so that we can tell if it's working (i.e. not all zeros).

3. Send the packet using the radio.py file.

Other Notes:

• You can see a full list of types in the struct library. Note that circuitpython only supports some of these.
• You can see exactly what names we are using for each type in the dictionary type_name_to_format_str in the Packet class.
• Some rows in the spreadsheet might correspond to multiple fields in the JSON. For example, attitude might be broken down into four components.
• Feel free to ignore some of the more vague or not as fleshed out rows in the spreadsheet initially, since this is more of a proof of concept than anything else.

After this, the next step will be defining other types of packets, like commands and responses to commands. We also might want to implement something similar with UART.

People to contact

Flynn: For information about the spreadsheet and the various fields Langston: Anything else, esp. information about the current code and the different python libraries, or the goal of the task as a whole. Tim Vrakas: If you have a question about the spreadsheet Flynn can't answer

[polygnomial]

@Timvrakas lol

[Timvrakas]

I can try to dig up how Olympus has done radio packet stuffing in the past.

• For boolean data types, you should just include a single bit.
• For state machines/enums, you should encode it as an minimum-length integer. Don't pad it out to 8 bit increments.
• For time, I would measure seconds in a 16-bit counter, which would roll over every 45 days.
• For Measurements like temperature, I would use a scaled integer (8 bits should suffice, with 256 bins from -100 to +155). Make sure you constrain before mapping, you want to saturate, not overlow.
• I would have GNC list out important variables, and for each one determine the best resolution and the greatest values possible. Many variables (like quaternions) would be best represented as scaled integers (eg: 0-1024 -> -1 to 1). Your sensors are of limited precision, so having 32 bits of orientation data is not useful.
• For some variables (fault counters for example) you can get smart and have N bits of counter, and then have the last bit be "latching" so that once you overflow the first N, the overflow bit will stay on forever (or until manually reset).

Keep in mind that your fallback UHF Bitrate is 18 bits per second, and your contact window is not very long in LEO. You should have a critical telemetry packet of around 100 bits of the most important data to recover from failures.

[Timvrakas]

This is old and in C, but here's what I used to do for this: https://github.com/stanford-ssi/rockets-irec-sradio/blob/master/src/irec-rf.h

I think the JSON-based packet description format is a good idea, and I've been wanting to do something similar for a while

[Timvrakas]

critical telemetry might look like:

• reset counter (4 bits +1 latching overflow)
• master state machine state (3 bits?)
• battery SOC (5 bits?)
• 8 hour average power flow (4 bits)
• GNC state (3 bits?)
• Orbit solved? (bool)
• Attitude solved? (bool)
• De-tumble state (attitude stable) (1-2 bits?)
• various hardware health (4x bools)
• orbital position (5-6x 8 bits? might need more...)

The big driver seems to be orbital position, which I don't know enough about. If we want to know where it is in the sky within 10 degrees, and when it will appear within 10 seconds, what level of precision do we need on our TLE terms? This is a problem someone can solve with a notepad and math. some terms are limited to 0-pi range, some 0-2pi, and for rough orbit tracking we probably only need 2pi/255 resolution on some of them. @grantregen and @aleclessing any thoughts?

[polygnomial]

@Timvrakas I'm gonna push back on some of these. Yes, we lack sensor precision, but we are filtering and performing some fusion (hopefully). For orbital position, that's not as much something driven by the TLE and more by our goals of doing terrain relative orbit determination.

[Timvrakas]

The feedback above is entirely targeted at critical telemetry. I totally see wanting 32 bit orbit telemetry available on request, I just don't think it's useful for determining where to point the antenna.

The hardest part for any cubesat mission is finding it, and talking to it. Once you have that working, you have a many more options to debug cameras/sensors/etc.

The best chance of finding your sat is maximizing how long you can transmit critical data on a full battery. If you only have one orbit to find it before it dies, you're fucked. We should try to have days of power. To that end I'd have the payload, cameras, and RPi off, and just be running critical sensors. You might not even want to detumble, because the UHF is omnidirectional so you can afford to wait.

Being able to send 20% less data per packet means you get 20% more times to try to listen for it.

[polygnomial]

In that case we don't need orbital position in telemetry. Like we can just grab the TLE from spacetrack and solve it on ground (with better precision).

[polygnomial]

That's a good point about it being hard to find. I think we should break our telemetry down into different types based on what state Sequoia is in.

[Timvrakas]

grab the TLE from spacetrack

Does this always work? I thought we lost Pointr and didn't know where it was?

How do they know what little dot is ours? How long does it last before drifting?

[polygnomial]

Yes, this doesn't always work. I'm pretty sure in that case they didn't know which satellite was ours, out of a number of TLEs. In this case, the only relevant information would be from our terrain relative orbit determination, which requires both the camera and the raspberry pi and it also needs to work.

[Timvrakas]

Don't we have a GPS to tell us where we are?

[polygnomial]

yes, but we don't have it working yet. I would say 50/50 at this point.

[polygnomial]

we like literally don't have it lol