LightSail-2 is now identified as 44420 and it is change to DB and Network.
One more observation with one of the TBEx which fits one of 44359, 44360, 44361. It looks like there is a drift (~4KHz) in frequency. @jwc Do you have any update on your side about TBEx-A or TBEx-B?
I’m back in the lab and ground station now and able to track directly. No updates on TBEX-A or B. Our last decoded packets were from 30 June. All looked healthy. We were able to uplink to the B as well.
Right now, we think we’re kernel panicking based on ground testing. Our theory is that every ~ 48 hours we reboot and work for a bit, then crash.
We could definitely use some help trying to figure out the ~48 hour reboot and when we’ll be on. If we can uplink during that short window, we might be able to fix the code that is crashing.
We’re also working to stop MC2 and GRIFEX from beaconing so that we can quiet the band.
As per this thread: Observation 832478: TBEX-A (99965)
I’ve changed TBEx-B to be object 44359. And also I’ve changed TBEx-A to follow 44360, (if there is any other suggestion let me know).
@jwc please if you have available the UTC times of when you heard TBEx-A in the past may help us (by checking SatNOGS observations) to find out its norad id.
Will do on the TBEX-A observation we have. Trying to coax a student to do it first. 
Yes, you are right… I got carried away from checking waterfalls and TLEs, as it was the object with the closest orbit to 44359. So I changed TBEx-A to follow OBJECT 44361.
Being late to the ID party for this launch I give only PSAT-2 a try.
Analyzed observations (838575, 838563), 838584, 838585, 838588, 845205 with the new waterfall tabulation helper and STRF.
Result:
| id | desig | center freq / MHz | rms / kHz |
|---|---|---|---|
| 44348 | 2019-036K | 435.347 | 8.10 |
| 44354 | 2019-036R | 435.358 | 1.76 |
| 44355 | 2019-036S | 435.359 | 2.07 |
| 44357 | 2019-036U | 435.364 | 7.43 |
So, currently 44354 matches the SSTV observations from PSAT-2 best (followed by 44355).
Note that all fits show rather large residues for my taste (but I don’t have much experience with this manual tabulation method yet, so this might be expected / I didn’t do any error propagation).
update:
I’ve repeated the analysis, this time using five AFSK1k2 observations since this transmitter drifts less compared to the SSTV one (thanks @vk5qi and @fredy for pointing this out to me!). With 0.354 / 0.440 kHz for 44354/44355 the resulting residues are indeed smaller.
@jwc Jamie,
I am running into several problems implementing a satnogs-decoder for TBEX telemetry.
I also know that people usually are very busy in that times 
Could you help me out with some details?
It looks like there is some “offset” in the first few bytes, because the timestamps are not “identical” for beacon_1 and beacon_2. The first bytes after the ax.25 header seem to be 0xab 0xcd which seems to be invalid for a timestamp or a mode indication.
Maybe you have added something like a “big/little endian” determination?
Second part is: did you possibly mix up source and destination callsign? I am getting KF6RFX as the source callsign from TBEX-B, which seems to be your personal callsign!?
Looks like you are using a specific “framing” inside the AX.25 UI payload! Could you please give me a hint which specific one this is? CCSDS Transfer Frame? CSP (Cubesat Space Protocol)? Something totally different?
Best regards,
Patrick
Hi, thanks for taking the time to create a decoder!
Yes, the callsigns are off. The radios weren’t configured as we wanted. We can change the call signs later once pass elevations are high again in the north. And yes, KF6RFX is my call sign and KD8SPS is student alum.
The beacon format is described here. I’ll edit this later when I can chance to describe the 0xab 0xcd packet structure we’re using.
@DL4PD here is the description of the 11 byte header with length specified in bytes:
For MXL, our SIDs are 0x0000. TBEx PIDs are 0x0052 and 0x0053 for TBEX A and B respectively. A flag value of 0x03 indicates a beacon.
Yes, I have added a decoder using the description, but there is a header infront of what you call “Offset 0”, or, for beacon_1 before “Operation Mode”, of 11 bytes as far as I can assume! The structure is looking something like this:
[ax.25 header:16][unknown header:11][TBEX beacon payload][crc:4]
It would be very nice if you could point to a description for the “unknown” header. 
OK, got it! Thanks for that!
It seems the endianess is flipped between header and payload! I that correct?
I am getting values of 0x03 and 0x04 for beacon_1 and beacon_2 respectively.
A quick update with the latest results:
TBEx-A is 44356
TBEx-B is 44359
PSAT-2 is 44354
OCULUS-ASR is NOT 44356… I’ve changed it to 44346 as it looks like a good candidate given the order of deployments and the orbital data from TLE.
One more update for today…
BRICSat-2 (USNAP1) is 44355
Confirmed from this observation where both PSAT-2 (signal following curved line) and BRICSat-2 (signal following straight line) are visible and decodable:
SpaceX now collaborates with Nasa and they are allowed to reuse the rockets.