IDEAS For SKY-COMMAND III for CLUB ops 22 Feb 07 ---------------------------------------------------------------------- SkyCommand II was designed for an individual to have remote control of his own rig on a one-for-one basis. But there are many applicaitons for clubs that may want to have a group with access to the SkyCommand HF transceiver and for all to be able to participate in the group monitoring while one is transmitting. Here is my WEB page that tries to optimize this type of operations. http://www.ew.usna.edu/~bruninga/USNAremoteHF.html Although we can do Group operations with SkyCommand II, there are some ideas that could make this better, for new users while being fully backwards compatible with SkyCommand II systems. An overview of the required changes for group operations for what I call SkyCommand III are as follows: 1) Use default Generic COMMANDER and TRASNSPORTER calls so that everyone can set their radio once, and then be able to use any Sky Command system that is made public with these same generic calls. 2) Use two PL's on the UHF audio link, so that only one PL keys the remote SkyCommand transmitter, but the other PL (or none) lets all members of the group chat on the UHF channel for coordination. Enable a front panel button for selection of CHAT or PTT choice of PL while operating Sky Command. 3) Have provisions for the multiple COMMANDER radios to BEACON an APRS status packet periodically that contains their FCC call so that they can be identified and so that other SKY-III transceivers can also see who else is sharing the UHF command channel and operations. 4) Have the TRANSPORTER auto-QSY periodically to the APRS channel and put out a Sky Command status packet to put the HF asset on the APRS system map showing the current operating frequency. 5) Some provision for additioanl commands for antenna selections. 6) Allow the D700 to operate UHF COMMANDER link on band A UHF so that band B can be used for 220, 902 or 1296 reception of Sky Command Audio. DETAILS FOLLOW: Each of these concepts is further expanded below. GENERIC CALLS: Let the default COMMANDER call be CMDR and the default TRANSPORTER call be TRPTR, and default TRANSPORTER skycommand PL be 123. while the default USER or CMDR PL is 88. This makes any user able to monitor a SkyCommand system out of the box, or to go from one public skycommand station to another. And he can chat with other skycommand users on the UHF channel without bringing up the HF TX, unless he selects the special 123 TX PL. Another advantage of generic callsign operation is that multiple COMMANDERS can all be in SkyCommand mode and can see the same front panel HF radio status at the same time. ALTERNATIVE (a): Another option may be to have the OPTION for public systems to allow the TRANSPORTER to be GENERIC on receipt and accept Sky Commands from ANY callsign in this mode. This way, every existing COMMANDER can control the radio without having to use a generci call. This keeps the COMMANDER operator legal, since his call will be in every packet. ALTERNATIVE (b): Another option for COMANDERS is to allow for GENERIC receipt and display of Sky Command data independent of the TRANSPORTER call. This way, each COMMANDER does not have to change his transporter callsign for each different GENERIC system that he wants to control. UHF PL CONSIDERATIONS: 1) While in Sky-Command mode, the COMMANDERS need a front panel button to turn on and off sky command PL. This way, all the group COMMANDERS can turn off special PL and talk/coordinate back and forth on the UHF simplex channel without keying up the sky-command radio. This allows very powerful use of HF radio in local groups, and very simple to implement. I suggest naming this soft button toggle between "PTT" and "CHAT" as it toggles between the SkyCommand PL and the non-skycommand PL or off. SKYCOMMAND COMMANDER OBJECT BEACON PACKETS: While a COMMANDER is in SkyCommand III mode, it should include some periodic OBJECT packets to tell others on the UHF frequency who it is and where it is. This should beacon once every 10 minutes or each time after the skycommand RX is activated. FORMAT: THe format for the status packet (in APRS OBJECT format) would include the MYCALL as the object name and TIME/position, etc. This is because the actual packet will be originated by the generic "CMDR" callsign and so without the OBEJCT packet, we cannot tell who is doing what. Here is a suggeted format: CMDR>APKxxx:;MYCALL-SS*HHMMSSzDDMM.__N/DDDMM.__W$SkyCommand TX myname Which will show up nicely on the D700 as: MYCALL-SS: SkyCommand TX Bob THe TX is transmitted if the SkyCommand PL is set, and an "RX" will show if the SkyCommand PL is not set. LIST: On receipt, these objects can go to the normal APRS list or to the DX list? While in SkyCommand III mode, there should be a "LIST" hot key on the D7 or D700 radio that will call up this list, and display only other SkyCommand stations. PACKET MUTE:??? New COMMANDER radios need to have a 20 dB mute when monitoring the UHF channel so that VOICE can be heard but packets are muted. Or is CTCSS Set in Skycommand mode? If so, then it needs to recognize BOTH the PL's for PTT and for CHAT mode only. CROSSBAND???? While Sky Commander with TX PL is transmitting on HF, does the VHF audio link remain up and provide a copy of the transmitted voice so that all monitoring stations can hear it? This can help in CHAT mode with PL's and muting packets? More thought here... SKYCOMAND III TRANSPORTER APRS ANNOUNCEMENT PACKETS: SkyCommand III needs an APRS Station packet from the Transponder radio periodically that goes out on the APRS (144.39 in the USA) channel to beacon the HF radio (IF) status for all surrounding APRS mobiles (on 144.39). This beacon packet will put the public SkyComand III station on the MAP, and alert all drivers of its presence and operating frequency. In most cases, this packet will go only DIRECT. TRPTR>APKxxx:;TRPTRCALL*HHMMSSzDDMM.__N/DDDMM.__W$145.550Sky441.550 MHz MM.KKK MHz Which will show up nicely on the D700 as: TRPTRCALL: 145.550Sky 441.025MHz 14.123 Notice the Frequency is inlcuded. But the inclusion of the UHF is optional and if not used, then the HF channel can show. The Transporter needs to auto-qsy for one-second periodically to put this out on the APRS frequency and not the SkyCommand channel. My guess would be once every 10 minutes if no-change in frequency and within one minute of each frequency CHANGE. THis results in no transmissions while fine-tuning, but an update within a minute after a change is made. Also, the SkyCommand Transporter needs to INITIATE a radio status packet (in IF... format) once every minute on the UHF command frequency to update all monitoring COMMANDERS that may begin monitoring. Note: Backwards compatibility. For SkyCOmmand II, a BT and BEACON can be set in packet mode and it will continue to work in SKyComand mode, but it is not on the APRS channel, only the SkyCOmmand channel. ANTENNA SELECTION: SkyCommand III needs to be able to select ANTENNA on the TS-2000. ALthough MEMORY channel on TS-2000 can remember ANTENNA 1/2, an external antenna selection is needed for selecting fixed beams or othere options on the same band. More later on this subject? SEMI-PUBLIC OPERATION: Provision needs to be made in Sky Command III for the uplink command channel to be on 900 or 1296 MHz and private, while the VHF or User Listening channel can be on VHF or UHF. In otherewords, the Sky Command III should be able to operate in RECEIVE-ONLY mode and give the user the full status of the SkyCommand Radio display, even if he is not commanding and even if he cannnot press [0] to start the link. CONVERSLY, provision needs to be made for Sky Command to use 220, 900 or 1296 bands in place of the VHF audio link. This reduces the demand on the 2m band for these links. The Remote controlled site may have to add one of these 220, 902, or 1296 band transmitters just for the audio, but the D700 should be able to receive this audio in place of 2 meter audio link and still operate in Sky Command COMMANDER mode. It is very easy to BUILD a skycommand III system TRANSPORTER with a D700 radio's internal TNC and some external software. So this investment in SkyCommand III can multiply more than just the new radios sold. SkyCommand III also willbe fully backwards compatible to II's. SOFTWARE TRANSPORTER: My next document will describe tha backwards compatible SkyCommand II+ system that can run on a PC between a D700 TNC and a TS-2000. This PC software can implement many of the advantages of SkyCOmmand III and be compatible with existing D700's. More thinking needed. Bob Bruninga, WB4APR