I found that SatNOGS client 1.6 was released in 2021, so it predates the aliasing bugfix I was talking about.
I will go over my STRF runs and see if we can find something at 437.010 MHz.
Jan | PE0SAT
@EA4GPZ and @fredy I have not seen any demodulated packets for HUNITY, although the satellite is operational. There are two reasons: the default data rate is now 25kbps, not 12.5kbps. I have edited the transponder to match that.
Wrong sync word is used to find the packets. Can you please comment on how the packets are found in the iq stream? I know, Daniel worked on the SMOG-P and MRC-100 decoder in gr-satellites, and HUNITY uses a very similar GMSK modulation. Can the client be configured so that it demodulates the data properly?
73,
Tibi
Would it be possible to share an IQ recording and signal details so we can try to get a working solution?
Jan | PE0SAT
Can you indicate what are the differences in coding between HUNITY and SMOG-P and MRC-100? I want to figure out what are the changes (if any) that need to be done in gr-satellites to decode HUNITY.
Thank you. In some observations (from 858 - SM0TGU - UHF, 733 - VAUBAN-IEPER ON7XX and most recently from 3282 - ha7dcd and decent.org) we have seen wideband signal ~60 seconds apart which could be 3UCubed-A’s faint beacon.
If it is any help in looking for the data: 3UCubed-A transmits beacons every 60 seconds in ~6 packets of 137 bytes and an interpacket gap of 500 ms at a frequency of 437.01 MHz. Of the 137 bytes, the first 15 bytes are preamble data that can be ignored; starting at the 16th byte is the start of an AX.25 frame ending at the 97th byte.
Hello,
We generated a TLE for Black Kite-1:
BLACK KITE-1
1 98527C 14900A 25334.87353009 .00000000 00000-0 -95230-3 0 03
2 98527 97.4399 46.8487 0000898 95.5753 300.1156 15.17627249 00
The error is probably large as the TLE was generated with few observation points. In any case, could we try loading it for observations to evaluate its performance? Thank you!
Thanks for the TLE. Be careful with the drag value. You have now -95230-3, which is a negative number. This will make the TLE deviate in a few days. Mostly we see values in the range of 30000-3. For the next TLE you may want to set a more normal value before fitting it to your data.
Good luck!
Thanks for your advise! We probably have to regenerate it as the tle does not seem to perform well based on the observations.
Do we just change it to an arbitrary value and run rffit?
@fredy There is some disagreement on the drag models that is causing divergence on the expected spacecraft velocity. Looking to test out an idea using CTC-1C. Please update the TLE to the following and let’s see if it improves the observations. Thank you!
CTC-1C
1 98480U 25276AS 25332.82216433 -.00022598 00000+0 -11210-2 0 02
2 98480 97.4485 44.8340 0000580 252.9749 106.6046 15.17805408 04
Yes, in rffit after fitting the other parameters use c then 7 and set the value to 0.3e-3 which is a “normal” value for drag at this altitutde. Then you can either fit only the B* and get a value near the set one or just leave it with the set value.
Hello,
We generated a TLE for Black Kite-1 again using the suggestions provided in the forum (thanks again EelkeVisser and fredy!).
BLACK-KITE-1
1 98527U 14900A 25336.85313657 .00000000 00000-0 30000-2 0 00
2 98527 97.4399 48.7935 0000673 120.2750 276.8341 15.17552134 08
From the observations on Satnogs, we noticed that the observations were earlier by 2 mins 27 seconds approximately. This implies to us that the previous tle was now ahead of schedule by the same amount.
We tried multiple parameter combinations when running rffit, but the one that worked for us to get a TLE that is behind time is deselecting everything else other than Mean Anomaly. We counterchecked the generated TLE against the current TLE used by Satnogs and the track and timing is on par. We also added the set value to the drag term.
Is this the right process for generating TLE?
I think the drag is 10x to high. It should read 30000-3 in the tle. A decimal point is assumed, and the value to key in in rffit is 0.3e-3. Next check if it still fits your data points.
When you fit one observation then the best is to go by fitting at the same time Ascending Node and Mean Anomaly. When you fit more than one then you can fit also the Mean Motion but you need to make sure that the observations come from the same station, otherwise you may need to do some adjustments to the points.
TLE update for PHI-1:
PHI-1
1 98512U 25337.45939727 .00000000 00000-0 30000-3 0 00
2 98512 97.4399 49.0291 0001303 68.4740 60.6408 15.18833744 07
TLE update for IHI-SAT 2:
IHI-SAT 2
1 98479U 25276C 25337.63381067 .00000000 00000-0 30000-3 0 02
2 98479 97.4471 49.7598 0001858 150.1005 211.1576 15.18335799 01
ihisat2_337_v1.dat (945 Bytes)
sites.txt (11.9 KB)
Updated TLE sets for LILIUM-2 and LILIUM-3:
LILIUM-2
1 98478U 25276N 25335.86847519 .00000000 00000-0 30038-3 0 04
2 98478 97.4409 47.4393 0005650 359.6083 60.0905 15.16071875 02
LILIUM-3
1 98477U 25276AD 25337.45988832 .00000000 00000-0 29886-3 0 03
2 98477 97.4494 49.3741 0001814 183.3387 306.3695 15.18115159 08
sites.txt (11.9 KB)
lilium2_337_v1.dat (945 Bytes)
lilium3_337_v1.dat (1.6 KB)
Hi All,
We have a new TLE from Spacetrack for BLACK-KITE-1, though the original NORADID is a little different from what’s on Satnogs. We modified it to match what’s on Satnogs. Could this be loaded into the observations?
BK-ST
1 98527U 14900A 25336.97972819 .00066568 00000+0 +34008-2 0 0006
2 98527 97.4394 48.9094 0006629 348.7790 11.3294 15.16393925 00064
Thank you!
6GSTARLAB has been listed at SatNOGS DB - 6GSTARLAB (enable Show invalid frequencies) to transmit on 433.895 MHz in the amateur radio band. ITU-API only lists 435-438 MHz without log-in.
IARU Coordination 6GSTARLAB was denied: IARU Sat Coordinator
Is the 433.895 MHz frequency confirmed?
Anything known about 435-438 MHz?
more here: https://arxiv.org/pdf/2503.15101