Hi sat ops,
Would it be possible/legal to add functionality to UZ7HO Digpeater software to enable a VOLUNTARY / opt-in feature where when you click Send, CQ etc. (to TX a packet), instead of immediately keying the radio, a TX request is sent to a central Internet server (to be created) that sorts requests in some sort of fair sequence and then one by one commands/allows the various requesters to actually TX their packet?
The sequence could be sorted by time, i.e. whoever sent the request first gets in line first. It could be partially random to account for latency (whoever is closest to the server doesn't always go first).
Additional functionality could be added to the Digpeater software, or a central website, to display the queue so you can see your place and watch the people in front of you send their packets and see yourself move up the queue. This would allow everyone to calm down, knowing their turn is coming. On the IO-117 side hopefully this would mean less long gaps with no packets digpeated/much higher rate of digipeats. Imagine if everyone used it: when busy, IO-117 would be digipeating practically non-stop with gaps to RX as short as a single transmission.
The Digipeater software could give each operator a certain number of tries to get the packet digipeated (say 3) before putting them at the back of the queue again if they all fail to be digipeated. The Digipeater software could determine if they are successfully digipeated by checking the RX packets for its own message, and reporting back to the Internet server. The Internet server could even check SatNOGS to verify if the packet was digipeated (it seems telemetry is uploaded in real time). The Internet server software could even be on SatNOGS.
You could also do something like WSJT-X and require everyone to have accurate NTP time and packets are sent at specific intervals, RX happens at specific intervals, but all in order, this way there isn't an issue with varied latencies between the server and the requesters. The sorting happens as fast as possible but the scheduling in the intervals is a bit delayed.
You could program all sorts of sorting heuristics to make things fair or optimize for certain things. If a new station DX station comes on the digipeater and a pile up starts, maybe the Internet server can be enabled to see who is near their LOS and put them at the top of the queue, or just prioritize anyone near LOS. If a DX station goes out of IO-117 FP, requests to TX to it would not be allowed and the requester could be denied and told why. If stations have contacted each other before from the same grids maybe they could have lower priority.
You could even let people complete whole QSOs quickly before moving to the next person in the queue if they are all calling the same DX station, if the DX station is also using the new feature and/or following a set QSO format/exchange.
Another benefit of this is it helps low power stations as there is less need to run high power to compete. In the FCC rules at least, it is a requirement that you use the lowest power necessary to achieve the radio comms goal, so if this proposal is possible it is very much in the spirit of the rules and maybe even necessary. It seems a little ridiculous for everyone to be running as much power and gain as possible when I can get in easily with 5-7 watts and 10 elements when the bird is mostly over SA.
Of course rovers without internet service can't use this, many people will never use this for various reasons, and they could just not enable the feature and use the Digipeater software as they do today, sending TX commands immediately.
Adding this code and creating an Internet server would take a lot of work. I have no solution for that but maybe if UZ7HO can't do it an extension interface can be added to it and someone else can write an extension that communicates with the Internet server. Someone else could also make the Internet server. Or someone could write a new Digipeater software that has all this functionality.
If any of this is possible/doable I think it could make IO-117 / GreenCube a lot more easy and fun to work.
73, John Brier KG4AKV
P.S. Sorry this isn't more well thought out. I'm not a programmer and I'm just throwing out as many ideas as I can think of. Maybe some are possible.