[wsjt-devel] Yet Another Compound Call Issue
Bill et. al., I have identified another problem with autoseqencing with compound calls, that can generate and log invalid QSOs. It seems that when someone responds to my CQ with TX2, the resulting standard TX3 response from me enables someone else to hijack the QSO. Here is an example of the problem, cut and pasted from the RX freq window: 130430 -3 0.3 1417 ~ W7RI K0GK -15 (K0GK responds to my CQ) 130430 7 -0.5 1518 ~ W7RI N3OUC FN20 (Call 1st is on, so this call is ignored. It's supposed to. So far, so good.) 130445 Tx 1415 ~ DE TI3/W7RI R-03 (I respond to K0GK with TX3) 130500 6 -0.5 1518 ~ W7RI N3OUC R-08 (N3UOC continues to call, even though I am in QSO with someone else. He is ignored. Great! So far, so good.) 130515 Tx 1415 ~ DE TI3/W7RI R-03 (K0GK has failed to respond, so I resend TX3) 130545 Tx 1415 ~ DE TI3/W7RI R-03 (K0GK has failed to respond, so I resend TX3) 130615 Tx 1415 ~ DE TI3/W7RI R-03 (K0GK has failed to respond, so I resend TX3) 130630 -4 0.7 1416 ~ W7RI JA2XYO RRR (Because, for compound call users, TX3 does not send the call of the station I am working, JA2YXO responds, thinking mistakenly that I am in QSO with HIM rather than K0GK) 130645 Tx 1415 ~ DE TI3/W7RI 73 (Hearing the RRR sequence from JA2YXO, my software responds with the Log QSO dialog box, but populated with JA2YXO's callsign, and K0GK's signal report - an invalid QSO.) This problem happens with enough frequency to be something of an issue, particularly when I am working a large pileup as I was this morning, which is a good deal of the time. Whenever someone responds with TX2 and I send TX3, there's enough people out there attempting to call me that this will happen with some frequency - maybe once in 15 or 20 QSOs. Configuration does not allow me to work around this by changing the TX3 standard message without forcing me to change others I don't want to change. Maybe the software should test to see if the callsign was changed since the last signal report has been received before sequencing to TX5 and bringing up the dialog box, and not advance the sequence or allow logging if it has. Regards and 73, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] DXPedition System Clock Sync
On 07/12/2017 05:48 p.m., Dave Corsello wrote: Then the idea of an automatic network isn’t feasible. Maybe it could work if every WSJT user who had access to NTP had the option to broadcast time data periodically from their station. Let's get real here, folks. The SOLE utility of WSJT-X is to generate QSOs. Full stop. As a consequence of deliberate, well-considered design decisions, it is close to useless for communicating any message longer than 13 characters, so the only time you're going to use it at all, at least in any serious way, is when ALL you want to do is generate contacts, not convey information. If an EMP takes out your Internet service and nullifies your NTP access, it's because there's a friggin' WAR on, dude, and you're going to have much more serious problems to worry about just generating contacts for yet more wallpaper. And as far as the DXpeditions are concerned, in such an event, I guarantee you that freezing to death in a fragile tent amidst howling blizzards on a rocky beach on Bouvet Island is quite likely the last priority you're gonna have in the midst of a war serious enough to see the GPS network shut down or become inoperative. So just buy the darned $25 GPS receiver from Amazon and take it with you on your next DXpedition and don't worry about the theoreticals that you're not going to encounter in any likely scenario. Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Another Compound Callsign Problem
On 04/12/2017 05:34 p.m., Libor Holous OK2ZO wrote: Dear Scott.. Look.. As I said, experienced smart operator will get the call correctly.. The others can repair it in their logs anytime later. The experienced, smart operator will. The problem I encounter is the embarrassingly large number of operators that are inexperienced, not smart, or both. These problems get compounded by the large number of operators that are still using the early-version FT8 software that will not sequence properly when working some unfortunate, hapless schmuck like me who is stuck with a compound call. It's not your problem. Actually, it is, because I can't 1) get all those operators out there to learn how to use their software, 2) increase their intelligence/awareness level to a reasonable standard, or 3) teach them that, just because their "About" window says they are using says "1.8.0," that doesn't mean that they're using the largely bug-free general release version, rather than a thoroughly bug-ridden early development release candidate version that they downloaded and installed from that obscure web site in Outer Slobbovia, or haven't updated since they first heard about FT8 and downloaded it from Joe's site when FT8 was first announced. The net result is that I end up aborting about one QSO in five, because the other guy either isn't sequencing properly or does something unexpected. Most often, he's not sequencing properly because he is using a development version that doesn't handle compound callsigns very well. N.B. JOE: I really wish Joe would put up a note on his web site about that - because the vast majority of people not involved in software development don't understand and have absolutely no clue about how software version numbering is being done these days. It would be extremely helpful in getting those folks to upgrade their software. The note should be placed near the download links where it can't be missed. Here is the wording I would suggest: "NOTE: If you are using software that was downloaded from this or another OFFICIAL site prior to October 28, 2017, you are using a development version, even if the version number shown on your software is "1.8.0." As many of the development versions (designated with -rc1, -rc2 or -rc3) have bugs that can cause operational problems on-air, you should update to this version as soon as possible to prevent problems on-air. There is no guarantee that software downloaded from unofficial or unauthorized sites is current." 73, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Another Compound Callsign Problem
On 04/12/2017 12:57 p.m., Libor Holous OK2ZO wrote: Experienced users will quickly know, you are from Costa Rica.. Just send time to time CQ and standard 73 message with full call.. Libor, I understand what you are saying, but the reality is that a lot of fellows in the States, when they sit down for a session, will simply glance at the band activity window and not connect up my abbreviated call and my full callsign, because it may not appear on their list of decodes. If my full callsign, from a CQ or 73 message doesn't appear in the band activity window, they will not appreciate that I am a DX station. I do, in fact, call CQ frequently - mostly so my full callsign gets out there, and also because it makes starting an autosequence more sure. But when I'm working a pileup, as I am most of the time, I can go for quite a few QSOs - ten or fifteen minutes - with the software never sending a CQ, but simply replying to the first decode that pops up after my last 73 message, and Call 1st then sends to the standard messages. When that happens, I do not send a complete callsign at all until the next 73 message, (and technically, that's not legal under the rules here - we are supposed to transmit the full, unabbreviated call signs of ours and the other station's call, during the first and last transmissions in a QSO and "frequently" in between). And it also means my full callsign is transmitted far less frequently, as it appears only in the 73 messages I send. If the other station who might be considering calling me has a lot of band activity that is generating a ton of decodes, he may not ever notice that my full call is a DX callsign. And very few, if any, ever will ever figure it out from my grid square alone. Anybody will always put you to the cluster, so you won't have to be worry, you not have a pileup.. That is not always true when I am working a lot of Stateside stations, many of which probably never realize, till my 73 message, that they've even worked a DX station. Many, if not most stations in the States will never spot me to the cluster (because, even though I'm DX, I'm in a commonly worked country), and, because of my proximity to the States, they represent the bulk of stations I work. I can always tell when I've been spotted to the cluster because the pileup instantly gets much bigger. And that happens only infrequently when most of the stations I am working are Stateside. When I am working a lot of Europeans, yes, at least a third of the stations I work there will spot me. But that is a much less common practice in the States. Question is, if EU is more DX than US for you? For lot of stations from Caribean it's opposite.. For purposes of awards, they're all the same - anything outside of Costa Rica is DX to me - including 200km up the road in Nicaragua or 150 km down the road in Panamá. If your question is whether I am more desirous of working E.U. than U.S., no, it doesn't matter to me as I'm not really much of a DX chaser, unless it's a country I haven't worked, and then I want it - no matter where it is. And in E.U. all I am lacking are Andorra and Lichtenstein, but still lack several in Latin America, mostly in the Caribbean. 73, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Another Compound Callsign Problem
On 04/12/2017 07:39 a.m., Rich - K1HTV wrote: A caution to those of us who often bypass the TX1 message (calls & grid) and start with TX2 (Calls and report). The problem for those of us with compound calls, is that TX1 populates ONLY with OUR own full call - it does not include the other guy's. So the other guy doesn't know if you're responding to HIM rather than someone else. Using TX2 fixes that problem, but... Another problem (for me) is that if I respond with TX2, which has my abbreviated, U.S. call in it, the other guy often thinks I'm just yet another U.S. station with a 1x2 call sign, and who cares? So they don't answer, not realizing they're being called by a DX station. So the problem for those of us forced to use compound calls, is which problem is worse. I seem to get more frequent responses with TX2 nowadays so it's what I now use. When calling a DX station with a complex callsign, when the DX station responds, none of the messages in his transmitted sequences will have YOUR callsign in them. There is no way to know for sure that the DX station is responding to you or another station. Yup. See the above. The fix, when calling stations with complex callsigns, is to start with the TX1 message. Unless you're a DX station forced to use a compound call. See my first paragraph above. Another note, when using the alternate TX4 (RR73) message, if after you send your "RR73" message the station you are working responds with a TX2 (calls and report) instead of a TX5 (73) message, that indicates that the station is probably using an older version of WSJT-X. I've sent out numerous emails to those who have responded that way when I worked them and almost all have responded, confirming that they were using an older version. I'm using the current version and have had that happen to me. It certainly happens a lot with other stations, so I don't use the alternate TX4 for that reason. A more serious problem for us users of compound calls is that the earliest versions of FT8 software doesn't handle compound calls well at all, and will often hang up during auto sequencing. So when this happens, I give the guy four chances to take it out of autosequence and advance manually, but when he fails to do so, I've taken to aborting auto sequence and sending a macro that says UPDATE SOFTWR. I am still having to do that on about one out of every ten Qs I have. On 20m, it's noticeably worse - about one in five. It's why I tend to stick to 15 and 17 when those bands are open. 73, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Another Compound Callsign Problem
On 02/12/2017 07:01 p.m., John Broughton wrote: Here is a copy of our transmissions. Your call showed up as TI3/W7RI on your CQ. The generated messages from me just had W7RI in them, except my 73 message which had TI3/W7RI. Your responses during the QSO showed W7RI with TI3/W7RI showing up again in your 73. I assume this is the way it is supposed to work. 183015 8 1.0 1607 ~ CQ TI3/W7RI EJ89 171202_183030 Transmitting 21.074 MHz FT8: W7RI WB9VGJ DM34 171202_183100 Transmitting 21.074 MHz FT8: W7RI WB9VGJ DM34 183115 7 1.0 1607 ~ WB9VGJ W7RI +11 171202_183130 Transmitting 21.074 MHz FT8: W7RI WB9VGJ R+07 183145 10 1.0 1607 ~ WB9VGJ W7RI RRR 171202_183200 Transmitting 21.074 MHz FT8: TI3/W7RI 73 183215 5 1.0 1607 ~ DE TI3/W7RI 73 BTW, thanks for the QSO. My pleasure, John. Yes, that's the way it's supposed to work with compound call signs. And as long as everyone uses the standard messages with the current software, everything works just fine with them. The problems that arise happen when calls used are not in a standard message, or are not in a standard autosequence series. You were not answered on the first try because someone else in the pileup decoded before you did, and got worked before you were. I'm really looking forward to the "fox and hound" protocol for working pileups, which account for the bulk of stations I work. It should speed things up considerably and increase my QSO throughput considerably from what I am hearing about it. Other stations here locally I have talked to have expressed similar eagerness for it. Technically, FT8 and similar protocols are of questionable legality here, since our local rules stipulate that the full, unabbreviated call signs of the station being worked, as well as my full, unabbreviated call sign must be transmitted at the beginning and end of a series of transmissions, and "frequently" in between - but they don't say anything about the use of abbreviated calls during a series. But since no one here has yet been cited for identification infractions using FT8 or other WSJT modes, I suspect that it's not being considered by them to be a problem, since my full call sign is transmitted during the CQ, and during the 73 sequence, and the other station's full call is transmitted by me at some point in between. Presumably, that seems to satisfy the regulator here locally, as they have not yet said anything about it. The exception would arise when I, with my compound call, will be working another station with a compound call. Haven't encountered that one yet to see how that one works out. 73, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Another Compound Callsign Problem
On 02/12/2017 05:45 p.m., Bill Somerville wrote: you can always click the appropriate message button to continue the QSO with him. I have noticed that the program won't populate the standard messages if I click on the call in a non-standard message or a previous auto sequence has not been aborted. So I've grown used to not bothering to try in such situations. 73, Scott -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Another Compound Callsign Problem
On 02/12/2017 04:40 p.m., Bill Somerville wrote: On 02/12/2017 22:28, Scott Bidstrup wrote: TI3/W7RI WY5I Hi Scott, the above message is not a standard format message, it is a free text message. WSJT-X does not try to interpret free text messages apart from the general case of messages containing the word 73. 73 Bill G4WJS. Thanks, Bill. That explains it. I appreciate the explanation. The guy was quite persistent, and kept after it for a dozen or more sequences... Finally, he gave up after seeing me working others... 73, Scott -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Another Compound Callsign Problem
I have encountered another problem with compound call signs that needs attention. If I am calling CQ and someone calls me with my full callsign in the decode, not just my abbreviated call, auto sequence won't recognize my call and begin the sequence after he responded to my CQ. Note the following series copied from the RX Frequency window (auto seq and call 1st were both checked when this occurred): 222300 -1 -0.2 1322 ~ TI3/W7RI WY5I 222315 Tx 1323 ~ CQ TI3/W7RI EJ89 222330 -1 -0.2 1322 ~ TI3/W7RI WY5I 222345 Tx 1323 ~ CQ TI3/W7RI EJ89 222330 -1 -0.3 1323 ~ W7RI K5VP CN85 222345 Tx 1323 ~ K5VP W7RI -01 Regards, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Call change while logging
It would be preferable, I think, to simply allow the changing of the DX call in auto sequence, but NOT change the data that is in the dialog box that is going to go to the log file when the log dialog box is open and then OKed. This would solve the problem, but not cause a problem with the next auto sequence when the log dialog box is OKed, and then TX is then enabled. Hi Scott, this is already exactly what happens. Bill, I've actually SEEN it change the callsign in the Log QSO dialog box AS I was moving the mouse over to the OK button - when it happens, it is in the first second or two after the dialog box has opened. The callsign changes, but the rest of the data in the dialog box does not. So I know it can change the callsign in the dialog box, under some circumstance, however rare. I've seen it happen. Scott -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Call change while logging
On 26/11/2017 01:04 p.m., Rich - K1HTV wrote: Disabling the changing of the DX call while the logging box is open would prevent the problems now being experienced for those that don't act fast enough to log the previous QSO. I've had this happen to me, too. It would be preferable, I think, to simply allow the changing of the DX call in auto sequence, but NOT change the data that is in the dialog box that is going to go to the log file when the log dialog box is open and then OKed. This would solve the problem, but not cause a problem with the next auto sequence when the log dialog box is OKed, and then TX is then enabled. 73, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Another Issue With Auto Sequence
All, I have noticed another issue with Auto Sequence that should be addressed. Here is a sequence series, copied and pasted from the RX frequency window, that exemplifies the problem: 181945 7 -0.5 1235 ~ W7RI WA2VCQ EL87 (other calls fm. a previous CQ) 182000 Tx 1236 ~ WA2VCQ W7RI +07 (I respond, auto seq. TX2) 182015 8 -0.5 1235 ~ W7RI WA2VCQ -07 (other stn. responds) 182030 Tx 1236 ~ DE TI3/W7RI R+08 (auto seq. goes to TX3) 182045 11 -0.5 1235 ~ W7RI WA2VCQ RRR (other stn. responds) (Log QSO dialog box comes up automatically; I clicked OK) 182100 Tx 1236 ~ DE TI3/W7RI 73 (auto seq. goes to TX5) 182115 6 -0.5 1235 ~ TI3/W7RI 73 (other stn. responds) 182130 Tx 1236 ~ WA2VCQ W7RI +06 (auto seq. goes to TX2) Note that rather than ending the auto sequence after logging, the system jumped back to TX2 and attempted to continue the auto sequence again from there, which I had to manually abort. This problem happens with rather considerable frequency, and if the auto sequencing sequences from TX2 to TX3, it will ALWAYS happen. Usually, if the auto sequence jumps from TX2 to TX4 (most often the case), it will not happen, and the auto sequence will complete normally. Not sure if it is related to the fact that I am cursed with having to use a compound call, but maybe... Regards to all, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Aborted Auto Sequence Issue
I have noticed a small issue using F4 to abort an auto sequence in FT8. As I am cursed with having to use a compound call, and there are still a surprising number of rc1 users out there whose software can't handle compound calls like mine very well (I am guessing about one in five), I frequently find myself on the other end of a QSO with a user whose auto sequencing gets locked up when trying to deal with my call. F4 aborts the auto sequence for me just fine and erases the standard messages, and that's been a lifeline - the F4 key is now my new best friend. But I have encountered a small bug using it that probably ought to be fixed. If the other user gets locked up, and then I use F4 to abort and have not yet repopulated the standard messages, and the other user then unexpectedly happens to then send the next expected sequence, my software will then transmit a sequence that is totally empty because, well, I just erased the standard messages when I hit the F4 button. Perhaps the software should look to see if the sequence about to be transmitted is empty, and not transmit it, if it is. Regards from rainy Costa Rica, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Problem with standard message generation
On 21/11/2017 06:38 a.m., Rich - K1HTV wrote: Scott, Have you tried using the F4 key to clear the current QSO messages then click on the new station call that you want to work? Yes, that works. Thanks, Rich. Helps enormously with pileups. 73 all, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Problem with standard message generation
All, Maybe I'm doing something wrong here, but I've encountered a problem with the standard message generation and auto sequencing in FT8. As I am a DX station, usually when I call CQ, I will get multiple stations answering me. So far, not a problem. If I have Auto Seq and Call 1st both checked, the messages auto generate on the first decode with my call in it, the system starts through the sequence and as long as I hear the other guy's responses in the proper sequence, all is well. The problem I am encountering is when the station I am working fails to respond to the sequences in the series as expected by the software for whatever reason (and this happens with some frequency) and I have to abort that sequence. Maybe I've missed something here, and if so, let me know, but the really annoying part is that there doesn't seem to be an easy way I have found to abort an auto sequence and regenerate the standard messages for a *different* call. Disabling transmit doesn't do it. Unclicking the Auto Seq box doesn't do it. Clicking on the Generate Std Msgs button after highlighting the call doesn't do it. Double-clicking another redlined call doesn't do it. Nothing does it that I've found, except disabling transmit, then selecting the TX6 radio button, then enabling transmit and ACTUALLY SENDING a CQ sequence. THEN I can double click on the call of the next guy in the pileup and it will generate the standard messages. But more often than not, by the time I've done all this and he's gotten my first sequence in the new series, that guy's already seen the CQ sequence I didn't really want to have to send, and has declared me to be a jerk or a doofus, and has gone away. Probably with a disgusted look on his face. May I suggest that, somehow, during an incomplete auto sequence, that there should be an easier way to abort the current auto sequence series and enable the generation of new messages and start a new auto sequence. Perhaps, during an auto sequence, double-clicking on a different red-lined callsign should generate a context menu button that says "Click To Abort Current Auto Sequence And Restart With This Call" and then, if that button is clicked, it would reset the standard messages to the new call and start a new auto sequence. This would be enormously helpful in pileups when the other station gets lost or out of sequence for whatever reason (which seems to happen with considerable regularity) and balls things up with the sequencing. If, at that context menu, one simply clicks on the first station's redlined call, it could simply restart the sequence and get it going again. Then I wouldn't have to look like such a jerk to get the auto sequence software working right again. Another, similar context menu button would be nice for working pileups. After the auto sequence is complete, if auto seq is checked, double clicking on another redlined callsign could produce a context menu button that says "Click To Enable/Start New Auto Sequence With This Call" - it would then set the standard messages, enable transmit and begin with the first sequence. This would greatly facilitate working pileups, without having to always remember to manually enable the transmit separately (which I seem to have a problem remembering to do in time to not lose that first sequence period). 73, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] DXPedition System Clock Sync
On 11/11/2017 11:11 a.m., Bill Shell N6WS wrote: Thank you David for your comment. You understand my original point in asking for the option. All the other comments were trending to the need for the system clock to be accurate. It is the framing that needs the accuracy. The several problems I foresee in using a timing average as a frame - it's only as accurate as the average, and if the number of decodes is small, and they don't happen to be particularly close and are off in the same direction, the average may not be particularly close to the correct time, so your framing reference gets set to the wrong time. And before long, someone on the correct time may not get decoded. The second problem that I can foresee is that, over time, if everyone were to get lazy and just switch to using that option rather than dealing with their system clock, sooner or later the average is likely to drift away from accurate time as there's nothing to correct the average frame reference other than probability statistics. And if you come up with a new install, you're not going to get decodes (and a framing reference) if everyone in your bandpass is six seconds off in the same direction. So I don't see using average decode timing option as being particularly wise - it creates a ticking time bomb (no pun intended) that kinda defeats the whole purpose behind standard time references. A third problem comes when you're using a cheap Chinese clone computer motherboard like I am that has a really terrible clock. It runs VERY fast (a second and a half per hour) - and I have to set it twice a day at minimum for decodes to be reliable. How would I set it to the consensus time frame reference (problem 2) if that reference is no longer the NBS standard? No way to do that that I can see when my reference is far enough off that the decodes aren't decoding. No, I think that sticking to setting the system clock to an NBS reference, however derived, is a better idea. Just spring for the twenty bucks and take a GPS dongle with you on your next DXpedition. In fact, Amazon has one that is on a USB cable, so you can stick the antenna out of the tent if you need to. Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] DXPedition System Clock Sync
On 11/11/2017 09:26 a.m., Bill Shell N6WS wrote: Hello, While using FT8 in a DXPedition setting, there may be conditions where there is no reliable timing source for syncing of the system clock. Bill, When my Internet here in Costa Rica has been down, I've been able to sync my system clock adequately closely by using WWV and using the Windows clock set feature to set the clock, by simply setting to the next minute and then clicking the Apply button as the time comes around to zero seconds. After doing it a few times, you can nearly always get the hang of it and get it within a second or so. Close enough that I've gotten by. It's a nuisance and takes a bit of practice, but it can be done in a pinch. And it's gotten me back on the air many times. Per your request, though, I envision a clock set feature whereby you would set the receiver to zero-beat WWV, and call a special clock set routine that would look for the top-of-the-minute tone at the right audio frequency and at approximately the top of the minute. When it sees the tone appear at the right frequency, and at about the right time, it sets the system clock accordingly. In my professional work, before the advent of the Internet, I used hardware clocks based on such a system, and they seem to have worked reasonably well most (though not all) of the time. That would only work, however, in parts of the world where WWV is available. When I lived in Africa many years ago, however, WWV was rarely audible, but there was a different time signal that I could hear, a digital signal of some sort, and I have no idea where it originated from (EU maybe?) or what the protocol was. Something that uses that or other protocols might be useful in those regions. Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 1.8.0 Waterfall freezes
On 02/11/2017 02:01 p.m., Ervin Hegedüs wrote: I confirm this bug - until the Debian package test, I also had this problem. I have also seen this happen from time to time on my XP64 platform. I attributed it to ancient, potentially unstable hardware, but maybe not. When this happens to me, the program itself becomes unresponsive and won't do anything until it's closed and restarted, frequently requiring the task manager to kill it. I have also had problems with the program crashing on occasion and closes itself, and Windows asks if I want to sent MS a crash report. When this happens, restarting the program resumes without problems. Scott B. TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT 1.8.0 RC3
On 18/10/2017 01:27 p.m., Bill Somerville wrote: Having both parties to a QSO on the same frequency is conceptually simpler but in theory one party may have QRM from half of another QSO or local QRN, in that case moving improves the number of successful QSOs overall. For us DX stations who make most of our contacts in pileups, it's actually BETTER to have folks transmitting wherever they can find a clear spot in their own RX bandpass, rather than always on their QSO partner's transmit frequency. On PSK31, for example, where simplex is the norm, I have a terrible problem with that - when ten or twelve people are calling me on my exact freq, I copy NO ONE, including, often, the party with whom I am having a current QSO. On FT8, on the other hand, it's an advantage to have them scattered throughout my RX bandpass, because more of them get decoded, and the guy I am currently working is less likely to be QRMed, and I can pick and choose among the calling stations. So, the more I think about it, the better I like not having TX and RX locked together. Everyone just needs to get used to the idea that, on FT8, the other guy doesn't need to be on your exact frequency. As long as he's in your RX bandpass, you can decode his sequences, work him efficiently, and it's OK. Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Compound behavior
On 06/10/2017 09:07 a.m., Black Michael via wsjt-devel wrote: Does anybody use TX1 for full call? Never seen one. I usually do. And most of the compound call users I know here in Costa Rica also do, too. The problem that those of us DX stations cursed with having to use a compound call have, is that if we answer a CQ with TX2, we can often be (in fact, usually are) ignored - who cares about yet another W7 (they never bother to note that the grid square is not in the U.S., unless they're grid hunters)? The problem with responding with TX1 is that the station to whom we are responding aren't always sure that we are responding to THEM. So we're damned if we do, and damned if we don't. Several of the other gringo hams I know here in Costa Rica are faced with the same issue. So the question becomes, which is the least problematic. And a lot of use over a long period of time, everyone here seems to settle on TX1. And as a result, most of us have taken to using TX1 to avoid being frequently ignored. 73, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Experimental changes in r8125
On 28/09/2017 03:44 p.m., xx wrote: Scott, i don't like it. Normal operation is TX=RX; split is an occasional mode for most. The extra steps should be in the split mode and simplex should be default.Phil Understand, Phil. I feel exactly the same way - for me, TX=RX (simplex) is also BY FAR the most common mode I use (rarely use split), since I'm neither a DX chaser nor a contester. It's the logical mode for both casual users and new users that are naïve to all the subtleties of how to use this software casually. But we'll see what comes of it. I'll pass along your comment to the development list... ...List readers: The above is from a list non-member, but who compiles his own latest versions, and tried this, but doesn't like it, as, like me, he is a casual user, and is neither DX chaser nor contester (and I have a suspicion that there are more users like us than are in those two categories). He's told me in a previous message that he found it sufficiently inconvenient that he uninstalled 8133 and went back to a previous version that doesn't have this change. I would suggest that if this is going to become a permanent feature, it should be part of a feature set that is active ONLY when a "contesting/DX chasing mode" tick box is checked. Which, for Phil and I, it almost never will be. Scott TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Feature Request - Wide Graph Size
On 12/09/2017 08:37 a.m., Black Michael via wsjt-devel wrote: Just figured out...if you turn off the controls it shrinks a lot further. I just discovered an issue with that. If you have it shrunk down, then turn on the controls, it will resize to accommodate the controls - but then, when you turn the controls back off, it does NOT re-shrink to the size it was before you turned the controls on. You have to manually resize it again to where you want it. That's something of an annoyance. Scott TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Feature Request - Wide Graph Size
On 12/09/2017 08:37 a.m., Black Michael via wsjt-devel wrote: Just figured out...if you turn off the controls it shrinks a lot further. de Mike W9MDB Ah, that should be noted in the user guide. I think that's what tripped me up. Thanks, Mike. Scott TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Feature Request - Wide Graph Size
On 12/09/2017 08:11 a.m., Black Michael via wsjt-devel wrote: There's no such thing as "configured bandwidth". WSJT-X has no idea what the width on your rig is. How much smaller than this do you need the window to be? See the window on the upper left here? It's about half the width of the minimum WSJT-X window size. You need it smaller than this? This is interesting. I think there may be a small bug. When I first installed this release and ran it from the installer checkbox, and tried to resize the wide graph window to fit my monitor, it stubbornly refused to allow me to set the width to less than about 1/3 of my monitor width (the initial run did not recognize either the window position or sizing settings from the previous install's configuration, but instead went to default). So that was what prompted the bins/pixel and repositioning workaround, which I have used ever since the first time I ran the new release, on the assumption that the size limitation I encountered was permanent. Now, when I just tried it, it WILL allow me to resize to about a fifth of the screen size, just fine, no problem. That is adequately small to do what I need. So something has clearly changed from my initial run to now. I have no idea what, but now I can do what I need - so if this is a bug you don't want to mess with, fine, sorry for the trouble, I'm in good shape now. But this problem should be noted if it leads to some other issue, elsewhere, or maybe make a note of it in the user guide so that others don't embarrass themselves as I just have. Scott -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Feature Request - Wide Graph Size
Folks, I have a small feature request. I have an issue with the wide-graph window size. Seems that I cannot reduce the size to allow it to fit on the screen the way I would like anymore. It was not an issue in RC1, but it is in the current release. My computer monitor is of rather limited size, and I like having another program up and visible on the left, but with the wide graph running on the right hand side, so I can watch for evidence of a 6m opening beginning to appear. But I can no longer shrink the wide graph to the size I need. I am working around this limitation by greatly increasing the bins per pixel to where the entire audio bandwidth is visible in the portion of the wide graph I can use, and then position the unused portion of the wide-graph window off of the right hand end of the monitor. It works, but strikes me as a rather crude workaround. Would it not be possible to set the minimum window width on the wide graph window to the number of pixels required to display the configured bandwidth at the current bins per pixel setting? This would provide a cleaner solution to this problem. Thanks for a great program that is revolutionizing six meters and weak signal communications. You guys are doing great! Regards from sunny Costa Rica, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC2 bug report
On 02/09/2017 08:41 a.m., Black Michael via wsjt-devel wrote: Settings/Frequences right-click and Reset Seems to me we need to detect this and provide a dialog to notify and reset when no frequencies are loaded. It would be super-nice if previous edits weren't lost but that's probably asking too much. de Mike W9MDB Mike, Joe, et.al., My apologies for the trouble. I'd heard about the release and had downloaded and installed it before I'd received the email from Joe via this list, and so I didn't know about the need to do the reset when upgrading from the RC1 release version I was using. So... I apologize for getting ahead of myself, Joe. But note that the reset didn't "take" on the first try. I had to do the reset per the instructions four or five times (it would appear in the frequencies window, but nothing would happen on the user interface), and had to close and restart the software twice before the drop-down frequency list finally appeared on the user interface (all that would appear on the drop-down was a frequency I had previously entered manually). So there would still appear to me to be a problem that might need some attention. If I had trouble doing the reset, others probably will too - yeah, I'm your problem child. My apologies, Joe, for not noticing your comment at the bottom of your announcement email. I'm too easily distracted. :) 73 to all, Scott -------- *From:* Scott Bidstrup *To:* wsjt-devel@lists.sourceforge.net *Sent:* Saturday, September 2, 2017 9:38 AM *Subject:* [wsjt-devel] RC2 bug report Gentlemen, I have downloaded and installed the RC2 release software, and am delighted to report that, for the most part, it is working. One problem I have noted, though, is that the drop-down frequency list, in all modes, seems to be missing in the new version (downloaded from sourceforge) - it's stuck on the last frequency I used in the old version, and can't be changed so far as I know. Mark and replace does not work, and there's nothing at all in the drop-down list in any mode to select from. Since I can't change the frequency, this is a serious problem for logging and reporting. Is there a quick and easy fix for this? Please don't tell me I'm going to have to manually enter ALL the frequencies for ALL the modes... Not sure I have that much patience. Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC2 bug report
On 02/09/2017 08:41 a.m., Ulderico Arcidiaco wrote: Scott, Please read Joe's note below: Depending on what code revision you upgrade from, it may be necessary to do a one-time reset of the default list of suggested operating frequencies. Go to *File->Settings->Frequencies*, right click on the table and select *Reset*. Thanks, Ulde. I tried that, and only after several retries, including re-starting the software twice, did that finally work - might still be a problem there that will need looking into. But I do have it working now. Thanks again. 73, Scott TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] RC2 bug report
Gentlemen, I have downloaded and installed the RC2 release software, and am delighted to report that, for the most part, it is working. One problem I have noted, though, is that the drop-down frequency list, in all modes, seems to be missing in the new version (downloaded from sourceforge) - it's stuck on the last frequency I used in the old version, and can't be changed so far as I know. Mark and replace does not work, and there's nothing at all in the drop-down list in any mode to select from. Since I can't change the frequency, this is a serious problem for logging and reporting. Is there a quick and easy fix for this? Please don't tell me I'm going to have to manually enter ALL the frequencies for ALL the modes... Not sure I have that much patience. Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Signalink USB issue
On 28/08/2017 04:23 p.m., Black Michael via wsjt-devel wrote: I've resigned myself to wait until rc2 is released for my W9MDB/QRP sign. Once the majority of users upgrade (you can see on pskreporter what versions are being used) I'll start trying again. This is why my little campaign statement in the last paragraph of my previous message, begging and pleading for a repaired -rc2 official release, sooner rather than later. I suspect that few developers on this list who are not using compound call signs, have any idea at all of what an operational issue this actually is - especially for DX stations like me, who have to deal with this problem in pileups for most of our 6m QSOs. I figure that at least a half, maybe two thirds of the QSOs I get involved with, end up taking far longer to complete than they need to (if they complete at all) because of this autoseqencing issue in -rc1. And as a result, my productivity in giving folks my country or my quite-rare grid square, is probably half or even less of what it could be. That doesn't just affect me, it affects the people who are trying desperately for my grid or my country prefix... I did a little testing over the weekend and made a couple QSOsbut it took the responders several iterations before they figured out what they had to do to continue the QSO. ...And frustration is leading to people just giving up. And not trying. Well, I am at least trying, but all too frequently not succeeding during the ultra-short 6m openings I live with at this latitude - most of the 6m openings I am trying to work, which have to be at least two hops to get anywhere with population, last three minutes or less. So conserving time and maximizing throughput is urgent. 73 to all, Scott -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Signalink USB issue
Folks, As the God-cursed holder of a compound callsign, I'm *desperate* to get off the current -rc1 release version with its compound callsign handling problems in FT8 Autosequence. I've tried a recent development version that has fixed that issue, but it failed to run, saying that input audio failed due to an "unrecognized format on device." I am using a Signalink USB interface, and I have heard from other Signalink USB users that they have had similar problems as well. I had to uninstall it and, sadly, go back to the aggravating -rc1 release version. As the problems with the compound callsign handling in -rc1 are serious for me as they are for other DX stations forced to use them, I'm desperate to get off of the -rc1 release version. They make QSOs very time consuming and confusing to the other guy, who, more often than not, does not understand what is going on. This is a serious problem when trying to handle a pileup, which I do more often than not on 6m, and often doubles, or more, the time required to complete a QSO. My question is this: Is there a build available that 1) has the compound call fix, and 2) also supports Signalink USB? If there is, I would be deeply grateful if given access to the binary so I can download and install it - and give lots more folks a rare grid square and a new country during our all-too-infrequent 6m opening pileups, than I am able to do now. I would also like to take this opportunity to campaign for an -rc2 release as soon as possible so that we can get the -rc1 version displaced among the user base, with the serious operational problems it is causing due to users who are naïve to the problem. Often as not, they'll turn on autosequence, send a reply to me, but their software won't advance the sequence, causing the same sequence to be sent over and over and over and over (for more than two minutes, till the band faded out, in once case I remember) And the offender either isn't there (assuming autosequence is going to complete his Q while he's off to work), or is totally clueless and confused as to what to do about the endless repeats... Regards to all from sunny TI, Scott Bidstrup TI3/W7RI -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
