I see the three new CubeSats BHUTAN-1, MAYA-1, and UiTMSat-1 are in the db with temporary NORAD IDs along with their transmitters (they all use 437.375MHz CW). However, I can’t schedule observations for them yet as they don’t seem to have TLE entered. I presume they will start with the ISS TLE.
Their deployment is scheduled for August 10, 2018 at around 09:45 UTC according to http://birds2.birds-project.com/2018/08/09/live-broadcast-of-the-deployment/
Your are right, there wasn’t tle for those, I’ve just added ISS ones. So from now on you can schedule observations. I suggest scheduling starting from 9:45UTC tomorrow/ We are expecting they start transmit around 10:15UTC.
OK, great. I have scheduled a bunch of observations, spreading them around all 3 cubesats, starting at 09:59 UTC. Since they all use the same frequency, taking turns every 120 seconds, I guess each observation will record all three, and then we can tell which one is which by the callsign in the CW (JG6YKL for BHUTAN-1, JG6YKM for MAYA-1, and JG6YKN for UiTMSat-1),
Will the CW telemetry automatically be decoded, or will we need to do this manually?
Scheduling this made me remember a question I have had in the past: is it possible to set the default transmitter for a satellite? In this case, the default was APRS so I had to change them all to CW before scheduling. For the Fox series satellites, the default isn’t the DUV telemetry transmitter, which is the one we should always use, even if we just want to hear the FM voice, since it decodes the telemetry. I’ve also had failures with weather satellite observations when the default isn’t the image transmitter but some other one. Is there a way to set a default to make scheduling easier?
Is our db entry for the APRS transmitter correct? It shows the same downlink frequency as the CW transponder. The BIRDS-2 reception report web page lists this:
“Which type of data did you receive? O CW - 437.375 MHz O APRS - 145.825 MHz”
http://birds2.birds-project.com/data-submission/
The IARU allocation says that 145.825 MHz will be used for both transmit and receive on APRS
“The APRS digipeater onboard BIRDS-2 CubeSats will use 145.825 MHz for both receive and transmit.”
http://www.amsatuk.me.uk/iaru/finished_detail.php?serialnum=562
You are right… this was my bad. I’'m fixing this now.
Frequencies fixed! Thanks @KU2Y!
I’ve also change the current and future observations from APRS to CW transmitter in order to keep them in UHF band.
Thanks for fixing that. I’m not sure that APRS is even active yet. I hear very weak CW telemetry at 2 minute intervals on this observation, so it looks like at least one of the cubesats is transmitting:
Looks like new TLE have been issued for these three cubesats 43589, 43590, and 43591. Since they are using the same frequencies, I guess we won’t be able to identify each until they separate in time enough.
The TLEs themselves already differ in predicted time of closest approach (TCA) for the European pass of 12:25UT today by 2 second intervals. Observed Doppler curves from that pass differ by about 1s in TCA. It may be possible to distinguish them after a few more passes over ground station #40 today.
Can you use the 43590 TLE for all three elements instead of the ISS one? That’s the middle one of the three Cubesats, and will allow for CW decoding as all three have already separated from the ISS significantly.
To find about new TLE, I get tweets from:
And then look them up at:
DK3WM has determined the NORAD IDs:
Norad Ids are updated on db. TLE for those sats are updated too, let’s confirm that are correct. 
I’ve heard on Twitter that at least 2 of the 3 cubesats are transmitting on the digipeater so I scheduled some observations. However, I’m not sure any are successful yet. Do you think any of these are Good? There is so much traffic on that part of 2m that it is hard to tell:
https://network.satnogs.org/observations/217453/
https://network.satnogs.org/observations/217450/
https://network.satnogs.org/observations/217451/
https://network.satnogs.org/observations/217444/
https://network.satnogs.org/observations/217442/
Indeed hard to say… maybe decoding from audio, if it is possible, could help.
I tried soundmodem decoding on the audio but got nothing. But I also tried decoding some other AFSK1k2 observations and got nothing from them too, so not conclusive. I guess I’ll schedule a few more observations and see.