INSPIRESat-1 #332
Replies: 5 comments 2 replies
-
Hi! Thanks for the information. I'm first moving this to a discussion, since now we handle threads devoted to support to satellite teams as discussions. |
Beta Was this translation helpful? Give feedback.
-
My understanding is that the modulation and coding used by INSPIRESat-1 is standard 9k6 FSK AX.25 G3RUH packet radio. Regarding your question:
These two operations commute, so the order in which you perform them doesn't matter. Therefore, I think that the following SatYAML file will be enough to obtain frames from your satellite (this is using the temporary NORAD from SatNOGS DB):
Can you test if this SatYAML file works with your satellite? The next step would be to write a telemetry parser for your frames using construct. Your frame structure seems very similar to that of CUTE, perhaps due to the use of the same SpaceQuest TRX-U transceiver (and in fact you mention CUTE in your message). Code for CUTE is already available here. Can you take a look at this code and the documentation for CUTE and check if what you need is exactly the same or there are some differences? Depending on the differences, we may want to extract the common part to a telemetry parser for the TRX-U and then have the differences separately. Please give me some feedback on this aspect so that we can determine how best to proceed. |
Beta Was this translation helpful? Give feedback.
-
Hi @daniestevez,
Good eye! INSPIRESat-1 does indeed have some similarities with CUTE, as it was developed by IIST, NCU, and NTU in partnership with LASP, and as such uses some LASP code in its FSW.
Sorry about that—I have been working with @Dhruva-Ananth to get support for INSPIRESat-1 into gr-satellites (as well as SatNOGS): he is following some internal written guidance I put together when I did the same for CUTE that is now a little stale—I need to update this to direct our engineers and collaborators to open discussions and not issue reports for new teams. (This is also why CUTE appears in the original post—a copy/paste error from the original CUTE gr-satellites discussion). Along these lines—I have a parser that is, I think, just about ready to be merged that I have pushed to lasp/gr-satellites fork as commit Outstanding issues are that I think a conversion needs to be added for
I think this SatYAML file is correct in every regard except a NORAD ID has since been assigned, 51657. @Dhruva-Ananth, could you please test @daniestevez's SatYAML file (with the corrected NORAD ID)? |
Beta Was this translation helpful? Give feedback.
-
Ni Nicholas, Thanks! I've taken a look at ab7848a5 and it looks good. I'd rather I think it could be good to separate the CCSDS portions into a separate file, but as you mention, there is always the risk of making the code too complicated to handle small differences. Time codes are often project-specific, for instance, so I wouldn't try to make general code for that. In case it seems too complicated, I think it's OK not to share this code. After all, it's just going to be a dozen line listing the fields in the CCSDS packet headers, so it's not much of a problem if this is repeated with some small variations. |
Beta Was this translation helpful? Give feedback.
-
Hi Daniel,
Ah, thanks for reminding me of that--I would have forgotten otherwise. I have modified
I agree that the CCSDS primary header, at least, could be refactored. I've since realized that there was a CCSDS primary header definition already available in Other changes I made in this commit:
By the way, for future LASP CubeSat missions that are using the same codebase, the secondary header could at least be refactored into a separate file: missions coming up for which I think this would apply would be CTIM and SPRITE (as well as some others that are futher off whose names I can't quite recall...). I believe CTIM will be launching later this year. SPRITE is further off. I would have to talk with our CubeSat FSW lead to know how similar the telemetry is between these missions. I think that refactoring would best be done in future when support for those CubeSats is added to gr-satellites. It is worth noting that only the CUTE sw_stat packet is generated by LASP software: the other packets are generated by the BCT bus used on that CubeSat. This is why the APID in the primary header and the time format in the secondary header are different between CUTE and INSPIRESat-1. Along these lines, CIRBE is another LASP CubeSat which is also slated to launch later this year (actually, on the same rocket as CTIM) which also uses a BCT bus (though of one generation newer), and so should have more similarity to CUTE than to INSPIRESat-1/CTIM/SPRITE. CSIM is another LASP CubeSat currently on orbit which uses a BCT bus (of the same generation as CUTE) and should therefore be very similar to CUTE. There is currently a SatNOGS decoder for CSIM, though not a gr-satellites one. So really, I suppose CSIM, CIRBE, CUTE, and any other BCT XB1-based CubeSats could share the same CCSDS secondary header definition and time adapter. Anyway, I also went ahead and pushed a second commit to lasp/gr-satellites with the SatYAML file added, I am attaching a GNU Radio 3.9 flowgraph to this comment as well as a 48 kHz audio file containing INSPIRESat-1 beacons (in raw 32-bit float format) that can be used to test the satellite YAML file as well as the telemetry decoder. The audio file is a cut-down version of SatNOGS observation #5478149. The .zip file containing these two files is available here: inspiresat.zip Anyway, please let me know if you have any other changes you'd like to see made, or if you'd like me to go ahead and open a pull request. Thanks, Nick |
Beta Was this translation helpful? Give feedback.
-
IS1 Introduction
The INSPIRESat-1 is a to-be-launched nanosatellite from the International Space Program In Research and Education (INSPIRE) Educate to promote cultural exchanges through international collaborative space science and spacecraft engineering projects.
It consists of 2 Payloads:
Telemetry Beacon
We have a open beacon definition for the community,
Transmitter Description
The flowgraph used for reception using USRP blocks, here
Other than the flowgraph other external dependencies for the operations can be used and are as follows:
Beacon Packet Definition
Once we receive the PDUs after HDLC de-framing (CRC, Preamble, byte ordering) the following packet structure.
Framing
All data sent by the CUTE spacecraft over the 70cm (437.250 MHz) link are contained within AX.25 unnumbered information (UI) frames:
The control field is always set to 0x03, which identifies the AX.25 frames as unnumbered frames. The PID field is always set to 0xF0, which indicates that no layer 3 protocol is used.
Source and Destination Call Signs
Note that the 'hex' column shows the numeric value corresponding to the ASCII character displayed in the 'char' column before it is a bit shifted to obtain a said character.
6 Byte header for the CCSDS packet.
Beaconing
The 70cm transceiver is configured to beacon at a rate of once every 10 seconds, though this rate may be changed post-commissioning.
Each beacon consists of a single state of health (SOH) packet, which fits in a single AX.25 UI frame: these packets contain 256 bytes of data (including 6 bytes of CCSDS primary header).
More info is in this Repository, for the extended beacon definition.
To-Do
More resources
GRC scripts for PDU generation are available at this repo, for some reference !
Thank you very much!
Beta Was this translation helpful? Give feedback.
All reactions