From: DX J. <ah...@ya...> - 2019-01-11 18:17:09
|
Bill, Thanks for your response. The compound call issue is shared with me by many as we see. As you mentioned ... after an FT8 exchange, I often send something like "Aloha fm Virginia" and sometimes I send the grid too. There are some considerations about that though. Number one - perhaps not all people pay attention to the extra transmission ... and are perhaps scrambling to find my grid on-line or more likely searching for other stations. Number two - sending the extra info takes a lot of effort especially when on the air for a few hours and we start getting fatigued. Number three -- compound calls should be handled without problems. They are "legal" call signs allowed by many countries ... plus they are "authorized" under international treaty ... in most cases under CEPT, via the provisions of IRAP [International Amateur Radio Permit ] agreements, or under other reciprocal ham radio permit arrangements. As for us in the U.S. and territories, the FCC authorizes compound calls under the provisions of the US law regulating amateur radio, Part 97, Code of Federal Regulations. Let me know, I will send you an extract if you desire. I understand the technical limitations you described about this issue. Your idea about a public domain database providing grid info sounds interesting. I use Amateur Radio Ham Radio Maidenhead Grid Square Locator Map but unfortunately it does not do most compound calls. With the lack of a usable database ... why doesn't WSJT-X generate one itself ... a self-generating database. For instance ... as someone enters a compound call in set-up ... the required information is transmitted to the big WSJT-X compound database in the sky [perhaps with user permission obtained from a pop-up], and integrated accordingly in the FT8 execution script. [I recognize not all compound call users have internet access to do that ... but perhaps it could be done in preparation for DXpeditions and those taking DXvacations, etc.] Of course we are up against the 77-bit limitation ... but you had an idea about databases - that is an option. Another option in dealing with the 77-bit limitation is dividing the FT8 transmission into two seamless execuables. For instance ... two .bat files execute various lines of the FT8 transmission ... something like .bat1 executes FT8 lines Tx1, Tx2, and Tx3 ... .bat2 executes Tx4, Tx5, and perhaps Tx6 [maybe Tx6 does not demand some of the 77-bit allocation ... ???] By executing the two .bat files, perhaps your programming can piggy-back two seamless executions as though they are one standard FT8 transmission. Of course the compatibility issue may come into play ... hopefully your solution will be compatible with version 2, et al. Another option is to do whatever you did for KH1/KH7Z. I am guessing you used city.dat to overcome that issue. Not an option for someone like me who semi-routinely operates from two different DXCC entities - but might work for everyone else. One more option ... perhaps do the compound calls as a special operating activity such a fox / hound ... or a contest, etc. Now sure if you can overcome the 77-bit real estate issue and resolve the other technical issues here or not. Just a thought ... In closing, Bill - I want to say I appreciate the great effort by you, Joe, and the entire WSJT-X team. It is an understatement to say your work has changed ham radio for the better. With all due respect, I say the compound call issue must be overcome. If you spend time on the bands playing FT8 ... daily, you will see various stations using compound calls and sometimes you will see calls from the two "overseas" US states [HI & AL], the US territories, and the Commonwealth of Puerto Rico seemingly out of place by transmitting from someplace else like Virginia or Massachusetts. There a several stations on now operating under CEPT and other reciprocal permits. I worked a few within the past few days and saw some this morning. Of course there will be many other CERT calls on the bands when the spring and summer vacation season begins, and when this year's DXpeditions and DXvacations get up and roaring. Looking forward to you all overcoming the compound call issue. 73 and Aloha from Virginia, Danny W4/AH6FX | | | Amateur Radio Ham Radio Maidenhead Grid Square Locator Map Amateur Radio Ham Radio Maidenhead Grid Locator in Google Maps | | | On Wednesday, January 9, 2019 8:36 AM, Bill Somerville <g4...@cl...> wrote: On 09/01/2019 12:05, Bill Somerville wrote: > If you are in this situation then you must either send you gridsquare > post QSO in a free text message if you want to give your QSO partner a > chance to recognize you are not in HI, or use a compound callsign that > indicates your location like /W4. Hi again, a correction to the above. "If you are in this situation then you must either use a compound callsign and send you gridsquare post QSO in a free text message, or use a standard format callsign which allows you to send a gridsquare in standard messages. Either way indicates your actual location, both options together are not possible." Note that both of the methods above are available to a station with an callsign issued in HI working from the lower 48. The former has more restrictions that the latter due to a standard callsign being used. In both cases your QSO partners have the information to determine you are not operating from HI. All I can suggest is you point that out to them if they fail to notice. Note also that we cannot add special cases to WSJT-X for the same reason that the AD1C CTY.DAT file cannot contain an override for this situation because you still operate from HI and the software does not know when that is happening. There is one possible solution in that some cases can be clarified if your gridsquare lies wholly outside of the DXCC entity that your callsign indicates. If anyone knows of a database that can be incorporated (i.e. in the public domain and freely usable) into WSJT-X that is 100% accurate in determining mismatches between gridsquares and DXCC entities then we will consider using it. 73 Bill G4WJS. _______________________________________________ wsjt-devel mailing list wsj...@li... https://lists.sourceforge.net/lists/listinfo/wsjt-devel |