diff --git a/README.md b/README.md
index 97e0709..b8a23d7 100644
--- a/README.md
+++ b/README.md
@@ -10,6 +10,7 @@
 - [comms/phasors-to-stun](comms/phasors-to-stun)
 - [ground-segment/can-you-hear-me-now](ground-segment/can-you-hear-me-now)
 - [ground-segment/i-see-what-you-did-there](ground-segment/i-see-what-you-did-there)
+- [ground-segment/talk-to-me-goose](ground-segment/talk-to-me-goose)
 - [payload/calendar](payload/calendar)
 - [payload/leakycrypto](payload/leakycrypto)
 - [satellite-bus/bytes-away](satellite-bus/bytes-away)
diff --git a/ground-segment/talk-to-me-goose/README.md b/ground-segment/talk-to-me-goose/README.md
index 1f37f38..fa64a90 100644
--- a/ground-segment/talk-to-me-goose/README.md
+++ b/ground-segment/talk-to-me-goose/README.md
@@ -13,13 +13,11 @@ by [erin (`barzamin`)](https://imer.in).
 
 Inside `LaunchDotCom_Carnac_2.zip` is a documentation PDF describing the "satellite" we're connecting to. One of the interesting things it notes is that "LaunchDotCom recommends Ball Aerospace’s COSMOS suite of software for command and telemetry processing with the Carnac 2.0."; we already set this up for the _That's not on my calendar_ challenge (written up by `haskal` in this report).
 
-We're given an XTCE file inside `cmd_telemetry_defs.zip`, `cmd_telemetry_defs.xtce`, which describes the command/telemetry protocol to the satellite. COSMOS can [load an XTCE definition](https://cosmosrb.com/docs/xtce/) into a COSMOS configuration, so we just generated a new COSMOS configuration tree and imported `cmd_telemetry_defs.xtce`. Out of the box, this won't identify packets properly for some reason; we had to add a file `$COSMOS_CONFIG_DIR/config/targets/CHALLENGE1/target.txt` containing
-```
-TLM_UNIQUE_ID_MODE
-```
-to make COSMOS fall back to a non-hash-based packet ID mode for the imported XTCE `CHALLENGE` target to work.
+We're given an XTCE file inside `cmd_telemetry_defs.zip`, `cmd_telemetry_defs.xtce`, which describes the command/telemetry protocol to the satellite. COSMOS can [load an XTCE definition](https://cosmosrb.com/docs/xtce/) into a COSMOS configuration, so we just generated a new COSMOS configuration tree and imported `cmd_telemetry_defs.xtce`. Out of the box, this won't identify packets properly for some reason.
 
-We also had to write an [interface config](https://cosmosrb.com/docs/interfaces/) for COSMOS in `$COSMOS_CONFIG_DIR/config/tools/cmd_tlm_server/cmd_tlm_server.txt` so it could connect to the TCP-tunneled-CCSDS telemetry port the challenge gives us after a ticket; ours was of the form
+To fix this, we created a config `$COSMOS/config/targets/CHALLENGE1/target.txt` containing `TLM_UNIQUE_ID_MODE` to make COSMOS fall back to a non-hash-based packet ID mode for the imported XTCE `CHALLENGE` target to work.
+
+We also had to write an [interface config](https://cosmosrb.com/docs/interfaces/) for COSMOS so it could connect to the TCP-tunneled-CCSDS telemetry port the challenge gives us after a ticket; ours was of the form
 ```
 TITLE 'COSMOS Command and Telemetry Server'
 # 10 nil: read, write timeouts
@@ -29,18 +27,18 @@ TITLE 'COSMOS Command and Telemetry Server'
 #   7:  length value offset (true # bytes read is length + this)
 #   1:  1 byte per count in length field
 #   BIG_ENDIAN: endianness *of length field*
-INTERFACE LOCAL_CFS_INT tcpip_client_interface.rb {ip} {port} {port} 10    nil    LENGTH 32 16 7 1 BIG_ENDIAN
+INTERFACE LOCAL_CFS_INT tcpip_client_interface.rb {ip} {port} {port} 10 nil LENGTH 32 16 7 1 BIG_ENDIAN
   TARGET CHALLENGE1
   TARGET SYSTEM
 ```
 
-and was generated by a script which connected to the challenge, passed the token, and templated/wrote out this interface config file. We ran COSMOS in the Docker container detailed in _That's not on my calendar_.
+and was generated by a script which connected to the challenge, passed the token, and templated/wrote out this interface config file to `$COSMOS_CONFIG_DIR/config/tools/cmd_tlm_server/cmd_tlm_server.txt`. We ran COSMOS in the Docker container detailed in _That's not on my calendar_ (I'm so sorry for the lack of themes in the docker container; everything looks like Win95).
 
-Connect with COSMOS: [hacker voice im in]
+Connect with COSMOS [hacker voice im in]:
 
 ![COSMOS CMD/TLM server connected](goose-im-in.png)
 
-All the packets we're getting are `EPS PACKET`s indicating undervoltage:
+Almost the packets we're getting are `EPS PACKET`s indicating undervoltage:
 
 ![COSMOS showing that the goose is hungry](goose-hongy.png)
 
@@ -53,20 +51,21 @@ And then all we have to do is send an `ENABLEPAYLOAD` command:
 ![COSMOS displaying command sender for ENABLEPAYLOAD`](goose-enablepayload.png)
 
 The goose is now happy and `FLAG_PWR` is on!
+
 ![COSMOS showing a happy goose](goose-happy.png)
 
 The flag will come back whenever the flag task's scheduler fires, in a FLAG_PACKET:
 
 ![COSMOS showing we have a FLAG_PACKET](cosmos-havemail.png)
 
-Instead of decoding the packet into fields in COSMOS (that won't show us an ASCII string, just FLAG1, FLAG2, etc integer fields in a list), I copy-pasted the flag packet from COSMOS's hexdump
+Instead of decoding the packet into fields in COSMOS (that won't show us an ASCII string, just FLAG1, FLAG2, etc integer fields in a list), I copy-pasted the flag packet from COSMOS's hexdump:
+
 ![COSMOS displaying FLAG_PACKET](cosmos-hexdump.png)
 
 And threw together a quick script to decode by inspection of the XTCE file's defintion of the flag layout (basically identical to _Can you hear me now?_):
 ```{.python}
 from bitstring import Bits, BitArray, ConstBitStream
 
-# b = BitArray(open('./data', 'rb'))
 b = ConstBitStream('THE_HEX_HERE')
 packetlocs = list(b.findall('0x0066'))
 print(f"found packets:  {packetlocs}")