435.45MHz. Sorry, fixed in original posting as well now - the document I copied and pasted had an error.
Andrus.
435.45MHz. Sorry, fixed in original posting as well now - the document I copied and pasted had an error.
Andrus.
Got this from NORAD today:
ā¦
We are still in the process of getting enough tracking data to determine orbits for all of the objects on the launch. 25 have been catalogued so far, but there are more still in work. Youāll notice theyāre all just named OBJECT A, OBJECT B, and so on right now. We need to have the satellite owners tell us which is which, but we expect it to take a few days for each of the satellites to get far enough away from each other for you to be able to tell the the TLEs apart.
ā¦
Andrus.
Yes, this is a classic process when many satellites are deployed together. It helps a lot when the whole group transmits, as the most calculations are based on these transmissions. In cases of many satellites not transmitting, these can stay unidentified forever.
Except the satellite teams, especially for satellites in amateur bands, there are people that help identifying objects. For example check this twitter thread.
In SatNOGS we can also help on identifying, but currently we have less precision on our calculations than when other tools used, this means that we need more time for the satellites to separate.
Of course the whole identifying process is a shared effort, so we use, cross examine and confirm our results with other results and end up to the right NORAD IDs.
Beautiful!
Thanks for this detailed description! A lot of work to implement a decoder for thisā¦
Awesome!
Thanks for this!
Edit: Could you please describe the command header?
Of course ā¦
Added it to original posting as well, but the header is:
4 bits sending module, 0=groundstation
4 bits intended receiver module, 0=groundstation
8 bits command sequence #
16 bits command, little endian number. 4 highest bits are flags
bit15 - response bit (the packet is response to command)
bit14 - error bit (the command produced error)
Good morning guys,
finally we had time to activate the CW beacon. We could hear it loud and clearly
It will be broadcasted for the next two hours in an interval of 30 seconds.
Would be nice if you could schedule some passes (around the globe) so we can do some more doppler studies.
tom
From a quick look, we can also hear it loud and clear!
https://network.satnogs.org/observations/810654/
Iāve scheduled a couple of observations too for the next 2 hours.
Yes, and in observation https://network.satnogs.org/observations/811104/ data 2 āENDDP0SNā look almost like SONATE callsign DP0SNT
It looks like you are always defaulting to āINTā for a type, but this seems incorrect for a lot of them: The flags are bool and I would like to guess that your data is transmitted āunsignedā!
Can you please confirm or decline, maybe clarify this?
Do you have trouble decoding your telemetry starting at, letās say, byte nr. 221?
Does your CCSDS Space Packet header tell you there are 240 bytes in the payload for APID=100?
Two updates from us:
We switched to use Object N with our main ground station for MOVE-IIb. Object Q seems to fit for SONATE, while MOVE-IIb is slightly off (see attached Screenshot of Object Q generated from pass SatNOGS Network - Observation 808690). Maybe one can confirm this guess and we may also switch on SatNOGS?
Also we recognised, that SONATE is using exactly the same frequency as MOVE-IIb in VHF (145.840 MHz, so donāt be confused. As the satellites are still close to each other, both may appear together in one observation. MOVE-IIb sends a repetitive pattern of short beeps and longer CWs in a 20s interval, while SONATE seems to send CW only so far. Also SONATEās signal is way stronger. We donāt understand why coordination did fail here, but weāll arrange with it
To give you an example: SatNOGS Network - Observation 808691 (SONATE starts to send itās CW at 380s during a MOVE-IIb observation)
Hey @DL4PD,
thanks for your feedback and interest. Iāll answer your questions in a batch:
1.) Yes, we default to unsigned integer. Of course, you can interpret the one-bit-long fields as booleans, but note that not all of them are directly linked semantically to āTRUEā or āFALSEā but to the given calibration.
2.) According to the CCSDS standard the field in the header holds the actual length - 1, i.e. the source packet length for APID100 is 241.
3.) The fields you mention (ARSERR and ARSE01 to ARSE12) are a special case. The fields of ARSE01 to ARSE12 (Byte 221 bit 5 through 7) are multiplexed. Depending on the main error code ARSERR (Byte 221 bit 0 through 4) the values in Byte 221 Bits 5 through 8 have a different meaning. It was more convenient for our encoder/decoder to define it like that. Iād suggest you treat the whole Byte 221 as one uint8 field (as defined as ARSECO) and do the multiplexing āmanuallyā in the calibration rules.
Hope this clearifies your questions and weāll improve the document on our website regarding them asap.
I hope youāll understand that weāll do our best to answer your (further) questions as soon and detailed as possible, but that during the busy times of LEOP operations itās not our top priority - so please excuse possible delays
cheers,
tom
Yeah, ok! Thanks for the quick reply - totally understanding your higher priorities currently
1:.) Maybe you could default to āUINTā instead of āINTā in the document then!?
2.) Indeed - the Data Lenght should be counted minus 1! Must have overseen thisā¦
3.) This clarifies a lot! Thanks for that!
Iāve changed it also in network, so now MOVE-IIb follows 44398. I can confirm that it looks like that this is the best fitted NORAD ID in the good observations we have in network.
It is indeed unfortunate, fortunately the two satellites already have a good distance between them in order to be able to separate them from the curves in waterfall.
We recognized that the network is using NORAD-ID 44401 (Object R) for observations of SONATE. We are currently using NORAD-ID 44400 (Object Q) for our tracking, but we are still trying to pinpoint SONATE better.
Object R seems to be too early, resulting in a bad doppler-shift correction.
Greetings from the SONATE-Team
Tom (not the orange one)
By using ikhnos indeed 44400 has a better fit that 44401. Maybe 44399 is also in the lottery for SONATE. Iāve changed SONATE to follow 44400 in network.
https://amsat.org/pipermail/amsat-bb/2019-July/074018.html
JAISAT is now object F with the following information from AMSAT-bb
2019-038F
1 44419U 19038F 19190.66730395 .00001667 00000-0 10000-3 0 9996
2 44419 97.4914 152.5407 0020014 233.1737 126.7422 15.12176922 634
The JAISAT-1 Beacon signal on 435.700 MHz in GMSK Mobitex 4800 bps mode
code for JAISAT-1 frames 1 in row 11
41 (0x29) - JAISAT UHF1
42 (0x2A) - JAISAT UHF2
Iāve changed JAISAT-1 to follow OBJECT F (44419) in network.
Did some TLE analysis on current files - please find below.
It is just an attempt to make sense of current tracking data and launch information available, so by no means is this a request to update the entire tracking information. But may be it becomes handy to some.
Assumptions made (based on the launch data what we have - sorry, the doc is confidential):
As the cluster #2 had 30 satellites total and we have tracking vectors from NORAD for 22 objects on this orbit, that fits the math nicely (30-4beesats-4double3Ulaunches).
Please note, that this is just a crude attempt to match together the launch order, satellite sizes and current TLE and is by no means a suggestion for changing a tracking setups. It also does not fit for three of the LEMURās already claimed at NORAD.
Anyway. The launch sequence (time from lift-off and time from go-inertial, in seconds) for satellites at cluster #2 was as following:
Scrolling A LOT back and forth in Orbitron, trying to see what flies together with what, at which speed etc., the best fit was like the one below. Once again - it is just a theory:
(Updated 07-15-2019 10:24UTC)
OBJECT G (L2-24[3U])
1 44392U 19038G 19194.83629255 .00000340 00000-0 23392-4 0 9997
2 44392 97.4899 156.6272 0020436 219.9684 140.0059 15.12180966 1068
OBJECT H (L2-23[3U])
1 44393U 19038H 19194.83690227 +.00000430 +00000-0 +28641-4 0 9997
2 44393 097.4887 156.6250 0020827 219.7302 140.2406 15.12071975001260
OBJECT J (SOKRAT[3U])
1 44394U 19038J 19194.96967333 +.00000426 +00000-0 +28512-4 0 9999
2 44394 097.4896 156.7555 0020815 219.3866 140.5853 15.11997981001282
OBJECT K (MOMENTUS[16U])
1 44395U 19038K 19194.11125698 .00005760 00000-0 34059-3 0 9995
2 44395 97.4933 155.9226 0022366 211.7858 148.1977 15.11644218 1149
LEMUR 2 LILLYJO (AMGU-1[3U])
1 44396U 19038L 19194.97089496 +.00001023 +00000-0 +63366-4 0 9997
2 44396 097.4872 156.7572 0023640 214.2877 145.6830 15.11787978001275
OBJECT M (CARBONIX[M])
1 44397U 19038M 19194.97245866 +.00000444 +00000-0 +29884-4 0 9996
2 44397 097.4890 156.7529 0024460 213.2298 146.7398 15.11506789001286
OBJECT N (DOT-1[M])
1 44398U 19038N 19194.90593227 +.00000655 +00000-0 +42220-4 0 9990
2 44398 097.4881 156.6935 0024155 215.5595 144.4030 15.11566116001270
OBJECT P (JAISAT[3U])
1 44399U 19038P 19194.97192916 +.00000269 +00000-0 +19551-4 0 9990
2 44399 097.4895 156.7539 0023540 218.9655 140.9883 15.11597076001285
OBJECT Q (VDNH-80[3U]+UTE EQUADOR[3U])
1 44400U 19038Q 19194.90561804 -.00000040 +00000-0 +14690-5 0 9990
2 44400 097.4893 156.6904 0024128 213.9120 146.0570 15.11616753001279
OBJECT R (AMICAL[2U])
1 44401U 19038R 19194.90512185 +.00000391 +00000-0 +26604-4 0 9994
2 44401 097.4886 156.6892 0023978 213.1734 146.7996 15.11708845001276
LEMUR 2 WANLI (LIGHTSAT[3U])
1 44402U 19038S 19194.90500929 +.00000998 +00000-0 +61989-4 0 9996
2 44402 097.4854 156.6907 0023725 215.1404 144.8264 15.11733617001277
LEMUR 2 MORAG (TTU101[1U])
1 44403U 19038T 19194.97119565 +.00000903 +00000-0 +56494-4 0 9997
2 44403 097.4900 156.7486 0022443 218.7638 141.2005 15.11732926001284
LEMUR 2 YNDRD (L2-28[3U]+SONATE[3U])
1 44404U 19038U 19194.90456334 +.00000425 +00000-0 +28575-4 0 9997
2 44404 097.4878 156.6873 0021360 220.1738 139.7916 15.11807166001274
LEMUR 2 EJATTA (EXOCONNECT[3U])
1 44405U 19038V 19194.83828406 .00001461 00000-0 88787-4 0 9995
2 44405 97.4868 156.6255 0023130 215.5701 144.3987 15.11832598 1269
LEMUR 2 DUSTINTHEWIND (MOVEIIB[1U])
1 44406U 19038W 19194.83840392 .00000216 00000-0 16397-4 0 9999
2 44406 97.4895 156.6259 0023493 213.5532 146.4224 15.11801835 1252
LEMUR 2 ALEX-MADDY (L2-27[3U])
1 44407U 19038X 19194.90483351 .00000812 00000-0 51158-4 0 9992
2 44407 97.4894 156.6824 0022363 218.7864 141.1763 15.11762527 1265
OBJECT Y (LUCKY-7[1U])
1 44408U 19038Y 19194.90432420 -.00000031 00000-0 19927-5 0 9997
2 44408 97.4883 156.6821 0022170 218.9088 141.0929 15.11847573 1276
OBJECT Z (L2-29[3U]+L2-22[3U])
1 44409U 19038Z 19194.83791669 +.00001004 +00000-0 +62087-4 0 9997
2 44409 097.4858 156.6272 0023400 214.6928 145.2781 15.11895659001261
OBJECT AA (BEESAT-9[1U])
1 44410U 19038AA 19194.90408591 +.00000550 +00000-0 +35754-4 0 9992
2 44410 097.4887 156.6902 0021191 219.3146 140.6552 15.11893367001274
LEMUR 2 GREGROBINSON (L2-26[3U]+SEAM-2.0[3U])
1 44411U 19038AB 19194.83920318 +.00000931 +00000-0 +58233-4 0 9991
2 44411 097.4912 156.6199 0022618 219.5165 140.4421 15.11662509000937
OBJECT AC (MTCUBE[1U])
1 44412U 19038AC 19194.90492598 .00000382 00000-0 26073-4 0 9991
2 44412 97.4884 156.6877 0021851 219.0534 140.9120 15.11742195 966
OBJECT F (L2-25[3U])
1 44419U 19038F 19194.96830349 +.00000406 +00000-0 +27178-4 0 9998
2 44419 097.4899 156.7586 0020486 218.9421 141.0342 15.12240390001288
Regards,
Andrus.