Surely I am still a greenhorn when it comes to IO-117 but I think it is worth to take down some notes. In fact this more a collection of don’ts but from these you will be able to convey how to do it right. The main thing one should know about IO-117 is that this is single-channel satellite and not a linear transponder. That means all stations have to share the medium at the same time. So as more air time one station occupies the less time is available for all other stations (even the DX you may be calling).
A few days ago I was lucky to make QSOs with FJ/FG8OJ, PJ6/FG8OJ, FS/FG8OJ and PJ7/FG8OJ on Greencube IO-117 satellite using packet radio. This was an announced DXpedition to activate some rare grids and DXCCs via satellite. Apparently IO-117 is a single channels half-duplex 1k2 packet radio transponder which means only one station can be active at a time. So it is required to save air time in order to also give others a chance for a QSO. After I made the QSO with FG8OJ I was watching the remainder of the pass and discovered several stations with questionable operating practice. So here is a list to help you improve and maybe also raise your chance for making a QSO with a rare DXCC / grid.
Leave time between your CQ calls
Greencube aka. IO-117 is a medium earth orbit satellite meaning it is moving rather slow (compared to LEO satellites). Thus the footprint also changes rather slowly. This means it does not make sense to call CQ repeatedly in short time frames. The stations receiving will almost certainly be the same.
In this case two stations sent 7 CQ calls within 4 minutes. This is useless as the footprint will have been very much the same within this period. This just steals air time for other users wanting to access the tpx.
Avoid calling stations outside of the footprint
It does not make sense to call stations (with a delay of 0) which are known to be outside the current footprint. They will not receive your message(s) anyway. The nice GC Terminal program by OZ9AAR provides information about your QSO partner even before the QSO takes place.
In this case K6FW was called at a time where his elevation has been at -20.6° so way below the horizon. This is useless as he will (most probably) not be able to receive the message. Surely it can be discussed if 0° is the limit or maybe 1° - 3°. But -20° is definitely too much. Again this is just stealing air time for other stations.
Do not send many packets at once
Please send your packets one at a time. It is very unfair for other stations if you repeatadly send your call or answer within a small timeslot. In this example the op sent 5 packets within roughly 20 seconds and thus potentially pushing packets of 4 other ops aside.
Avoid sending redundant data
Please adjust your macros and avoid sending same or identical information more than once. Again this is not helping and only stealing air time of other users. In this case the locator of the calling party as well as logging info was send twice where it would have been sufficient sending it once.
Also redundant data in a single packet is to be exterminated. For a CQ call for example just set the target callsign to CQ and add your (4-char) grid in the free text part. Everything else can be ommited in favor of air time for others. In this case ALL as target is redundant to CQ in message part as well as the callsign of the op which is transmitted twice.
Do not answer delayed calls with zero delay
In this case I receiced a CQ call that was obviously sent with a delay of 2400 so definitely not at the time I received it but way before that. The satellite was just repeating it after this delay expired. At this time the calling party was way out of footprint. So it does not make sense to answer this call (if your own delay is set to 0). As it is doubtful if it counts as a QSO at all if you work with delay it does not even sense to answer at all.
Wait until your packet gets repeated
Please wait until the packets you send gets repeated. In this case I called FS/FG8OJ twice with too little time for repeating the packet in between. As a result my packet was repeated twice meaing air time reduced by roughly 50%. It makes sense to wait for at least some seconds to listen and decode if your transmission got repeated before sending the next packet.
General recommendations
Besides these IO-117 specific issues there are some general recommendations that also apply here. So it would maybe make sense to also mention them here as these would also contribute to everyone having fun on satellites.
Only use as little power as absolutely needed
Generally not much power is needed to work satellites. Try to determine which least power level is needed to be repeated on IO-117. Of course this is difficult to find out during a busy pass so it might take time to find out. My portable setup for IO-117 for example uses an IC-705 barefoot with the 70cm Alaskan Arrow antenna (10el).
Minimize TX delay
This is the time the transmitter needs after pulling PTT until it is ready to actually transmit the AFSK signal. If this is unnecessarily long it is again just blocking air time for other users. So to be efficient this should also be as low as possible. My setup with UZ7HO soundmodem and IC-705 uses 20 msec TX delay and works fine. Again this requires try and error and preferrably on a pass with few to no other stations calling. Experiment and find the lowest value that will work.
Avoid calling stations that obviously want to work DX
As rare DXCCs or grids appear on satellites usually there is a big pile-up calling the DX. Even if you did not work the DX (or have worked them before) refrain from calling the other callers. They most probably only want to work the DX station and will not answre to other callers. So again this just waists air time for other users (also wanting to work DX).