Physical Architecture: FlexTrak STM32 Transceiver Modelling (Downlink)

[chgio]

Existing diagrams to extend:

• [x] [PCBD] Root Physical Component Breakdown
• [x] [PAB] Root Physical Architecture
• [x] [PFBD] Root Physical Function Breakdown

New diagrams to create:

• [x] [CII] Root Internal Interfaces
• [x] [ES] Communications TX Scenario
• [x] (Optional) [PAB] Physical Architecture View of Communications TX
• [x] (Optional) [PDFB] Functional Dataflow View of Communications TX

[chgio]

FlexTrak mock diagrams (LucidSpark)

[xszymonzur]

Additionally: Add:

• [x] [PFCD] Transciever Downlink

Edit (for why, see 82344d3):

• [x] [PAB] Physical Architecture View of Telecommands
• [x] [PAB] Physical Architecture View of Mode Changes
• [x] [PAB] Physical Architecture View of Mission Activities
• [x] [PFCD] Physical Functional Chain Description of Telemetry Retrieval (most notably)

btw after reading https://github.com/daveake/flexavr/blob/master/lora.ino I don't believe just sending the SSDV CMD (in FlexTrack's current state ofc) as proposed in the mock diagram in would do the trick :)

[chgio]

don't believe just sending the SSDV CMD [...] would do the trick

can you please elaborate? :)

[xszymonzur]

Sure, here: if (++ImageCount > (GPS.Altitude > Settings.High ? Settings.HighImageCount : Settings.LowImageCount)) { ImageCount = 0; } else if (SSDVBufferLength < 256) { ImageCount = 0; } , and if (ImageCount == 0) //send telemetry, otherwise send SSDV; this means SSDV is send only when the buffer is full (correct me if I'm wrong here, it's late 😴) which in turn means there is a possibility the telemetry wouldn't be send right after the command (if it's too small) or, more likely, be fractured. I'm assuming different telemetry retrievals and TC reports will have different sizes, so this approach might not be ideal (we could artificially "fill" up missing bytes to the full packet size but that seems wasteful).

Generally, to my limited understanding, there are two ways in which the out-of-the-box FlexTrack board sends data:

• telemetry - it is being sent continuously without the need of any external commands being issued to the board by the Pi (or the OBC in our case); it is the author's "intended" way of sending the telemetry, it is what the recommended app will display and the author's firmware already provides the code to send some useful data with it. There is a possibility to use up to 6 (source code says 4? 🙃) Programmable Fields; this is the "intended" way of sending the additional telemetry. In the Pi software it is achieved by the AddField(...) (it sends the ~F* command to the board), in the FlexTrack firmware they are stored in the GPS.ExtraFields[...], a TGPS struct (might seem rather peculiar but makes sense considering it was added later). Also, telemetry already has the CRC attached to it for error detection. The table of available fields:
• SSDV (Slow Scan Digital Video?) - it is being sent in packets of 255 bytes when the contents of the buffer exceed (or is equal to) 255 bytes; the commands ~SP and ~SB both append data to the buffer stored on the board. It is the author's "intended" way of sending images. The Pi software sends the SP command using SendPacket, which is called only in one place, taking the data from the camera as a parameter. The SB doesn't seem to be called at all. It does, nevertheless, allow for transmission of arbitrary data. The command is processed in ProcessSSDVCommand(...). I didn't find anything similar to the CRC attached to the packet, but maybe I have missed it.

Let me know if any of this makes sense and what doesn't. Of course we have the access to the source code of both the OBC and FlexTrack so we can change everything to our will (especially the OBC part, as we'll have to make that from scratch), and don't have to obey the "intended" parts but I'm concerned about the receiving end. We haven't discussed how we intend to receive the data at all, but those are my two cents. 😅

[chgio]

closing for abandonment of the FlexTrak in favour of an in-house-developed comms module based on the STM32WL55JC Nucleo Devkit. thank you very much @xszymonzur for all your great work, keeping it for docs.