Release Status Display - Hardware Edition

[Hossi]

Disclaimer 1: This tool is in no way related to Robert Maynards StatusDisplay, beyond the fact that I obviously got my inspiration from there
Disclaimer 2: I'm not entirely sure if that's the right section of the forum. Its a definitly a tool, it contains software.... but its not entirely software. If some moderator feels this doesn't belong here, feel free to move it (wasn't there a hardware forum once?)
Disclaimer 3: The whole thing was planned, build, assembled, soldered and wired by me. Every single line of code was written by me. Even though I obviously copied some lines from some sort of documentation.

Introduction:

I was always a fan of eighties style cockpits, big chrome switches and blinking lights. I'm also a big fan of having a fixed placed for every important information, instead of clicking trough 3 sub-menues. And I was looking for some new diy-project to keep me busy...
So I build this here

Spoiler

The upper one, not the lower one. The lower one is the input panel I've build years ago. Technicaly its just a USB-keyboard with different switches attached to it and some relais to run the leds.
The upper one is a status display pannel, run by an Arduino Mega 2560, connected via usb to my gaming rig, that receives status information from the journal and the status.json.

I can upload the code if anyone is interested, but please be aware that building that thing takes some time. Longerer than writing the code.

Features:

Spoiler

Power: Obviously the power switch
Master Warn: Yellow/Red/Red-Blinking: Indicates all sort of bad stuff happening. From low fuel, heat damage, interdictions, under attack to the ominous 'IsInDanger' and many others
Heat Warn: Red Blinking: >100% Heat. I'd love to have a yellow and red alarm, but I don't think thats in the files
Fuel Dislplay: Displays Fuel as number/maxnumber as well as a bar-graph (I thought about an analog fuel gauge, but that might be a bit too retro)
Fuel Warn: Yellow/Red/Red Blinking: Shows fuel level below 25/10/5%
System Display: Shows system name and star class
Cargo Display: Shows amount of cargo on board, as well as either unloaded or loaded cargo in this system (-->see 'Cargo Mode')
Test: Lights up everything, very festive
Scoop Adv(isor): Lights up the -->'Fuel Scoop' light if in super cruise around a scoopable star
Reset: Hard Resets the board. Once everything is done, will be switched to 'reset alarms' (stop blinking, dammit)
Load Mode: Switches the -->Cargo Display between loaded and unloaded cargo
Dim LCD/LED: Dimms the LCDs and LEds
Silent Running: Blinking Red/Blue:Silent Running
Weapons: Red: Hardpoints deployed
Group: Weapon Group
Cargo Hatch: Yellow: Take a guess
Landing Gear: Yellow: Landing gear
Fuel Scoop: Green/Green blinking: Lights up green in super cruise around a scoopable star if -->'ScoopAdv' is on, blinks green during scooping
FSD Inhib(ited): Yellow: Masslock/Cooldown
Light: Green: Lights on
FSD: Green/Blue: Green if available; Blue if running; Blinking Blue/green if charging
Night Vision: Green: What do you think?
Permit Warn: Yellow Blink: Light up after entering the no fire zone until a landing permit has been granted (or until fsd is engaged again). Keeps me from forgetting to ask for a permit

I'll post some technical details later

 

[SpaceTerp]

This is awesome thanks for sharing. And yes please, upload the code.

 

[Robert Maynard]

Very nicely done!

 

[Hossi]

As promised, here are some technicalities for those who are intersted.

There are two sets of code running the whole thing.
First there is the parser that runs on my PC, that compiles a status-string and sends it out via com-interface.
The second runs on the arduino and send the signals out to the leds and display.

The first one does all the heavy lifting. The reason is pretty obvious: My PC runs a i7-9700k with 32GB of ram. The Arduino has a single 8-bit processor and whopping 256KB of ram (thats more than the first computer that I played elite with).

The 'StatusReport_V4.ahk' is AHK code. AHK (AutoHotKey) is free scripting languange thats surprisingly powerfull and flexible. A bit like phyton, but has the option to compile the code with a single mouseclick to a standalone executable. (I had to rename it to a .txt to attach it to this post)

The StatusReport_V4 checks the journal and the status.json asynchronuos. The json every 200ms, the journal every 1000ms. I've build a generic 'SearchFor' structure that defines what the parser is looking for and when to stop. It looks something like that


SearchForArray[11,1]:="FSDJump"
SearchForTagArray[11,1]:="StarSystem"
SearchForArray[11,2]:="Location"
SearchForTagArray[11,2]:="StarSystem"
SearchForArray[11,3]:="SupercruiseEntry"
SearchForTagArray[11,3]:="StarSystem"
SearchLengthArray[11]:=1000
SearchSuccessArray[11]:=0
KeepOldValues[11]:=1
FoundValuesArray[11]:=0
FoundValuesArrayTemp[11]:=0
FoundTimeArray[11]:=0
DiscardTimeArray[11]:=0
SumSinceSystemEntryArray[11]:=0
SearchForType[11]:=0

Look for the event "FSDJump", "Location" or "SupercruiseEntry". If found, log the "StarSystem" value, as well as the timestamp of that happening. Dont sum up the value. Don't delete it after a while. Don't look further than 1000 lines. If you haven't found something, keep the old value.

Every 200ms the findings run through a 'PostProcessing' function that compiles the raw findings into the output singnals that can be directly set to the leds/display.

For example, this one here controls the PermitWarn (0 - off; 1 - on)

if (LastFoundArray[12]>1) && (LastFoundArray[11]>1)
{
    dTime1    :=LastFoundArray[12]
    t2        :=LastFoundArray[13]
    EnvSub, dTime1, %t2% , Seconds

    dTime2    :=LastFoundArray[11]
    t2        :=LastFoundArray[13]
    EnvSub, dTime2, %t2% , Seconds

    dTime3    :=LastFoundArray[11]
    t2        :=LastFoundArray[12]
    EnvSub, dTime3, %t2% , Seconds
    if (dTime1>0) && (dTime3<0)
    {
        PermitWarn:=1
    }
    else
    {
        PermitWarn:=0
    }
}
else
{
PermitWarn:=0
}

11 is a jump (see above), 12 is "$STATION_NoFireZone_entered", 13 is "$STATION_docking_granted"
So: If I did a jump and recieved a "NoFireZone_entered" message, check if there was either a "docking_granted" message after the "NoFireZone_entered" or another fsd-jump

Finaly, the whole thing is assembled to a string that looks something like that

58;64;Kamadhenu;K;1;0;1;0;0;0;0;0;0;0;0;698;0;0;1;0;

That string is now compared to the last string that I've send out to USB, and if its different (or its been more than 15 seconds) its written out. The usb port currently has to be defined manually, its port 6 for me.

 

[Hossi]

The Arduino code is pretty straight forward.

Thats my first Arduino project ever, so I'm sure I could have made it a bit more elegant. But keep in mind that this one is not written to look nice, or be easy to maintain, its written to be easy on the limited system recources.

Basically, all the thing does is:
-Wait for something coming over at the com-interface
-Cut it up at every semicolon
-Assign it to the matching variables
-Go through all diplay elements and see if the value we just recieved is different from the last value we set there (that prevents flickering)
-If so, set the value to the Led, the 2x16 LCD, or the 7-Seg Display
-Remember the new value

There ar some more small sections for
-Blinking
-Buttons (System Test (light everything up), Cargo Display and the Scoop Advisor)
-Dimming (read analog value fropm one port, calculate pwm value and set it out to a different port)


Now you just have to wire everything together like shown here:

 

[Hossi]

I've got a few new features, and I didn't even have to add a single cable. Just software upgrades.
There is now a difference between 'travel mode' and 'docking mode'. Travel is default, docking is activated when you get a docking permit and lasts till the next jump.
In travel mode, the number of jumps remaining on route is now displayed beside the star class. Thats one of these features that sound simple but somehow aren't. FD added the 'jumps remaining' info to the journal with the september update, but they added it to the 'FSDTarget' event, that is triggered when the route progress one jump. Thats means you will never ever see a 'JumpsRemaining=0', the last jump has no 'FSDTarget'. Jumps remaining=0 can instead be detected by the order of the jump events.
A routed jump has
-StartJump
-FSDTarget
-FSDJump

A non-routed jump has just
-StartJump
-FSDJump
So if the StartJump was after the last FSDTarget it was the last jump.

In docking mode the assigned landing pad number is displayed instead of the starclass (I don't think thats a relevant information at this time) as well a a 5-digit bar graph telling how deep inside the station the landing pad is. This way I know when I need to decelerate so that I don't overshoot inside the docking barrel. Of course that is only active for Coriolis, Occelus, Orbis and Bernal starports.