ericstoneking/42

Simulation for spacecraft attitude control system analysis and design

42 - Spacecraft Simulation

42 is a comprehensive general-purpose simulation of spacecraft attitude and orbit dynamics. Its primary purpose is to support design and validation of attitude control systems, from concept studies through integration and test. 42 accurately models multi-body spacecraft attitude dynamics (with rigid and/or flexible bodies), and both two-body and three-body orbital flight regimes, modelling environments from low Earth orbit to throughout the solar system. 42 simulates multiple spacecraft concurrently, facilitating studies of rendezvous, proximity operations, and precision formation flying. It also features visualization of spacecraft attitude.

Features:

• Multi-body dynamics (tree topology, rotational and/or translational joints)
• Rigid and/or flexible bodies
• Multiple spacecraft (prox ops, formation flying, or independent)
• Inter-spacecraft and spacecraft-surface contact forces support landers, rovers, and spacecraft servicing scenarios
• Two-body or three-body orbits, anywhere in the solar system
• Optional visualization
• Socket-based interprocess comm (IPC) interface to other apps
• Fast setup for concept studies
• Rigorous and full-featured to support full spacecraft life cycle

Installation

If you're installing on Windows, see the file "Install-msys.txt" in the Docs folder.

The compiler will attempt to detect what platform you're on (Linux, OSX, or Msys), but its success rate isn't great. If you have errors on the first compile or run, try editing your Makefile to manually set your 42PLATFORM.

For OpenGL graphics, newer Macs with Retina displays will need the GLFW graphics libraries, available from MacPorts, Homebrew, and probably elsewhere. Otherwise, you'll need the GLUT libraries, which are also readily available if not already installed on your system. Graphics are optional, settable in the Makefile by GUIFLAG.

Getting Started

See the overview, "42 Overview.pdf", in the Docs folder. Also recommended:

• Nomenclature.pdf
• POV Menu.pdf
• Key Bindings.txt
• FSW Models.pdf
• Flight Regimes.pdf

The default folder for inputs and outputs is "InOut". Look there for sample input files. "Inp_Sim.txt" is the top-level input file.

The input/output folder may be changed for a sim run by running 42 with an argument. For example, enter this at the command prompt:

42 Demo

Common Problems

1. 42 expects the input files to be plain vanilla text files. If your text editor adds formatting, makes straight quotes into smart quotes, etc, 42 may get confused. The most common symptom is generating the "Bogus input in DecodeString" error.

2. Also text-related, 42 is very simple-minded about reading the input files. Adding extra lines, or accidentally deleting a line, or swapping lines, will throw things out of synch. Again, the most common symptom is the "Bogus input in DecodeString" error. Use your debugger to trace back where the error was generated. (The actual mistake may be at that line, or may be somewhere upstream.)

42's Issues

42 Cam graphics choppy using VMware with an Ubuntu guest

A recent commit has made the graphics choppy in the 42 cam when running in VMware with an Ubuntu guest. This problem seems to be recently introduced. An early September clone of the repo did not exhibit this behavior. Seeing the following error in the dmesg log.

[drm:vmw_stdu_primary_plane_atomic_update [vmwgfx]] ERROR Failed to update STDU.

We will continue to review recent commits to see if we see an obvious error and will report back if we do.

Tx/Rx example crashing

We have setup a simple data server to push PVT to 42 for visualization of our simulation, but find 42 has been crashing after a few seconds. I went back and ran the Tx/Rx example,, but the rx instance also segaults after a few seconds. Unfortunately I haven't been able to generate a core file to try and debug.

What conditions are you aware of that cause the Rx instance to default? I'm currently running off develop.

Use UTC.JulDay (UT1, actually) for JD2GMST

Hi, I'm one of your users from South Korea.
First of all, I'm sincerely thankful for your code. It helped my project a lot, really.
Actually, I've noticed you mentioned that the function JD2GMST us JD in TT as its input.
After I looked through your reference and others, however, it has to be UT1 time system, not TT.
Could you check again about this matter?

Best regards,
Jinyoung

SimReadFromSocket sent and actual

Mr. Stoneking,

Tried to use the socket receiver in 42 to accept a set quaternion value:

SC[0].B[0].qn = 0.755903 -0.195576 0.567993 0.260278

but it didn't seem to fully use it...the spacecraft did change orientation a bit, but the next reported QN was:

SC[0].B[0].qn = 0.725113, -0.196976, 0.576276, 0.321430

The value before I issued the command over IPS was:

SC[0].B[0].qn = -0.589527, 0.310044, -0.503257, 0.550512

Am I using it correctly? Is there a max rotation it will perform in a step?

Earth twitches on demo

I have downloaded current master, and have problem - image of Earth twitches. Problem has appeared in commit f84857f

https://youtu.be/-An4PWLio-c?t=2

Ubuntu 20.04

glxinfo:

Device: Radeon RX 570 Series (POLARIS10, DRM 3.35.0, 5.4.0-52-generic, LLVM 9.0.1) (0x67df)
Version: 20.0.4

Planetary propagation of Mars seems inconsistent with other simulations

I have created several 42 scenarios involving S/C in orbit around Mars. Those scenarios have time epochs in 2020.

To verify the locations of orbits over features on the Martian surface I created an identical scenario in STK, which did not agree with 42. I noticed that in addition to the orbits not matching up, Mars' surface solar illumination condition is also in disagreement (wrong face of the planet is facing toward the Sun). This is more likely the root issue than the orbits themselves.

I have struggled for some time trying to find problems in my 42 input files, but so far have not unearthed anything. Thinking the problem could conceivably be in STK, I used JPL's Solar System Simulator (https://space.jpl.nasa.gov/) as a tie breaker. It agreed with STK...

So I am hoping to get some guidance on whether I have missed a critical detail or if the propagation of Mars planetary state is indeed incorrect. I plan to set up 42 scenarios for some of the other planets to see if inconsistencies appear there as well.

Oh... For the record, Earth is fine. Any 42 scenario I create involving Earth is completely consistent with STK.

TLEs don't work when J2 Drift is enabled

When running a sim with with

• an orbit given by a TLE and
• "Secular Orbit Drift Due to J2" set to TRUE in the orbit file,

the spacecraft orbit is set up in a way such that its position never changes:

$ cat IO3/PosN.42 
6.854132e+06 0.000000e+00 0.000000e+00
6.854132e+06 0.000000e+00 0.000000e+00
6.854132e+06 0.000000e+00 0.000000e+00
6.854132e+06 0.000000e+00 0.000000e+00
...

Pseudo code for 42

This is not an issue but a question. We use this program at my university's small satellite program for our two 6u cubesats. The department wants me to go line by line and write what each part of the code does in simple terms so someone new to it can learn it fairly quickly. Do you have a pseudo code already written for this program?

42dynamics.c vs 42dynam.c

Do the files Source/42dynamics.c and Source/42dynam.c both need to be included in the source code here? I've been working on adding a new component to the dynamics model and these two files have caused me a bit of confusion. It appears that these files are mostly identical, except that 42dynam.c has some extra code that refers to CMGs. Most of that extra CMG code is excluded with #if 0 ... #endif macros.

I guess the questions that arose while I was poking around in the dynamics are:

• Which of these files should I modify if I want to add a feature of the dynamics model? I've been modifying 42dynamics.c and that seems to work, but maybe I need to edit both files?
• Do both of these files need to be in the source? Choosing just one of them would make the codebase easier to understand.

Any clarifications here would be greatly appreciated - thanks!

Running 42 in background with no GUI causes IPC to NOT be loaded

Was doing a test running 42 in the background (NOS3 build) and ran into a weird issue, was wondering if you might have an idea as to what is happening...
If I start the simulation with the GUI set to false via a command like this, it works fine:

cd /opt/42
./42 <sim folder>

However, if I then try to run in the background (and save the log) it stops after it reads the Inp_Cmd.txt, but fails to process the IPS or step through the simulation, it just hangs:

./42 <sim folder> | tee /tmp/42.log

Produces:

Material material_3 is not in Matl structure
Setting material to default
0.0 SC[0] qrl = [0.0  0.0  0.0  1.0]
Reached CmdScript EOF at Time = 0.000000

Looking at the 42exec.c, it seems like it should be fine...after processing the command interpreter, it checks whether sockets are enabled ('ENABLE_SOCKETS'; they are, but don't see the 'server listening'), then it checks 'USE_GUI' (it is), but the 'FALSE' should set 'GLEnable' to false, so it should drop into the 'SimStep' processing...actually, those checks are at the compiler level... so they aren't even being done at runtime...

Thanks in advance.

Coarse Sun Sensor `body` initializer

Hi Eric,

I've been using some coarse sun sensors lately and I'm a bit confused by how the sun sensor axis is set up:

42/Demo/SC_ISS.txt

Lines 477 to 481 in bb9d25d

	*********************** Coarse Sun Sensor *******************************
	0 ! Number of Coarse Sun Sensors
	============================== CSS 0 ====================================
	0.1 ! Sample Time,sec
	0 1.0 1.0 1.0 ! Axis expressed in Body Frame

The "axis in body frame" line has 4 numbers, instead of the 3 I'd expect for a unit vector. Looking at 42init.c shows that the first number of that line is CSS->Body and the next 3 are the actual components of the vector:

42/Source/42init.c

Lines 2000 to 2003 in bb9d25d

	CSS->SampleCounter = CSS->MaxCounter;
	fscanf(infile,"%ld %lf %lf %lf %[^\n] %[\n]",
	&CSS->Body,&CSS->Axis[0],&CSS->Axis[1],&CSS->Axis[2],junk,&newline);
	UNITV(CSS->Axis);

A couple questions on this:

1. What is the CSS->Body number? Does it only apply to coarse sun sensors? I don't see a similar Body parameter in the 42init.c lines for the the fine sun sensors, for example:
   

   42/Demo/SC_ISS.txt

   Lines 486 to 494 in bb9d25d

   	************************* Fine Sun Sensor *******************************
   	0 ! Number of Fine Sun Sensors
   	=============================== FSS 0 ===================================
   	0.2 ! Sample Time,sec
   	30.0 20.0 10.0 213 ! Mounting Angles (deg), Seq in Body
   	32.0 32.0 ! X, Y FOV Size, deg
   	0.1 ! Noise Equivalent Angle, deg RMS
   	0.5 ! Quantization, deg
   	0 ! Flex Node Index

2. Does the Body parameter need to be defined on the same line as the CSS point vector? I think it would be more clear change the spacecraft definition files to have lines like this:

============================== CSS 0 ==================================== 
0.1                           ! Sample Time,sec 
0                             ! Body Index (?)
1.0  1.0  1.0                 ! Axis expressed in Body Frame

That way it's clear which of the numbers the components of the Axis vector.

I'd be happy to put together a PR for item 2 above if you like that suggestion!

Thanks,
Thatcher

Citation

This is a substantial piece of software that should be citable. It would be great if a citation along with a bibtex entry can be provided for this project.

Here is a helpful link I found about making this project citable.

Simulation Pauses if the front end visualization view is adjusted

I'm not sure if this is expected behavior or not, but I'm currently in the process of hooking 42 to our flight software implementation (running on our hardware). I noticed however that whenever I adjust the view in the CAM window, that the simulation appears to pause. I've tried setting Inp_Sim.txt to both REAL and EXTERNAL, however I've had no luck there. Anytime the mouse left clicks in the CAM window, the simulation pauses.

I'm currently running all of this on WSL (Ubuntu on Windows 10). I've noticed no other issues since getting started.

If this truly is expected behavior, we can make due without adjusting the visualization. It would just be extremely useful for an upcoming live demo we have to do with all of our hardware in the loop.

Please let me know if there is anything I'm able to do!

EDIT:
The "Summary for DSM" pdf states:

Dynamics engine and visualization front end can run as separate processes on separate computers.

Being able to run the visualization front end as a separate process seems like the solution I'm looking for. I'm unsure how to do that, but I'll keep reading and looking around a bit.

Reaction wheel imbalance on a rigid body

Hey Eric,

I'm currently trying to model the effect of reaction wheel imbalance forces/torques on my pointing accuracy in a particular simulation configuration. I'm assuming a single rigid body containing a bundle of reaction wheels, none of which are centered at the center of mass of the body. From my understanding, all of the reaction wheel structs are in the Body[0] struct, and their body frame locations are treated as FlexNodes given in the Flex File requested in SC.txt. Therefore I have a flex file that contains the body frame locations of each wheel. I've attached the three relevant files. Do you think you could confirm that I'm setting up the simulation correctly to model RW imbalance on a rigid body? I'm a little concerned that things are being simulated that I don't want being simulated, i.e. I don't want to be simulating any flexible body dynamics and I'm concerned that I might be.

SC.txt
Inp_Sim.txt
wheel_flex.txt

Thanks,

Liam

Update Orbit frames before InitSpacecraft()

Hi Eric,

I've encountered an error in spacecraft attitude initialization. I found it while running a simulation

• with a TLE orbit
• in EXTERNAL time
• with spacecraft attitude set in the Local (VVLH/LVLH) frame

although I suspect it would effect simulations with slightly different configs as well.

Here's how to replicate the problem:
Attitude setup in my Spacecraft.txt file (using angle sequence 123 to match the RPY.42 logs:

*************************** Initial Attitude ***************************
NAL                           ! Ang Vel wrt [NL], Att [QA] wrt [NLF]
0.6    0.5    1.0             ! Ang Vel (deg/sec)
0.0    0.0    0.0    1.0      ! Quaternion
60.0  50.0   40.0    123      ! Angles (deg) & Euler Sequence

I won't list the Inp_Sim.txt here, but the relevant parts are that it uses Spacecraft.txt assigned to an orbit defined by a TLE from a couple weeks ago, and I'm operating in EXTERNAL mode.

I'm using unmodified 42 + the change discussing in Issue #33 that fixes the AbsTime/AtomicTime inconsistency. Here's what I get in the logs:

$ cat IO3/AbsTime.42 
652243041.000000
652243042.384000
652243043.384000
652243044.384000
652243045.384000
...
$ cat IO3/RPY.42 
60.000000 50.000000 40.000000
51.067364 -45.131788 135.628397
49.913295 -45.050428 135.773724
48.760679 -44.983642 135.919908
47.609659 -44.931445 136.066860
...

Even though time is stepping smoothly along, there's this huge change in attitude between the first and second lines.

Time Jump in EXTERNAL timemode

Brief Description:
When 42 starts up in EXTERNAL-time mode, it doesn't seem to use the correct spacecraft attitude if the attitude is specified in the Local (L) frame. What seems to be going on - at least for LVLH attitudes - is that the correct LVLH attitude is produced, but then the orbit starting location is moved, so the LVLH attitude is no longer correct.

To see this problem in action:

• In Inp_Sim, set time mode to EXTERNAL
• Set angles to *AL, so that we use Angles in LVLH frame to set the attitude. It's also helpful to set the angle sequence to 123 so that you are inputting angles in the same way they are output in the RPY.42 log file. Here is the initial attitude block I used in my Inp_Sim.txt:

  *************************** Initial Attitude ***************************
  NAL                           ! Ang Vel wrt [NL], Att [QA] wrt [NLF]
  0.6    0.5    1.0             ! Ang Vel (deg/sec)
  0.0    0.0    0.0    1.0      ! Quaternion
  60.0  50.0   40.0    123      ! Angles (deg) & Euler Sequence
  

• Run a sim - short is fine. I ran one for 100 seconds, printing every 5 seconds
• Look at the RPY.42 output file:

  $ head IO3/RPY.42 
  60.000000 50.000000 40.000000
  45.345587 -39.943219 138.160030
  43.848478 -36.456984 152.789861
  42.268658 -32.816811 167.750836
  40.665574 -29.695574 -179.715812
  39.505176 -27.198757 -170.465631
  38.978831 -25.215036 -164.409881
  39.009007 -23.666701 -160.992152
  39.396171 -22.522666 -159.495960
  39.927639 -21.742183 -159.240318
  

• The first line (t=0) is the attitude I requested, but after that, the Euler angles jump to some other, different attitude, but evolve smoothly from there.
• This effect only occurs when time mode is EXTERNAL - using time mode REAL or FAST gives a smoothly-evolving set of angles with no initial jump:

  # in REAL timemode here
  $ head IO3/RPY.42   
  60.000000 50.000000 40.000000
  63.472372 52.442270 47.341806
  69.345057 53.454637 58.209298
  75.738691 54.321332 68.901482
  81.490012 55.084756 77.571503
  86.180588 55.454107 83.518959
  89.761833 55.312449 86.859616
  92.288422 54.762706 88.194113
  93.891308 54.011319 88.235279
  94.784569 53.255669 87.571375
  

• Worth noting is that other values have a jump when used in continuous time as well, most notably AbsTime.42 and PosN.42:

  # in EXTERNAL timemode here
  $ head IO3/AbsTime.42 
  610502400.000000
  651210401.384000
  651210406.384000
  ...
  $ head IO3/PosN.42 
  -6.878145e+06 8.423298e-10 0.000000e+00
  5.941199e+05 4.218782e+06 -5.399794e+06
  5.561901e+05 4.220741e+06 -5.402303e+06
  5.182432e+05 4.222572e+06 -5.404645e+06
  

It seems like the 42 simulation starts with the time given in Inp_Sim.txt and only being using EXTERNAL time after one cycle through the main simulation loop.

Documentation for Inp_Graphics.txt file parameters ?

Hello all, I tried to find the documentation for the different options available for the "Initial POV View" field in the "Inp_Graphics.txt".
Which other options except FRONT and FRONT_RIGHT are there ? I tried to use "BACK" but it returned a Bogus input.

Rotation problem

When L3 on unit sphere viewer touches to the top of the window, rotation in lvlh frame stops - sc always directed to earth

But in default demo config SC don't have any thrusters or wheels

Questions: Regarding use of "Point" command in Inp_Cmd.txt

Eric,

Sorry to keep bugging you, I was trying to trace through the code myself, but there is quite a bit of it. When using the "Point" command in the 'Inp_Cmd.txt' file (say a lat/lon on Earth and using the PROTOTYPE_FSW), I had a couple questions:

• how quickly does the satellite turn? (does the 'VectorRampCoastGlide' limit the speed or cause it to taper off? I see it changing IdealTrq's but ...)
• once pointed at the spot, will the SC continue to point there as it orbits (e.g. try to look through the Earth when on the other side)? It seems that it would unless something changes the Mode of the command vector
• how do the secondary vectors get populated? I see they are zeros when calloc'd memory for the structure, but if I set the Primary vector with a "Point" command, I see the secondary vector is used (in calculations) as well, but don't see how they get set (without a specific command).

Thanks in advance

Consideration of GitHub Actions?

Would the 42 project be open to including some GitHub actions in the repo? I have set up a few in my fork of 42 that run make commands every time I push to master (or open a PR) and it's been super valuable.

As an example, the actions I currently have set up on my fork show that current 42 compiles correctly on Ubuntu, but only with the graphics disabled. GLFW doesn't work on stock ubuntu (maybe there's library I should install) and there's a bug that pops up when you try to compile with GLUT on Ubuntu (probably an easy fix). To me these results show the value of adding Actions - right off the bat I would be able to see if changes I added to 42 would cause build errors on other platforms. I'm going to add Windows and MacOS builds too to see how make works on those platforms as well.

Pros:

• can test compilation on all platforms when new commits are pushed\
  • will show compilation errors that arise on any of the platforms
• provides reference compilation instructions for all platforms
• requires no C code modifications, just a GH actions description file
• provides maintainers with a quick report on any suggested code changes

Cons:

• adds code to repo
• Limited GitHub Action time budget: free accounts are limited to 2000 minutes per month, so if there's a month with lots of pushes to the master branch tests might become unavailable toward the end of the month. I don't expect 42 would run into this issue as builds are pretty quick. See here for more details

Example:

Here's a PR I have open on my fork of 42 (same as upstream 42 but with actions enabled) right now: ThatcherC#1. When I submitted this PR, the makes automatically ran and identified build errors in the Ubuntu GLFW and GLUT builds and a successful build of 42 without graphics:

Is this something we could add to the main 42 repo? I could put together a set of Actions if there's interest! I think it'd be a great asset to add the project.

Best,
Thatcher

Confusing READMEs

Having two READMEs is confusing. Is it possible to merge the two?

LVLH Output

Hello,

Would it be possible to easily modify your code to output LVLH? Also, does 42 recommend corrective actions if attitude tolerances are given?

Regards,
Jeff

Make error when making target `AcApp`

GCC: 8.3
When making target AcApp: make AcApp, the make process errors out. Here is the make output, link.

AbsTime/AtomicTime

I've noticed a time jump in the AbsTime.42 log files output after each run. There's always a jump of ~33 seconds between the first line of the log file and the second. Here's an example from a simulation I ran today:

$ cat IO3/AbsTime.42 
651661164.400000
651661197.984000
651661198.984000
651661199.984000
651661200.984000
...

I think this effect comes from a difference in time calculations between Source/42init.c and Source/42exec.c, shown below. I'm confident that these bits of code produce different results (at a minimum, in 42init.c, AtomicTime = DateToAbsTime(Year,Month,Day,Hour,Minute,Second) - 32.184 in the end, while in 42exec.c, AtomicTime = DateToAbsTime(Year,Month,Day,Hour,Minute,Second+LeapSec); ) but I'm not sure which snippet is the correct one.

42/Source/42init.c

Lines 3998 to 4012 in c8dc07a

	/* .. Time */
	#if defined _USE_SYSTEM_TIME_
	if (TimeMode == EXTERNAL_TIME) {
	printf("Initializing with external time\n");
	RealSystemTime(&Year,&doy,&Month,&Day,&Hour,&Minute,&Second,DTSIM);
	}
	#endif
	AbsTime0 = DateToAbsTime(Year,Month,Day,Hour,Minute,Second);
	doy = MD2DOY(Year,Month,Day);
	JulDay = AbsTimeToJD(AbsTime0);
	AbsTime = AbsTime0;
	AtomicTime = AbsTime - 32.184; /* TAI */
	CivilTime = AtomicTime - LeapSec; /* UTC "clock" time */
	GpsTime = AtomicTime - 19.0;
	JDToGpsTime(JulDay,&GpsRollover,&GpsWeek,&GpsSecond);

42/Source/42exec.c

Lines 103 to 117 in 651ee6b

	case EXTERNAL_TIME :
	while(CurrTick == PrevTick) {
	CurrTick = (long) (1.0E-6*usec()/DTSIM);
	}
	PrevTick = CurrTick;
	SimTime += DTSIM;
	itime = (long) ((SimTime+0.5*DTSIM)/(DTSIM));
	SimTime = ((double) itime)*DTSIM;
	RealSystemTime(&Year,&doy,&Month,&Day,&Hour,&Minute,&Second,DTSIM);
	AtomicTime = DateToAbsTime(Year,Month,Day,Hour,Minute,Second+LeapSec);
	AbsTime = AtomicTime + 32.184;
	JulDay = AbsTimeToJD(AbsTime);
	JDToGpsTime(JulDay,&GpsRollover,&GpsWeek,&GpsSecond);
	AbsTime0 = AbsTime - SimTime;
	break;

The fix is probably to replace the code in one of these snippets with the code from the other, but I'm not sure which is right one. I can't say for sure which way to correct way to calculate these various times, so I would welcome expert opinions!

Unused but set variable warnings

GCC: 8.3
Command: make
@ericstoneking I am getting several -Wunused-but-set-variable warnings. Is there a particular reason for keeping them? Would it be fine if I submit a PR that resolves these warnings?

42 and NOS3...still working?

Mr. Stoneking,

I apologize for asking such a n00b configuration question, but I was recently looking at the NOS3 and the latest version of 42 and have some simple (for you questions)...

Though the functions are still defined in 42.h (NOS3SendMessageToFSW, NOS3ReceiveMessageFromFSW), the '42nos3.c; file no longer supports sending telemetry to or reading commands from the NOS Engine...only getting time from NOS. Is that correct? If so, is there a reason it is no longer supported?

I was hoping to use multiple instances of NOS FSW to simulate multiple satellite missions, but the version of 42 installed with NOS3 seems to be only configured via the Inp_NOS3.txt (same as for time). I know I can change CPU, etc. with the NOS FSW, but I don't see a way, right now, that I could attach them to 42. Am I going down the wrong path?

Thanks in advance.

Regards,
Peter Blanchard

Add support of YAML configs

Reasons why I think YAML configs are good:

1. Plain text configs sometimes hard to read because different options are mixed together. For example

KEP                           !  Use Keplerian elements (KEP) or (RV) or FILE
PA                            !  Use Peri/Apoapsis (PA) or min alt/ecc (AE)
100.0     100.0               !  Periapsis & Apoapsis Altitude, km
400.0  2.0                    !  Min Altitude (km), Eccentricity
52.0                          !  Inclination (deg)
180.0                         !  Right Ascension of Ascending Node (deg)
0.0                           !  Argument of Periapsis (deg)
0.0                           !  True Anomaly (deg)
0.0  0.0  0.0                 !  RV Initial Position (km)
0.0  0.0  0.0                 !  RV Initial Velocity (km/sec)

Keplerian PA, Keplerian AE, RV, and file, all they don't separated. And you can not add line for separate them because of very strict file format

2. You can not comment-out lines. While in YAML you can do something like

        Position_Velocity_Orbit_Parameters:
#            Position:   [6000, 0, 0]    # km
            Position:   [7000, 0, 0]    # km
            Velocity:   [8, 0, 0]       # km/s

And it's easy to switch between 6000 and 7000 variants.

Now i'm gradually adding such support

Segmentation fault

Hello,

I'm running 42 on a debian virtual machine. There seems to be no issue in running 42 without graphics, but enabling the GUIFLAG throws a segmentation fault. I'm grad student and a novice in programing. I'm currently working on a CubeSat project and hence came across this. The following are the contents of runlog.txt and makelog.txt (I've ran make $1 2>&1 | tee makelog.txt and ./42 $1 2>&1 | tee runlog.txt, referring to a previous issue)
makelog.txt
runlog.txt

Thank you for your time.

How to get ECEF data from Socket IPC

I have been poking around in the the repository, internet and docs trying to figure out how to obtain ECEF data from the simulation of the socket. Currently what I have achieved is an output packet that looks like:

TIME 2014-172-00:00:07.400000000
SC[0].PosR = 0.000000000000e+00 0.000000000000e+00 0.000000000000e+00
SC[0].VelR = 0.000000000000e+00 0.000000000000e+00 0.000000000000e+00
SC[0].svb = 1.911549569229e-01 7.909220372261e-01 -5.812934830823e-01
SC[0].bvb = -3.996145331303e-05 2.917178560806e-06 -2.245080882139e-05
SC[0].Hvb = 3.102972229380e-02 -1.803329063292e+00 -1.674012035485e-01
SC[0].AC.ParmLoadEnabled = 0
SC[0].AC.ParmDumpEnabled = 0
SC[0].B[0].wn = 3.102972229380e-04 -9.016645316460e-03 -5.580040118285e-04
SC[0].B[0].qn = 5.005973816419e-01 2.828773014671e-01 5.711165756938e-02 8.161623321237e-01
Orb[0].PosN = 5.597997251275e+06 -4.649154587081e+05 3.266666278426e+06
Orb[0].VelN = -3.938776316545e+03 -9.662977797767e+02 6.789562087021e+03
[EOF]

From an Inp_IPC.txt that looks like:

<<<<<<<<<<<<<<< 42: InterProcess Comm Configuration File >>>>>>>>>>>>>>>>
1                                       ! Number of Sockets
**********************************  IPC 0   *****************************
WRITEFILE                               ! IPC Mode (OFF,TX,RX,TXRX,ACS,WRITEFILE,READFILE)
0                                       ! AC.ID for ACS mode
"State00.42"                            ! File name for WRITE or READ
SERVER                                  ! Socket Role (SERVER,CLIENT,GMSEC_CLIENT)
localhost     10001                     ! Server Host Name, Port 
FALSE                                   ! Allow Blocking (i.e. wait on RX)
TRUE                                    ! Echo to stdout
3                                       ! Number of TX prefixes
"SC"                                 ! Prefix 0
"Orb"				! Prefix 1

As I understand it, Orb[0].PosN is giving me an ECI position and what I want is ECEF but I am failing to understand why it is not dumping these values (source code appears to suggest it has them). Do I need to adjust 42.json and re-run the IPC python script followed by rebuild to get this to output or is there something I can change in the configuration such as the spacecraft definition? This is all being run from modifications on the Inp_IPC.txt in the Tx folder (i.e. the spacecraft and orbit definitions are whatever is currently there).

42 Not Able to Run Due to Syntax Error

Hi there!

I am extremely new to coding in any sort of language, but I was asked to look into getting this program to work for my design team at school. I went through the steps to download msys and also Ubuntu and attempted to execute 42 within both of them. I kept receiving the same error "line 3950: syntax error: unexpected end of file" so it would not run. I was wondering why this was as when I opened up the code to take a look at line 3950, it did not exist? It only goes up to line 3949.

Thank you for your time,
Evan Warner

string overflow warnings

make:

./Source/42init.c:3495:10: warning: ‘fgets’ writing 512 bytes into a region of size 511 overflows the destination [-Wstringop-overflow=]
 3495 |          fgets(line,512,infile);
      |          ^~~~~~~~~~~~~~~~~~~~~~
In file included from ./Include/42.h:23,
                 from ./Source/42init.c:15:
/usr/include/stdio.h:568:14: note: in a call to function ‘fgets’ declared with attribute ‘write_only (1, 2)’
  568 | extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
      |              ^~~~~
./Source/42init.c:3497:10: warning: ‘fgets’ writing 512 bytes into a region of size 511 overflows the destination [-Wstringop-overflow=]
 3497 |          fgets(line,512,infile);
      |          ^~~~~~~~~~~~~~~~~~~~~~
In file included from ./Include/42.h:23,
                 from ./Source/42init.c:15:
/usr/include/stdio.h:568:14: note: in a call to function ‘fgets’ declared with attribute ‘write_only (1, 2)’
  568 | extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
      |              ^~~~~
./Source/42init.c:3510:10: warning: ‘fgets’ writing 512 bytes into a region of size 511 overflows the destination [-Wstringop-overflow=]
 3510 |          fgets(line,512,infile);
      |          ^~~~~~~~~~~~~~~~~~~~~~
In file included from ./Include/42.h:23,
                 from ./Source/42init.c:15:
/usr/include/stdio.h:568:14: note: in a call to function ‘fgets’ declared with attribute ‘write_only (1, 2)’
  568 | extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
      |              ^~~~~

GCC: 10.2.0

Magnetic Moment of a Satellite and Hysteresis Rods Inclusion

Hi M. Stoneking,

We are using 42 in our project to simulate the current design of a CubeSat. As of right now, we are concerned with the inclusion of the magnetic moment created by permanent magnets required for our payload to work. We tried to use magnetorquer as a permanent magnet but we can't seem to find any direct control of them. Is there a way to include the magnetic moment from the satellite itself or to directly control the magnetorquer?

We also want to know if it is possible to add the effect of hysteresis rods to the simulation as this would better reflect our current attitude control configuration.

Thank you
Julien Roy

Invalid arch name '-arch macOS-arm64'

Hi Eric,

I've been enjoying 42 for a bit now, and its helped immensely with running some quick simulations for potential university satellite proposals. I've been using it on a msys, but I just recently transitioned to a mac with an M1 processor and noticed that the make file keeps failing when trying to run "make" while in 42. After digging through the make file I can't figure out where my issue is or how I can work around it. I have gone ahead and attached a makelog.txt to help show you my issue. Do you have any suggestions?

Thank,

Miles
makelog.txt

Question Regarding Attitude and Satellite View Intersecting Earth

Mr. Stoneking,

I was trying to figure out how to use the information that 42 is outputting to determine where on the ground a satellite can "see" from its orientation (given the assumption of a camera on the 'downside' of the spacecraft at start of simulation)...from the available outputs, I see the:

• PosN (Position of cm wrt origin of N, m) vector that gives me the ECI (which I can invert for Sat-to-Earth)
  • e.g. SC[0].AC.GPS[0].PosN = -6.618837523057e+06 -1.151775513349e+06 1.474205430476e+06
• QN (Quaternion of S/C (B) in N) - when not spinning reaction wheels it is the identity quaternion (x y z s) (0 0 0 1)
  • e.g. SC[0].B[0].qn = 0.000000000000e+00 0.000000000000e+00 0.000000000000e+00 1.000000000000e+00

I had found this article Satellite Line of Sight Intersection with Earth, but when I try to plug-in those numbers the computation tells me the satellite is not pointing AT the Earth. Am I looking at something obviously wrong? I try to determine the direction vector by extracting it from the quaternion (they use a (w x y z) q instead of (x y z s), but that should be fine as I compensate)...but that gives me a direction vector of (0 0 1). If I use the direction vector from their example (and the inverted PosN), I get an answer...

Thanks in advance.

Regards,

Pete

Make clean target error

System: Linux
When trying to clean the project (make clean) make errors out as shown below:

rm ./Object/*.o ./42 ./AcApp ./InOut/*.42 ./cFS/*.42 ./Demo/*.42 ./Rx/*.42 ./Tx/*.42
rm: cannot remove './AcApp': No such file or directory
rm: cannot remove './cFS/*.42': No such file or directory
rm: cannot remove './Demo/*.42': No such file or directory
rm: cannot remove './Rx/*.42': No such file or directory
rm: cannot remove './Tx/*.42': No such file or directory
make: *** [Makefile:367: clean] Error 1

Graphics Pause Question

Hi Eric,

I'm utilizing your software to stitch together multiple trajectories for on-orbit assembly applications. I'm trying to create screen captures and running into window sizing issues with my current set-up.

My question is regarding the "Pause at Start" option and if the pause can be lifted to resume the simulation somehow, either via command line or 42 window.

Thanks!

Gyro Sensor Documentation

Is there any documentation in the gyro model? ARW and BI do not seem to behave as I would expect. When entering the gyro datasheet values in the spacecraft config file, the gyro noise output does not reproduce the same allan variance plot than the one shown in the datasheet for those values.

Document Clarification: Pointing Target Commands from Network Port

I see clearly that the intended break for the network interface is between sensor measurements and actuator drives. My application I would like to connect cFS to send commands to the standalone 42 application, emulating a communications bus with a stand alone ACS system.

For this, I'm anticipating sending commands that sent the spacecraft to various pointing states.

I see the Inp_CMD file but it doesn't provide an obvious way for those commands to be augmented by another service.

E.g. initial command
0.0 SC[0] qrl = [0.0 0.0 0.0 1.0]

42 Receive via the network
SC[0] qrl = [0.0 1.0 0.0 0.0] (I have not validated this new command but should get the point across)

Is this supported?

Attempted divide by zero in UNITV (Line 337 of mathkit.c - NaN Centroid in SurfaceForceProps

Hello, I followed all the steps in the "A Process to Easily Create .obj Mesh Files for 42 from Your existing CAD Files" pdf document.
Also, I made sure that the origin of my model in Wings3D is also the origin of my imported body in Wings3D as pointed out at the top of page 8 but got that error.

Full Output ---
Attempted divide by zero in UNITV (Line 337 of mathkit.c)
Attempted divide by zero in UNITV (Line 337 of mathkit.c)
Attempted divide by zero in UNITV (Line 337 of mathkit.c)
Attempted divide by zero in UNITV (Line 337 of mathkit.c)
NaN Centroid in SurfaceForceProps

42 Installation Packages

Hello Eric, I'd like to preface this by saying you have created a wonderful project with very strong capabilities. 42 has been and is being used widely at my uni (and many other places I'm sure) and I hope it continues to do so.

I would love to see 42 being used widely. As such, I think it would be a great idea to create packages for this software. Things like a Debian package, Ubuntu PPA, macOS homebrew, etc. Having packages will simplify the installation process and the original hurdle of accessing the software. Are there any plans for creating packages for this project?

I understand that some installation instructions are available in the docs, but it would be great if these instructions were explicitly listed out somewhere like the project wiki instead of inside the repo.

Release Version

It would be beneficial to have a release for 42, so that users can download a release version instead of the latest master branch, which may or may not be stable.

It would also help in packaging 42 for OSs.

Error while installing 42 on linux

Hello to all,

I've downloaded a zip-archive from this repository.
While trying to compile the software on Linux Mint 20.04 via command .../42-master/make I am getting an error about the line AlbedoWindow = glutCreateWindow("Albedo Scratchpad"); :

./Source/42glut.c: In function ‘HandoffToGui’:
./Source/42glut.c:1392:7: error: ‘AlbedoWindow’ undeclared (first use in this function)
 1392 |       AlbedoWindow = glutCreateWindow("Albedo Scratchpad");
      |       ^~~~~~~~~~~~
./Source/42glut.c:1392:7: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:271: Object/42glut.o] Error 1

Before that, I have had an error with using the glut library inside the code, but resolved it installing the necessary packages. I cannot understand here why am I getting this error on the AlbedoWindow variable is just being declared?

The settings I use in the .../42-master/Makefile is (besides that nothing else was changed):

GUIFLAG = -D _ENABLE_GUI_
#GUIFLAG =

# For graphics interface, choose GLUT or GLFW GUI libraries
# GLUT is well known, but GLFW is better for newer Mac's hires displays
#GLUT_OR_GLFW = _USE_GLFW_
GLUT_OR_GLFW = _USE_GLUT_

SHADERFLAG = -D _USE_SHADERS_
#SHADERFLAG =

#CFDFLAG =
CFDFLAG = -D _ENABLE_CFD_SLOSH_

#FFTBFLAG =
FFTBFLAG = -D _ENABLE_FFTB_CODE_

#GSFCFLAG =
GSFCFLAG = -D _USE_GSFC_WATERMARK_

#STANDALONEFLAG =
STANDALONEFLAG = -D _AC_STANDALONE_


GMSECFLAG =
#GMSECFLAG = -D _ENABLE_GMSEC_

I would very appreciate if somebody directs me to a wholesome 'userguide'.pdf or a FAQ document with tips to make 42 work on my Linux, as I could not find or might miss some corresponding file in the .../42-master/Docs/ folder. Cannot use the included file README for this purpose.

Best regards

"Initial Attitude" for B Axes with respect to L Axes

Mr. Stoneking,

What controls the initial orientation of the spacecraft B Axes with respect to the L Axes? I see the "Initial Attitude" (in SC_*.txt) angles set to zero's, the rotation quaternion is identity...shouldn't the initial orientation of the spacecraft body axes line up with the local vertical, local horizontal axes? If not (and it appears not), what controls that? When I turn the Axes on in the UI, they do not line up.

Looking at a small sat, so only one body, no joints. Looking at the .obj file, the sat lines up on the axes with center at origin.

Thanks in advance.

Unable to stabilize after adding gyro

Hi, my simulation uses the sc_simple.txt file. I added a gro to read the angular speed through the gro, but after the increase, it runs 42. The model can't be stable and has been rotating wildly. Am I using it correctly?

Here is the code I modified.

******************************* Gyro ************************************
1 ! Number of Gyro Axes
============================== Axis 0 ===================================
0.1 ! Sample Time,sec
1.0 0.0 0.0 ! Axis expressed in Body Frame
1000.0 ! Max Rate, deg/sec
100.0 ! Scale Factor Error, ppm
1.0 ! Quantization, arcsec
0.07 ! Angle Random Walk (deg/rt-hr)
0.1 1.0 ! Bias Stability (deg/hr) over timespan (hr)
0.1 ! Angle Noise, arcsec RMS
0.1 ! Initial Bias (deg/hr)
0 ! Flex Node Index

Reached CmdScript EOF at Time = 0.000000

I am getting inconsistent behavior in 42. Some times it will start out with similar messages to below and then recover and some times go on for a long time and then ends with Reached CmdScript EOF at Time = 0.000000 Any idea what is causing it?

I see material_4 is in stf1_red.obj and I see other material_## variables in other .obj files does this mean the obj files are being overwritten or corrupted?

...
Material material_3 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_10 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_10 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_10 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_10 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_12 is not in Matl structure
Setting material to default
Material material_11 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_12 is not in Matl structure
Setting material to default
Material material_11 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_12 is not in Matl structure
Setting material to default
Material material_11 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_12 is not in Matl structure
Setting material to default
Material material_11 is not in Matl structure
Setting material to default
Material material_15 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_16 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_16 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_16 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_8 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_16 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_9 is not in Matl structure
Setting material to default
Material material_1 is not in Matl structure
Setting material to default
Material material_1 is not in Matl structure
Setting material to default
Material material_1 is not in Matl structure
Setting material to default
Material material_1 is not in Matl structure
Setting material to default
Material material_1 is not in Matl structure
Setting material to default
Material material_1 is not in Matl structure
Setting material to default
Material material_1 is not in Matl structure
Setting material to default
Material material_1 is not in Matl structure
Setting material to default
Material material_4 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_4 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
Material material_4 is not in Matl structure
Setting material to default
Material material_5 is not in Matl structure
Setting material to default
...

Material material_4 is not in Matl structure
Setting material to default
Material material_3 is not in Matl structure
Setting material to default
0.0 SC[0] qrl = [0.0  0.0  0.0  1.0]
Reached CmdScript EOF at Time = 0.000000

Window resize uncontrollably when interacted with

Ubuntu 20.04.2 LTS with Mesa 21.1.6

Cam View, Orrery and Unit Sphere Viewer windows have a very annoying glitch where the window resize uncontrollably when moved or resized with the mouse. This might be related to bug #45 and #52 since the workaround fixes both.

For this issue however I had to commend out other two lines since just the line suggested in #45 (comment) didn't fix all the windows for me.

This is my workaround:

diff --git a/Source/42GlutGui.c b/Source/42GlutGui.c
index 828dd62..1e1b7a8 100644
--- a/Source/42GlutGui.c
+++ b/Source/42GlutGui.c
@@ -3685,7 +3685,7 @@ void SetPovOrientation(void)
 /*********************************************************************/
 void SetupViewVolume(int width, int height)
 {
-      glutReshapeWindow(width,height);
+//      glutReshapeWindow(width,height);
       glViewport(0,0,width,height);
 
       POV.AR = ((double) width)/((double) height);
@@ -5453,7 +5453,7 @@ void OrreryReshapeHandler(int width, int height)
       O = &Orrery;
       OrreryWidth = width;
       OrreryHeight = height;
-      glutReshapeWindow(width,height);
+//      glutReshapeWindow(width,height);
       glViewport(0,0,width,height);
       InitOrreryWidget();
       O->Radius = ((double) OrreryWidth)/(2.0*80.0)*
@@ -5469,7 +5469,7 @@ void SphereReshapeHandler(int width, int height)
 
       SphereWindowHeight = SphereWindowWidth/2 + 16*(NumSphereWindowMenuLines + 2);
 
-      glutReshapeWindow(SphereWindowWidth,SphereWindowHeight);
+//      glutReshapeWindow(SphereWindowWidth,SphereWindowHeight);
 
       glMatrixMode(GL_PROJECTION);
       glLoadIdentity();

so far I haven't seen any consequences of commenting out those lines, windows can be resized just fine.

Use of EXTERNAL TimeMode option

Hi Eric,

I'm reviewing docs and code and having a difficult time understanding how the EXTERNAL_TIME option is supposed to work. I'm hoping to synchronize 42 with another simulation (which cannot be slaved by a time master), so I'm hoping 42 can be configured to slave to that other sim, hopefully by consuming a "dt tick" message or some similar mechanism. Can you point me in the right direction on understanding how the EXTERNAL_TIME option currently works? If I change my Inp_Sim.txt file to use that option (instead of REAL_TIME or FAST_TIME) I don't see 42 behaving any differently than if I use the REAL_TIME option.

Best,
-Ken Center

How can I show all the spacecrafts at the sametime

************************** Reference Orbits **************************
2 ! Number of Reference Orbits
TRUE Orb_LEO.txt ! Input file name for Orb 0
TRUE Orb_LEO1.txt ! Input file name for Orb 1
***************************** Spacecraft *****************************
2 ! Number of Spacecraft
TRUE 0 SC_Simple.txt ! Existence, RefOrb, Input file for SC 0
TRUE 1 SC_Simple1.txt ! Existence, RefOrb, Input file for SC 1

This is my set, but I can show only one spacecraft at the map.

AcApp exits while trying STANDALONE: "Attempted inversion of singular matrix in MINV3. Bailing out."

Eric, first of all, hats off for 42. It's beyond great, keep it coming. I hope I'll be able to contribute in some way at some point.

Now, I faced some challenges trying to run 42 in standalone mode with AcApp just out of cloning the repo. More specifically, it seems AcApp gracefully exits at the end of GyroProcessing(), where the Gyro axes seems to be all zero, giving a zero AtA matrix, hence the error. I noticed that SimWritetoSocket.c on 42 side does not send the Gyro axes to AcApp through the socket, because it depends on the status of SC[Isc].AC.ParmLoadEnabled, which I can't seem to find where it is initialized or what does it mean. Also, many other things (MoIs, etc) are not sent from 42 to AcApp because of the same ParmLoadEnabled flag.

Do I need to just RTFM or could this be some issue?

Format overflow and misleading indentation

When running make I receive the following format overflow warnings:

./Source/42GlutGui.c: In function ‘DrawClock’:
./Source/42GlutGui.c:2067:24: warning: ‘%04li’ directive writing between 4 and 20 bytes into a region of size between 0 and 79 [-Wformat-overflow=]
 2067 |          sprintf(s,"%s %04li-%03li-%02li:%02li:%02li",SysLabel,
      |                        ^~~~~
./Source/42GlutGui.c:2067:10: note: ‘sprintf’ output between 19 and 185 bytes into a destination of size 80
 2067 |          sprintf(s,"%s %04li-%03li-%02li:%02li:%02li",SysLabel,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2068 |             Year,doy,Hour,Minute,(long) Second);
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./Source/42GlutGui.c:2063:24: warning: ‘%04li’ directive writing between 4 and 20 bytes into a region of size between 0 and 79 [-Wformat-overflow=]
 2063 |          sprintf(s,"%s %04li-%03li-%02li:%02li:%02li",TlmLabel,
      |                        ^~~~~
./Source/42GlutGui.c:2063:10: note: ‘sprintf’ output between 19 and 185 bytes into a destination of size 80
 2063 |          sprintf(s,"%s %04li-%03li-%02li:%02li:%02li",TlmLabel,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2064 |             Year,doy,Hour,Minute,(long) Second);
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and the following misleading indentation warnings:

./Source/IPC/SimReadFromFile.c: In function ‘ReadFromFile’:
./Source/IPC/SimReadFromFile.c:27:10: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
   27 |          if (sscanf(line,"TIME %ld-%ld-%ld:%ld:%lf\n",
      |          ^~
./Source/IPC/SimReadFromFile.c:31:13: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   31 |             if (sscanf(line,"Orb[%ld].PosN = %le %le %le",
      |             ^~
gcc -Wall -Wshadow -Wno-deprecated -g   -I ./Kit//include/GL/  -I ./Include/ -I ./Kit/Include/ -I ./Kit/Source/  -O0  -D _USE_GUI_ -D _USE_SHADERS_ -D _USE_SYSTEM_TIME_ -D _ENABLE_SOCKETS_   -D _USE_GSFC_WATERMARK_    -c ./Source/IPC/SimReadFromSocket.c -o ./Object/SimReadFromSocket.o
./Source/IPC/SimReadFromSocket.c: In function ‘ReadFromSocket’:
./Source/IPC/SimReadFromSocket.c:46:10: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
   46 |          if (sscanf(line,"TIME %ld-%ld-%ld:%ld:%lf\n",
      |          ^~
./Source/IPC/SimReadFromSocket.c:50:13: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
   50 |             if (sscanf(line,"Orb[%ld].PosN = %le %le %le",
      |             ^~

GCC: 9.3.0