ISS CubeSat Deployment NRCSD#25 (Nanoracks) - 2023-04-24 12:05 and 12:15 UTC

Welcome and thank you for pointing out to this link.

The information shared via the link is confusing, DTMF is most of the time used to command a device, in this case a satellite, but what kind of data is send by LIGHTCUBE?

My first guess is, that this is some kind of RTTY signal.

Please update the site information so the community can also support the team with decoded data.

Jan - PE0SAT


There are currently two observations of ARKSAT-1 with a signal in each of them, however is difficult to say that this is ARKSAT-1.


Hi Jan-
We’re working on adding details on the decoding. The telemetry is AFSK Bell 103. There seems to be no default mode in SatNogs to work with non 1200 baud AFSK data. We have a flow graph that will do this decoding and would like to integrate it into SatNOGS (Satellite Operator Guide - SatNOGS Wiki) but I am not clear on whether there are development rules for what must be included in a flow graph. Are we permitted to use out-of-tree modules (gr-satellites, specifically?). We have a gr-satellites based flowgraph and a custom, the gr-satellites performs a little better.


Could you share the .GRC file of that flowgraph? Many thanks!

I received on the given satellite frequency LightCube signal which probably resembles bell103. I subjected it to decoding in minimodem and received such a sequence of bytes. Am I on the right way or is it nonsense ?

I spent all evening trying the strongest packets I could find from SatNogs Observations with minimodem, GNU Radio, and anything else I could find. Nothing conclusive, though - need to know what a valid packet should look like.

If the team can share the GNU Radio flowgraph that they’re using, it’ll be a huge help.


New TLE set generated for LightCube based on observations 7462193, 7462920, 7462957 and 7462188.

1 99165U          23115.20000000  .00000000  00000-0  00000-0 0    07
2 99165  51.6414 230.2247 0005920 174.6015 220.5620 15.50201805    07

lightcube-1.dat (2.2 KB)
sites.txt (2.5 KB)

1 Like

A status update:

Temporary NORAD ID Satellite NORAD ID to follow Other NORAD IDs Identified Last Update
99172 NEUDOSE - - NO Received but not heard since 2023-04-24 18:31
99165 LIGHTCUBE - - NO Received, new TLE set is generated
99166 ARKSAT-1 - - NO Not received
99169 AURORASAT - - NO Not received
99167 EX-ALTA 2 - - NO Not received
99168 YUKONSAT - - NO Not received

Zoomed in on NEUDOSE during the U.S. pass just ending here around 1608utc but unfortunately no signals were seen. The pass tomorrow around this same time is even higher, so will certainly keep looking!


Hi @tomasz and @K4KDR
Here’s the github repo with our .grc file (GitHub - ASU-cubesat/lightcube_telemetry: Repository for the downlink of the Amateur LightCube Satellite Telemetry). Apologies, my prior message was not correct in stating that we have a non gr-satellites based version, I use gr-satellites blocks in all versions of our .grc decoders right now. Please note this is a work in progress but should give the correct output data. We’ll add a link to the packet definition soon, it should be included on the LightCube website shortly.


Many thanks for the GRC file!

Here is the link without that trailing period → GitHub - ASU-cubesat/lightcube_telemetry: Repository for the downlink of the Amateur LightCube Satellite Telemetry


Could you kindly let me know if this is a valid LightCube decode? After adjusting your GRC flowgraph to input an audio file, I tested with an extremely strong & clear capture from SatNogs Observation → SatNOGS Network - Observation 7462188

Of course I’ll share the altered GRC if this is a valid decode.

Thank you!


On a really quick look, it looks reasonable to me! The call sign is KJ7TZG and it repeats twice in the header, preceded by a # for the hearbeat packet- in that .grc I use the first iteration of the call sign to sync which is why you only see it once at the start. I see the #callsign repeated a few times so looks like a few packets here? Hopefully we’ll have the packet definition up soon to interpret the other characters.

Thank you so much for the quick reply! I was looping through that ‘good’ packet repeatedly, so it’s no surprise that my output was not exactly correct. Here I replayed the entire .OGG audio file from SatNogs only -1- time through & I believe the decode looks to be formatted more correctly.

I’ll share my GRC file asap. Thank you!

1 Like

Obviously a LOT of room to improve on my modifications, but if anyone would like a GRC file that decodes LightCube with audio files as the input, you’re welcome to →


Also trying to get some decodes after changing the .grc so it can use decoded audio as input.
I need to work on my HEX editor skills, puzzled how to get some human readable output :roll_eyes:

This gave me the below result:

Packet number 12
pdu length =        250 bytes
pdu vector contents = 
0000: a4 e1 5e 26 e6 2e c4 e6 de 94 e1 ae 00 66 06 ae 
0010: eb 0e bf e4 86 20 e0 06 00 68 0e 00 60 06 00 60 
0020: 06 00 60 06 04 66 06 00 68 0e 14 6a f6 00 60 06 
0030: bc e2 9e 00 6b fe c0 60 06 00 7f ff ff ff ff ff 
0040: ff ff ff fd ff ef e7 f7 bf eb ce 60 7f b0 db e1 
0050: f7 03 cc 9b 13 e3 a5 07 e3 86 93 1f 42 f2 40 a5 
0060: 58 20 80 2f 2f 46 6e 20 58 6b 78 0a 30 e1 e1 ac 
0070: 21 d7 19 7c c9 19 ff e5 5d 31 66 30 60 2e 11 0b 
0080: f1 ac 95 18 8b 68 8c 5e c3 f8 03 d5 e2 65 9c d0 
0090: 61 7a b0 f9 d0 ef 41 45 c3 90 08 52 a0 00 8f 89 
00a0: 8b d3 3b 34 49 27 a4 a8 e2 9c 52 3f 69 e9 03 ef 
00b0: 84 1e 87 37 0a 13 30 3d 1d b8 62 a3 b6 48 31 03 
00c0: 07 4c 02 cb 31 96 02 c0 d8 e4 67 a1 ee 86 99 d3 
00d0: 77 a5 00 b0 67 dd c8 18 07 48 80 17 74 ff 4c 25 
00e0: 19 0c 67 a7 6a c6 28 4c 4f e2 56 4f 58 64 05 e9 
00f0: 22 8d c2 4d e7 b5 87 42 45 e7 
1 Like

Hi Jan!

I always output decodes to direwolf just because I like the formatting. Please note that the baud rate in my .CONF file is moot… we’re not decoding with direwolf in this case - only passing already decoded KSS data to it via /tmp/kisstnc (again, just because I like the output format). BEFORE running the GRC flowgraph, direwolf must be started with something like:



And, if anyone would like this flowgraph for -live- UDP audio input from something like GQRX + output to the SatNogs uploader, I’ve added that to another copy (NOT YET TESTED) in this same folder →


Hi Fredy!
I’m a member of the LightCube team that worked on calculating a TLE before deployment using data provided by Nanoracks. I’m pleased to say your TLE that you’ve calculated using observations perfectly matches our predicted TLE exactly when used to predict passes. This confirms that our predicted TLE is accurate. Thanks for the work you put in to calculate this!


Additionally, the packet information has been update at this link Lightcube · IPL