Regarding a new NanoFF A & B update I will just forward you the message from our project lead.
Dear project partners, supporters, and space enthusiasts,
We have more positive news from the NanoFF project: The launch provider will command the separation of NanoFF A on Monday morning, January 15, 2024, at 05:36 UTC (approximately over the South Pole). This means we expect the following contact times for Berlin:
Contact Attempt 1 (Elevation 11°): starting around 08:05 UTC / 09:05 AM CET (local time)
Contact Attempt 2 (Elevation 87°): starting around 09:32 UTC / 10:32 AM CET (local time)
The first contact can be followed live via the following Zoom link. The meeting will open around 07:50 UTC, where we will provide some brief information on the current operational status of NanoFF B and the procedure for the first contact of NanoFF A. The pass will start afterward. Due to the high workload of the team, the pass might not be live-commented, but a summary will be given by the operations engineer afterward, and questions will be answered.
Note: During the first attempt, it is possible that contact cannot be established due to the low elevation. Therefore, the second attempt with a higher elevation of 87° will take place at 09:32 UTC and will also be broadcast if the first attempt is not immediately successful.
Finally, here are some positive updates on the current mission status of NanoFF B:
Successful first contact on January 10, 2024, around 08:10 UTC
Nominal system behavior observed
Successful commissioning of the most important subsystems
Successful GNSS data acquisition on January 11, 2024 (2nd day of operation)
Successful detumbling (DTMb) on January 11, 2024 (2nd day of operation)
Successful constant spinning test with all 4 reaction wheels (2°/s on X-axis, other 0°/s)
Currently: Conducting further planned tests and commissioning the AOCS system
That’s the good news so far. We are now looking forward to the separation of the sibling satellite on Monday morning together with NanoFF B and eagerly await the first contact.
Best regards and have a pleasant evening,
Your NanoFF Team
D-Orbit confirmed they haven’t deployed NanoFF A yet. Therefore, no signals in all SatNOGS observations. Backup separation currently planned for the evening/night contacts but could also be rescheduled. We’ll let you know.
Yes, we’ve waited for 2 or three beacons and then switched it off following the procedure. I guess there might be a some SatNOGS recordings of this. We’re going to start the vetting of those soon.
The document doesn’t describe the payload part of the frame (48 bytes between the TTC and HAM MESSAGE parts). Is that intended ?
In the document bytes to transmit is described as 4 bytes unsigned integer in big endian. But this give me weird values : big endian : 4172939264 (i also tested little endian : 279368). it could works with some rounded values or something, but it is not in the doc, so i just wanted to know if is that correct ?
First, it is intended that the decoding of the payload is not described. As this data doesn’t belong to us, we cannot provide any information about it.
I know their is some conversion that are not correct, which parameter is it ?
Thanks for the website. I just tested it on a frame i use to test 8C689694B040E08CB06C8CA486E103F08C10BEC6A066AFC6A06605000455F8BA00009900B29155C700C5C8C71766000E0D39007B2815FD1306FEFDCA64C973D19356090102C8118F01775100141D9CBE6646007D1D1D02004B004DBF0029001B010B0030003100068A0202020700C0FED0FE98E924FFFF0013000C000000000000000000000020524F42314520454E534F202D204353554D202D20455850
All good for “obdh_nb_bytes_to_transmit”. But comparing the value, now i m asking for “obdh_last_temp”, i m supposed to have 0.3125 but i have 1280, some magic math to apply ? (the doc say only 4 bytes big endian, nothing else)
After that i will push the decoder
Oh and a last question, just for me to know, there are also some smaller frames like 8C689694B040E08CB06C8CA486E103F0050BEA499A6611 . It’s valide AX25 with the ENSO callsigns but it contains a very small amount of data (5 bytes), any idea of what it is ? (the website doesn’t decode it).
Hmmm there is still something wrond. I have a frame 8C689694B040E08CB06C8CA486E103F08C10E123A666D923A666F21F0455F8E70200A300FA9155C7FDC5C7C71566FE0E0D3900832A1605FA13FD01CA64C972D19156090102C81193017700008D069CBE99460000001D0200570059BF002E0026010B003000360006900202020700D4FEBCFED0EA23000300180007000000000000000000000020524F42314520454E534F202D204353554D202D20455850
In this frame the obdh_last_temp is 8178. Regarding your decoder here i’m supposed to get -0.875.
Regarding the picture you gave me, since the value is greater than 4095, i m supposed to consider it as signed and than multiply by 0.0625, but doing this give me 511.125 so this :
signed 8178 * 0.0625 i get 511.125
And if i still consider it signed and than do :
(signed 8178 + 57344) * 0.0625 i get 4095.125
Also it is supposed to be negative at the end but it is not.
So there is something i don’t get correctly here ^^
Also i have spotted an error in the document about :
Measured Transmission Power (ttc power fw): It’s described as a 2 bytes unsigned integer.
But actually it is : 1 bytes unsigned integer and there is another value which is ttc power rev of type unsigned integer of size 1 byte. And both have to be multiply by 10.
The ttc power rev field is missing in the document.
If I convert the 8178 back to hex I get: 0x1FF2. This leads to the assumption that we have a 13 bit value, which is to be interpreted as signed. I would convert to decimals: 8178-2^13=-14. Then -14*0.0625 = - 0.875.
The problem is that you probably can’t declare a signed 13 bit integer
Backup separation currently planned for the evening/night contacts but could also be rescheduled. We’ll let you know.
so this :