Re: [wsjt-devel] WSJTX Cabrillo log time
Hi! Funny I had to read Alan's reply from mail archive (web), I did not get that mail at all. if you calling CQ (TX1) and someone(s) answer to it qso starts from point you start first TX2 transmission (to any of answering stations). It is very clear. There is no exchange happened yet, and your TX2 will start the exchange chain (= qso). Same if you try to answer someones CQ. Once he sends first TX2 qso begins. In case of missed TX2 receive you will get different start time than the opponent, that is true. How ever the base of qso starting definition is clear. End time of qso is more or less unclear. It is clear (by rules) when both sides have exchanged reports and got confirmation to them. You get confirmation with report as "R-xx" and you confirm it by sending "RRR" or "RR73". What I mean "unclear" is that someone requires 73 after RRR or RR73 to see the qso complete, someone else do not. There has been lot of conversation about this in past and I do not want to make another "split argue" with this. My 5 cents is that _/qso /__/start time is easier to define/_ so that all can agree with definition and should be used with Cabrillo, like it is used with CW and phone, too. How ever the periodical exchange and poor conditions can make big differences in log times. That is the thing that contest log checkers should take account when defining accepted time windows for qso checks with FT8 qsos. It is different than with CW/Phone. And it is not getting any easier of one logging program uses "time_on" and other "time_off" when producing Cabrillo log. -- Saku OH1KH Reino Talarmo via wsjt-devel kirjoitti 11.5.2023 klo 10.08: Hi Saku and Alan, I think that Alan already pointed a least indirectly that the definition of the actual start time is a bit more difficult than a defining end time. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJTX Cabrillo log time
HI! Just worked a short OH-FT8 contest that uses "NA VHF" settings with WSJT-X. I had my logging program using UDP remote connect to WSJT-X and once contest was over I created Cabrillo logs. From WSJT-X and from my logging program. Just to compare. Then I started to wonderwhy logs differ? Further investigation from WSJT-X adi log showed out that WSJT-X uses "time_off" as Cabrillo time, while my logging program uses "time_on" for it. Difference, when it happens, is usually 1-2 minutes. But if it happens, in very poor conditions, that completing qso needs many periods that time difference may grow to several minutes, I think. (Depending on used contest format. NA VHF is quite straight, while EU VHF has a period more to exchange) I checked Cabrillo definitions from wwrof.org but there seems to be no definition about QSO record time (start or end of qso). That is perhaps because in traditional CW or Phone contests the time is always QSO start time as qsos take only few seconds. FT8 world is a bit different, or is it anyway? On what bases it has been chosen that WSJT-X uses qso end time as Cabrillo time? -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles
Oh, what a sandstorm! I write once more as I got an idea that perhaps clears out, or not, way of thinking for those who are not RF experts. We all know, (do we?), what SDR rig is. Look for webSDR receives (Googling...) it gives a view if SDR is not familiar. OK! WSJT-X software turns your old war horse (rig) to a narrow band SDR receiver adding a new IF stage 200-3000Hz to it, depending your rig's audio fllter passband. WIth old rigs it can be just over 2000Hz, with new ones nearly 4000Hz. Using waterfall you can tune your SDR receiver, the green marker, to receive a certain station. As being an SDR receiver you naturally can receive also other stations over whole (audio) IF at same time. But the one you tune in by moving green marker is your receiving frequency. Same way you tune your transmitter by moving red marker. If you have "hold TX freq" checked you and set your TX where ever you want over the (audio) IF. In that case you will have a split qso where you transmit on different frequency as you receive. If you set your TX red marker over the green marker, or have "hold TX freq" unchecked when software does the TX moving, you will have normal one frequency qso, no split. The nature of SSB, as explained here, is to produce a carrier to dial frequency+audio frequency (when using USB). Properly tuned SSB rig does not send the dial frequency carrier, it is muted by balanced modulator, it sends just the dial frequency+audio frequency product. The width of carrier is the width of FT8 signal, 50Hz. Perhaps thinking wsjtx software as additional IF stage that gives also for old rig some SDR properties could be good way to approach this off topic subject. "Split operation" in settings has nothing to do with this. It is wsjt-x's "artificial intelligence" to optimize TX audio filter usage, if user allows it by selecting "rig" or "fake it". Whether or not this "artificial intelligence" is used it does not change your RX and TX tuning (red and green markers) on RF spectrum, I.E. does not cause any "split". Test with frequency counter. Your TX RFcarrier does not change when selecting "none", "rig" or "fake it". And now this subject has been done by me. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles
Sam W2JDB via wsjt-devel kirjoitti 28.4.2023 klo 15.03: Saku, split on WSJT-X means that WSJT-X can automatically adjust your frequency so that your transmit audio is always somewhere within the middle of the audio bandpass. 73, Sam W2JDB Hi Sam! Split, what Google translate says, means "divide by parts". And that it is when we are talking about split in Ham radio. I.E. Transmit on other frequency as listen, just like Reino says. When using sideband modulation (USB/LSB) the RF frequency is tied to audio slot frequency. That is: dumped RF carrier +/- audio frequency depending on sideband used. If we change audio slot we change RF frequency that means we are using "split" in means what is in Ham radio. Using the thoughtlessly named "split operation" of wsjt-x/settings/radio has NO effect to RF frequency that is produced. It is always the same as "split operation", when used, adjusts the ratio of RF carrier to audio frequency to keep the produced RF frequency always the same while centering the audio frequency in middle of AF filter passband. Better would have been to call "settings/radio/split operation" as: "Optimize audio passband": none, using 2 vfos, adjust 1 vfo That would have been less confusing, just like Jim says. But that was not the subject after all. We were talking about the benefits of having randomized frequency on TX1 and TX6. Reino states that using random TX could prevent neighbor station to complete his DX qso. Well, I do not think so. TX1 and TX6 jumping may disturb neighbor, but only one time. Next transmit is again on different frequency. Unless the qso is established and TX locked. But that is life. It is not worse than losing DX because band polices "trying to keep DX frequency clear" causing most qrm by them self. And usually very close neighbors are using same period for TX when there is no harm at all. That is the best benefit of FT8 DXing: keeping the TX periods organized, mostly. There always are someones that think that transmitting on other period than others could catch DX better. Ok, now the original subject is splitting again. Best to QRT. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles
How do you know that? Perhaps on low bands but higher HF bands you can not hear others near by. Besides most of qsos are running "split" Station A on different audio frequency slot as opponent B. I would rather see improvement where CQ (TX6) and answer to CQ (TX1) would be randomized. So that every CQ, or every try to answer other's CQ would happen on different audio slot. If qso is established then TX audlo would be locked to current audio slot for qso. -- Saku OH1KH Jim Brown via wsjt-devel kirjoitti 28.4.2023 klo 0.53: Likewise, if we call CQ (or another station) for more than a few calls without a response, it's good operating practice to pause for at least one cycle to check what's happening on your frequency. 73, Jim K9YC ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] UDP Status #1 message while typing DX call (bug?)
Laurie, VK3AMA via wsjt-devel kirjoitti 21.2.2023 klo 13.06: This is not a bug. WSJT-X has always behaved this way, emitting a UDP status message with each character typed. I would not like to see this long-standing behavior changed. de Laurie VK3AMA (JTAlert author) Like always; I guessed that! What is set in stone, stands there. I do highly prefer backward compatibility, but but fixing this does not break anything. I expect nobody is interested in partial callsigns. There is also another "feature" that is not so nice. (but I know it is also set in stone and I do not expect this to be fixed. Just want to show it too) If you send UDP #4 or #15 to set new target call status #1 will first reply with old call and immediate after that the new call that was set Getting Call : by UDP #1 Getting Call : by UDP #1 *Settting call: IU8CFX by UDP #4 * <--setting new target call /Getting Call : by UDP #1/**the immediate response is *existing old call* *Getting Call :IU8CFX by UDP #1***right after that comes the call that was set** Getting Call :IU8CFX by UDP #1 Getting Call :IU8CFX by UDP #1 Getting Call :IU8CFX by UDP #1 Getting Call :IU8CFX by UDP #1 Getting Call :IU8CFX by UDP #1 Getting Call :IU8CFX by UDP #1 *Settting call: JE8VZK by UDP #4* <--setting new target call /Getting Call :IU8CFX by UDP #1/ **the immediate response is *existing old call** **Getting Call :JE8VZK by UDP #1* right after that comes the call that was set Getting Call :JE8VZK by UDP #1 Usually clients do response either with ACK or echoing the sent message. At least in industrial world that I used to while still working. Due to these the companion program must fix things with timeout timers to guess when proper responses are available from wsjt-x. -- -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] UDP Status #1 message while typing DX call (bug?)
Hi! Found annoying property of UDP Status (#1) message. If you enter new callsign to DXCall column the new status message is sent after every letter you type. This makes receiving program very hard to decide when there is complete callsign available. (needs timeout routine because of this) I do not know if same happens with DXGrid (not tested, because not needed grid now). Assume it can happen too. Expected status message with entered callsign to be *generated when cursor leaves* DXCall column. Not before. Thank you! -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 3Y0J F/H operation - was my "R+rpt" report received ?
That may also depend on RX tuning. If you put VFO a bit off from reported frequency the audio will appear in different place. I do often tune a bit off to get Fox little bit higher in audio for better copy. And for the three times R without RR73 and move to higher frequency (below 1kHz): Qso is still possible. I have had some Foxes not hearing my R and then I was moved up but kept giving R for some time (not very long). With good results; the RR73 has come after a while. I do not know if this requires something from Fox operator, but anyway I have got proper qso then (no luck with 3Y0J at all). -- Saku OH1KH Fred Carvalho via wsjt-devel kirjoitti 17.2.2023 klo 20.52: John is right. I have never seen 3Y0J transmitting that high. He was actually below (300-400Hz). ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 3Y0J strange F/H operation
Jim Shorney via wsjt-devel kirjoitti 16.2.2023 klo 15.05: So you do the best you can with what little you have. Who knows, maybe their GPS was in one of the boxs left on the boat. It seems unfair to criticize when none of us was there. No critics, done what was possible. How ever it seems to be that it was hard to find out just period sized time drift. I assume they had some kind of communication between boat and camp. Perhaps 2m. Boat has Gps for navigation. And from that you can see the time within one second. It would not be too hard to give time from boat to camp via radio and then manually set PC clock. Accuracy within one second. (enough). But I am sure they had enough other things to think about. On the other hand it was very easy to enable "Tx Even/1st" checkbox in hound mode and recompile. After that no problem with wrong period. (still no qso...) -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Logging of mixed data if you do QSO with two stations
Marco Calistri via wsjt-devel kirjoitti 15.2.2023 klo 22.17: Yeah! HI! Cqrlog wsjtx-remote can support only one remote wsjtx at time. Using multicast UDP I think you can have several wsjtxs sending to Cqrlog, but you have already found the problem that arises. The remote code is very primitive and about 5 years old. SomeOne™ should rewrite it if new features are needed. How ever you can have a workaround using own Cqrlog for every wsjtx you are running. They all can use same MariaDB log database that should handle multiple SQL users (Cqrlogs). Do not use UDP multicast, instead use localhost IP and own port definition for every Cqrlog-Wsjtx pair that are running. That should do the trick, I think. (not tested). How ever there are some settings that may do things easier, but this mailing list is not the place to go them through. Off topic: Cqrlog has no accepted pull requests since Aug 2022. I can only guess the reasons. My Alpha test version, "loc_testing" (in my GItHub) is now 209 commits ahead of official source. This means that code is on edge. Getting official version in sync with Alpha begins to be too big job. That's why I have stopped to add latest fixes as pull requests to official because the code difference is too big. They appear only in my Alpha that I am using here locally. Cqrlog is for Linux, not for Windoze. But it is open source, so it is free for W-programmers to try. I do not have any Windozes in house. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Who was I working with???
Hi! Very strange qso in 10m with J8/AJ4YX. Or was it really AJ4YX after all? -Fedora 37 -Wsjtx 2.6.1 (compiled from source) -rigctl Hamlib 4.6~git tammi 19 05:32:18Z 2023 SHA=268f44 (compiled from source) -ICOM IC7300 The callsign of AJ4YX varied as <...>, , and in ALL.TXT and screen. Who I actually was working with? And in addition ALL.TXT says that I was receiving on 28.026MHz and Transmitting on 28.091MHz ! You can see ALL.TXT, printscreen and wsjtx log and adi all in same pdf at: https://drive.google.com/file/d/1BA5_55PpZArKEqLdd-nLvEIw-44ml8fJ/view?usp=share_link -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.6.0-rc5 reporting
I just wonder... We did qso on 144.150 (qsy by vfo knob). After qso I moved back to 144.174 that is saved to wsjtx/frequencies. Because wsjtx sends heard calls to pskreporter as a "block" time to time I think the sending happened after our qso when I was again back on 144.174 I just wonder did it catch frequency from that moment, not at time when qso was held on 144.150 Note the difference frequencies, it is bigger than vfo +(-) audio frequency can produce. Andrew Neumeier via wsjt-devel kirjoitti 23.12.2022 klo 16.44: Saku, My experience has been that pskreporter displays the frequency as received by the receiving station. So, this would be display frequency plus the audio frequency used for the qso. Sometimes the two are not the same, for instance, your transmit frequency and that of the other station may differ. This is because of small differences in frequency of the rigs used during the qso. Also, on 144Mhz, some folks, like me, use a transverter to put them on 2 meters. My transverter is always a little off frequency. I've seen no difference in the reporting frequencies no matter the version of WSJT-X. Hope this helps. 73, Andy, ka2uqw -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] 2.6.0-rc5 reporting
Hi! I worked a local qso on 144.150 using FT8 (that was displayed on WSJT-X frequency reading) Afterwards I looked at pskreporter where both our calls were reported on 144.175 I.E. frequency that was stored WSJT-X band quick settings (144.174) + audio frequency. Now question is: Does reporting use stored quick setting frequency or true frequency that is received via CAT ? In case of former one: Is this bug or not? Wsjtx-rc5 Fedora 35 IC706 -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.6.0-rc5
Builds and runs also in Fedora36 /LXDE but now main window is even wider than before. And there is no way to make it narrower after startup as before, except when HOUND mode is selected. Then it can be set as narrow as rc4, but when returning from HOUND it gets wider again and does not allow resizing. Graphics is getting worse direction now! -- Saku OH1KH Josh Rovero via wsjt-devel kirjoitti 30.11.2022 klo 0.15: Builds and runs fine on Fedora Core 37 Linux, 64-bit. And the ALL_WSPR.TXT incorrect transmit band issue looks like it's fixed. -- P.J. "Josh" Rovero http://www.roveroresearch.org Ham Radio: KK1D ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Feature request: Contest name
HI Larry! I am a Linux user. I worked last 15 years with Windoze servers and clients versions up to W7. When retired I do not have any need to touch them any more. Linux has Wine, but I do not have any need to run Windoze programs via it. Cqrlog has it all. And what it does not have I can program to it. Now it is just a question that if user could define a contest name at WSJT-X end and that would be transferred via UDP datagram to external logging program there would be no need to fix those entries in log later on. Now the UDP datagram sends those default, fixed, contest names that are in "settings/Advanced/Special operating activity". Of course I could fix this at Cqrlog's side with few lines of code, but I prefer that the origin of qso data (I.E. WSJT-X) should offer this as user defined option. It already has fields like "operator" and "Propagation mode" , so why not "contest name" ? (This will be my last reply of this subject for this list. PM to continue discussion) -- Saku OH1KH Larry Banks via wsjt-devel kirjoitti 14.10.2022 klo 16.23: Hi Saku, It is much easier to use a proper contest logging program. There are many out there. I use the programs from N3FJP -- they are easy to set up and use. They do everything you need. Larry / W1DYJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Feature request: Contest name
HI Jim! No Windozes in house. I use Cqrlog for logging and at the moment WSJT-X is sending a contest name in UDP logging frame to Cqrlog that can not be defined. That's why I always need to fix contest names of FT8 qsos afterwards with Cqrlog's group edit to be similar with all other modes used in contest. It would be lovely to define correct name already at WSJT-X logging window and retain that. Jim Brown via wsjt-devel kirjoitti 14.10.2022 klo 12.13: Hi Saku, There are logging programs that keep track of contests. I log contests with N1MM+ (Freeware), export the log to DXKeeper (FREEware), choose from a dropdown menu in the DXKeeper Import screen what contest it's from and choose the log file. That's all it takes! And when you're ready to upload to LOTW, eQSL, or ClubLog, DXKeeper does that with a button-push once you've set yourself up those logging sites. I suspect that other logging programs also do some or all of this; I have more than 300,000 QSOs in DXKeeper since getting back on the air in 2003. 73, Jim K9YC -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Feature request: Contest name
Hi! Sorry if this feature exist. I did not find a mention about it from user guide. There are now several contests that use WSJT-X contest modes. It would be nice to have user defined contest name to logging window. That way name logged (also via UDP message) could be set by contest. And maybe also add a date to name if several contests are kept in same external log making them easier to find by the name of contest. Just worked contest "NAC-6m_10/2022" that uses EU VHF mode. So my external log has now contest name "NAC-6m_10/2022" with all CW and SSB qsos, but "EU VHF" with FT8 qsos that have to be changed manually afterwards. Good place for contest name would be either: Make "operator" column smaller and set "contest name" after that on right side. or Below "propagation mode". In both cases "retain" checbox is needed too. Thanks! -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Second wsjt-x2.6.0-rc4-Linux64 Hound issue
(second try to send this message. 1st one did not show up on list) Hi! Found also another issue: If wsjt-x is closed with Hound-mode running the *next start will activate hound-mode again* (tested that by setting TX under 1000Hz and started TX. It jumped random ove 1000Hz) *but the mainwidow view is mixed*. Red "hound" text stays there, but there is also "Hold TX frequency" visible. In addition to that the button "H" is not colored as should. Pressing "H" button will color it and also remove "Hold TX frequency". Tested that with clean start to be sure that any of my settings could effect that: wsjtx -r testing Then set callsign, locator,rig,audio and hound mode on. Out of settings -> stopped wsjtx Started again: wsjtx -r testing View can be repeated. Fedora release 35 (Thirty Five) wsjt-x2.6.0-rc4 self compiled, source from https://git.code.sf.net/p/wsjt/wsjtx (same day as Hamlib below) rigctl Hamlib 4.5~git fri sep 16 13:33:51 2022 + SHA=b1d132 -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x2.6.0-rc4-Linux64 Hound issue
OH1MRR suggested that because FH/OK1M does use pure wsjt-x it causes the problem. Could be he is using other software, but as far as I can understand mainwindow.ccp lines 3930 - 3960 do not care is the Fox true fox or mshv. If that is the reason, then the problem lays somewhere else in code. 3930 - 3960 should pass it ok through. But as said my C is not very good, and I have not followed the whole receiving chain yet. I sent another bug report too. But it is not passed to devel list. At least yet. It had small screen part capture included. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x2.6.0-rc4-Linux64 Hound issue
Black Michael kirjoitti 18.9.2022 klo 16.59: I think it's because your callsign is being hashed and the logic is not allowing for a hashed callsign. This section removes hash marks from the foxCall -- but not my_callsign. I had plain call OH1KH (or OH1KJ) there. When my call is hashed it is done by wsjt-x and as far as I can see it does not affect to this bug. If wsjt-x generates them for me it should not effect the start of reply to Fox or ending the qso because then fox is hashed, *not mycall. * 220918_114600 21.091 Rx FT8 -15 0.8 443*OH1KJ -14 < that is when wsjt-x should react and start my TX3* 220918_114600 21.091 Rx FT8 -16 0.8 382 FH/OK1M RR73 220918_114615 21.091 Tx FT8 0 0.0 2113 OH1KJ KP01 *220918_114619 21.091 Tx FT8 0 0.0 2113 OH1KJ R-15 < here clicked rx line to get TX3 running So it is not so easy as you say. I have found the part of code where FOX call is srtipped from "< >". But this Fox call has still slash after stripping. How ever it looks that at the part of stripping "< >" does not look slash existence there. Could it be in somewhere else than between mainwindow.ccp lines 3930 - 3960 that makes TX3 start / stop fail? -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Second wsjt-x2.6.0-rc4-Linux64 Hound issue
Hi! Found also another issue: If wsjt-x is closed with Hound-mode running the *next start will activate hound-mode again* (tested that by setting TX under 1000Hz and started TX. It jumped random ove 1000Hz) *but the mainwidow view is mixed*. As you can see red "hound" stays there, but there is also "Hold TX frequency" visible. In addition to that the button "H" is not colored as should. Pressing "H" button will color it and also remove "Hold TX frequency". Tested that with clean start to be sure that any of my settings could effect that: wsjtx -r testing Then set callsign, locator,rig,audio and hound mode on. Out of settings -> stopped wsjtx Started again wsjtx -r testing View can be repeated. Fedora release 35 (Thirty Five) wsjt-x2.6.0-rc4 self compiled, source from https://git.code.sf.net/p/wsjt/wsjtx (same day as Hamlib below) rigctl Hamlib 4.5~git fri sep 16 13:33:51 2022 + SHA=b1d132 -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x2.6.0-rc4-Linux64 Hound issue
OK1M HL5NBM PM45 220918_114745 21.091 Rx FT8 -7 1.0 2705 JH7RTQ QM07 Black Michael via wsjt-devel kirjoitti 18.9.2022 klo 15.18: Can you post the relevant section of ALL.TXT with your QSO data including all the other decodes around that too? Mike W9MDB On Sunday, September 18, 2022 at 07:11:56 AM CDT, Saku via wsjt-devel wrote: Hi! Just worked FH/OK1M on 21.091 using hound mode. After called a while I got answer, but wsjtx just continued calling. I had manually click on the received report line and after that wsjtx moved to proper TX frequency and started to give R-report. When I got RR73 wsjtx just continued to send R-report and had to stop manually. After that I closed wsjtx, compiled it again (without my own patches) and worked FH/OK1M again with my XYL's callsign. Just same errors then, as expected, bug is not in my patches that do not effect this part of operation. I assume bug lays somewhere in the original source code. Those who can do better with C should look the code. I have feeling that I have seen similar error report somewhere with earlier wsjt-x versions. Fedora release 35 (Thirty Five) wsjt-x2.6.0-rc4 self compiled, source from https://git.code.sf.net/p/wsjt/wsjtx (same day as Hamlib below) rigctl Hamlib 4.5~git fri sep 16 13:33:51 2022 + SHA=b1d132 -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] wsjt-x2.6.0-rc4-Linux64 Hound issue
Hi! Just worked FH/OK1M on 21.091 using hound mode. After called a while I got answer, but wsjtx just continued calling. I had manually click on the received report line and after that wsjtx moved to proper TX frequency and started to give R-report. When I got RR73 wsjtx just continued to send R-report and had to stop manually. After that I closed wsjtx, compiled it again (without my own patches) and worked FH/OK1M again with my XYL's callsign. Just same errors then, as expected, bug is not in my patches that do not effect this part of operation. I assume bug lays somewhere in the original source code. Those who can do better with C should look the code. I have feeling that I have seen similar error report somewhere with earlier wsjt-x versions. Fedora release 35 (Thirty Five) wsjt-x2.6.0-rc4 self compiled, source from https://git.code.sf.net/p/wsjt/wsjtx (same day as Hamlib below) rigctl Hamlib 4.5~git fri sep 16 13:33:51 2022 + SHA=b1d132 -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] transmission by udp
It has it's sides... I have monitor in Cqrlog where every decoded transmission (CQ or qso) is compared against my log. Callsigns and grids are color coded by working status (this band, other band, other mode , never) and it also shows decodes including ongoing qso in brackets. With earlier version of wsjtx I was able to "preload" std messages by double click on line with decode in brackets and be polite not disturbing the qso and also not loading already crowded frequency. Then fire my TX when ongoing qso is ending. Now I have to uncheck "Hold TX frequency" first then double click and then check "Hold TX frequency" again to make same thing. Well, I think I have to look how I can restore old behavior. C is no my strongest languages but I think I can do it with some testing. A thing to do during cold dark winter days. Black Michael via wsjt-devel kirjoitti 17.8.2022 klo 15.45: That change also makes working with JTAlert and such programs MUCH more friendly. Don't throw the baby out with the bath waterif some actor wants to create a bot just ignore them Mike W9MDB On Wednesday, August 17, 2022 at 01:03:44 AM CDT, Saku via wsjt-devel wrote: Hi! BTW, now version 2.6.0rc2 has property that if "Hold TX frequency" is checked sending an UDP frame created from decode of station keeping QSO can start TX. Previously it just "preloaded" Std. messages and moved RX to station frequency but did not fire transmitter. I see this as bad thing as it is now very easy to create an external program that checks log and if callsign or locator is not in log start calling and make automated qso that way. I hope it will be returned back as it was before v2.6 -- Saku OH1KH Carey Fisher via wsjt-devel kirjoitti 17.8.2022 klo 1.28: Hopefully, no one here will help you develop a WSJTX bot. On Tue, Aug 16, 2022 at 5:39 PM eduardo via wsjt-devel <mailto:wsjt-devel@lists.sourceforge.net>> wrote: I am developing a program in php -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] transmission by udp
Hi! BTW, now version 2.6.0rc2 has property that if "Hold TX frequency" is checked sending an UDP frame created from decode of station keeping QSO can start TX. Previously it just "preloaded" Std. messages and moved RX to station frequency but did not fire transmitter. I see this as bad thing as it is now very easy to create an external program that checks log and if callsign or locator is not in log start calling and make automated qso that way. I hope it will be returned back as it was before v2.6 -- Saku OH1KH Carey Fisher via wsjt-devel kirjoitti 17.8.2022 klo 1.28: Hopefully, no one here will help you develop a WSJTX bot. On Tue, Aug 16, 2022 at 5:39 PM eduardo via wsjt-devel wrote: I am developing a program in php -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Watchdog timer for F/H?
This is interesting. It seems that my ISP is dropping some mails (not even in trash folder) and I have missed the beginning of this chain. But to the subject: Timer is good, but I have suggested (without any comment) few times to randomize hound transmit frequency. That would keep "big guns" in move and maybe give change for smaller stations to get free slot for every now and then. The code is there already. I have done "rndHound" for myself with just few additional lines. Works fine and randomizes my transmit frequency for every period. With checkbox user could select to sit on same frequency all the time, or randomize it for every calling period. When QSO is established it works like before selecting the slot where Fox replies below 1000Hz. Randomize does not have effect for ongoing QSO. Gary McDuffie via wsjt-devel kirjoitti 29.7.2022 klo 0.10: You’re talking about defeating the timer, which is there for a reason. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] V. 2.6 Error and Crash
I can also confirm sudden crash of wsjtx where JT9 process left running. It did happen when I was playing with new mode buttons. I pressed several buttons during one receive period and suspect that caused the crash. How ever I could not reproduce it any more after restart. My setup is Fedora 35 Dennis W1UE via wsjt-devel kirjoitti 28.7.2022 klo 3.39: Mike I wrote this up and submitted it a week ago. I could not find any sequence of events to cause the WSJT window to suddenly close. I found it took anywhere from 15min to 3 hrs between crashes. I also get a TCP error when it closes, as I have wsjt mated to N1mm+ for logging. Dennis W1UE On Wed, Jul 27, 2022 at 20:26 mpcorey--- via wsjt-devel wrote: So I posted to this list a few weeks ago about the problem with 2.6rc1 suddenly crashing, and to restart ending a JT9 process through task manager. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.6.0-rc2
It seems that: https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.6.0-rc2.tgz and git clone https://git.code.sf.net/p/wsjt/wsjtx differ. Both source's release notes are talking about "-rc2" but there are differences in source contents in several files. Assuming git is not fully up to date. (But has parts of rc2, at least Release notes ;-). Saku via wsjt-devel kirjoitti 23.7.2022 klo 15.59: HI! With Fedora 35: git clone https://git.code.sf.net/p/wsjt/wsjtx and after that making compile gives: -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.6.0-rc2
HI! With Fedora 35: git clone https://git.code.sf.net/p/wsjt/wsjtx and after that making compile gives: Rick via wsjt-devel kirjoitti 23.7.2022 klo 11.02: Hi Jarmo, I compiled from sources too. Worked OK for me Check your install. Rick (GM4JIB)On 23/07/2022 08:15, jarmo via wsjt-devel wrote: Don't know, if anyone else have this, but compiled wsjtx from wsjtx-2.6.0-rc2.tgz. Still, when starting wsjtx I get wsjtx-2.6.0-rc1??? What I'm missing??? Jarmo, oh1mrr ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
No... It does not work. Pulled a few moments ago: [saku@hamtpad ~]$ rigctld --version rigctl Hamlib 4.5~git ma kesä 06 15:16:37 2022 + SHA=037384 Here you see what happens: "split - rig", "Allow frequency changes while transmitting" checked. Icom 7300 https://drive.google.com/file/d/1UnAzY5DiJAs53iko-xRWERWm0pk7Njw9/view?usp=sharing Starting with TX around 500 makes rig freq 50.311,5. Then moving TX to 2800 that moves WSJTX display to 50.314.0 but rig freq stays 50.311,5 After TX period ends WSJX shows 50.313.0 as should, but rig jumps now to 50.314.0 that it should have done when audio moved 500->2800 while TX, not now when RX period is started. This is worse now as before rig did move while transmitting, but return to RX went to wrong frequency. (1 bug) Now rig does not move while transmitting and return to RX goes still wrong. (2 bugs) -- Saku via wsjt-devel kirjoitti 4.6.2022 klo 9.17: Yep! I have it. I will make pull after weekend and see what that brings. Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 19.50: You can get the absolute latest with git clone git clone https://github.com/Hamlib/Hamlib.git Mike W9MDB -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Yep! I have it. I will make pull after weekend and see what that brings. Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 19.50: You can get the absolute latest with git clone git clone https://github.com/Hamlib/Hamlib.git Mike W9MDB -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
No can do... :-D Fedora 35, no Windozes in this house. Last tested version was: hamlib-4.5~git-a468f0de-20220603.tar.gz Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 16.39: In that case please use this DLL and send me the debug log as described below. https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0 Please place this file as described below https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0 C:\Users\[username]\AppData\Local\WSJT-X The WSJT-X_Rigcontrol.log file will be in the same location For Linux put it in ~/.config The WSJT-X_Rigcontrol.log file will be here: ~/.local/share/WSJT-X Restart WSJT-X and duplicate the problem. Shut down WSJT-X Then send me the WSJT-X_RigControl.log file Mike W9MDB On Friday, June 3, 2022, 08:33:18 AM CDT, Saku via wsjt-devel wrote: Sorry but it does not work. It is even worse. Interesting side effect was that after installing new Hamlib ic7300 lost output power when rigctld was started from scirpt before wsjtx. Even rebooting pc did not restore power. When killed rigctld from script and set wsjtx to use icom7300 serial USB instead of Net Hamlib rigctld I got output power back. After that changed wsjtx back to Hamlib rigctld and started rigctld from script output power was normal. Perhaps resetting ic7300 would do the same (?) (I have feeling this has happened sometimes before and fixed in same way) But to the point. Now when moving TX Hz from waterfall from edge to another while transmit is ON the wsjtx frequency display changes but rig's display does not change. And when RX period starts rig stays on TX frequency that was at the beginning of TX period, not the one it was moved during TX. Before: Rig TX frequency changed, but RX was at last TX frequency (at the end on TX period) Now: Rig TX frequency does not change, while wsjtx frequency display changes, and RX is at first TX frequency (at the start of TX period) Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 15.09: It has been fixed. http://n0nb.users.sourceforge.net/ <http://n0nb.users.sourceforge.net/> Mike W9MDB On Friday, June 3, 2022, 05:03:29 AM CDT, Kari Sillanmäki via wsjt-devel <mailto:wsjt-devel@lists.sourceforge.net> wrote: Hi Saku, Michael, Mike et al I can duplicate this behaviour reported by Saku on my 7300. I'm using the rigctld-wsjtx bundled with WSJT-X 2.5.4 source tarball on Ubuntu 18.04.6 LTS. This seems to be a defect in hamlib; RX-frequency should always stay put. 73's de Kari, oh2gqc On 3.6.2022 10.58, Saku via wsjt-devel wrote: Subject: Re: [wsjt-devel] Hamlib testing From: Saku via wsjt-devel <mailto:wsjt-devel@lists.sourceforge.net> Date: 3.6.2022 klo 10.58 To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> CC: Saku <mailto:oh...@sral.fi> Hi Michael ! Could you test with your IC-7300 this way: set "split rig" and check "Allow TX frequency changes while transmitting" in settings/general tab Set your TX around 300Hz by shift+left click on waterfall. Start TX period and while your TX is on move your TX around 2800Hz by shift+left click on waterfall. When TX period is over does your RX return to selected (from band selector) frequency? Mine does not, it gets the TX (vfoB) frequency that must then be corrected with band selector back to right RX frequency. This happens if I have settings/Radio configured as ICOM 7300, or if I have started rigctld with script before starting wsjtx and then using Hamlib Net rigctld/localhost:4532 in settings/Radio. Both ways same result. OS is Fedora 35 linux. -- Saku OH1KH 5p1kzx Michael via wsjt-devel kirjoitti 2.6.2022 klo 18.32: Hi Everyone I have tested new the Hamlib with WSJT-X and JTDX in RIG and Fake It. I tested it with IC-7300, IC-7000 and IC-706Mk2g - behaviour as expected and no problems so far. 73 de Michael 5p1kzx ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Sorry but it does not work. It is even worse. Interesting side effect was that after installing new Hamlib ic7300 lost output power when rigctld was started from scirpt before wsjtx. Even rebooting pc did not restore power. When killed rigctld from script and set wsjtx to use icom7300 serial USB instead of Net Hamlib rigctld I got output power back. After that changed wsjtx back to Hamlib rigctld and started rigctld from script output power was normal. Perhaps resetting ic7300 would do the same (?) (I have feeling this has happened sometimes before and fixed in same way) But to the point. Now when moving TX Hz from waterfall from edge to another while transmit is ON the wsjtx frequency display changes but rig's display does not change. And when RX period starts rig stays on TX frequency that was at the beginning of TX period, not the one it was moved during TX. Before: Rig TX frequency changed, but RX was at last TX frequency (at the end on TX period) Now: Rig TX frequency does not change, while wsjtx frequency display changes, and RX is at first TX frequency (at the start of TX period) Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 15.09: It has been fixed. http://n0nb.users.sourceforge.net/ Mike W9MDB On Friday, June 3, 2022, 05:03:29 AM CDT, Kari Sillanmäki via wsjt-devel wrote: Hi Saku, Michael, Mike et al I can duplicate this behaviour reported by Saku on my 7300. I'm using the rigctld-wsjtx bundled with WSJT-X 2.5.4 source tarball on Ubuntu 18.04.6 LTS. This seems to be a defect in hamlib; RX-frequency should always stay put. 73's de Kari, oh2gqc On 3.6.2022 10.58, Saku via wsjt-devel wrote: Subject: Re: [wsjt-devel] Hamlib testing From: Saku via wsjt-devel <mailto:wsjt-devel@lists.sourceforge.net> Date: 3.6.2022 klo 10.58 To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> CC: Saku <mailto:oh...@sral.fi> Hi Michael ! Could you test with your IC-7300 this way: set "split rig" and check "Allow TX frequency changes while transmitting" in settings/general tab Set your TX around 300Hz by shift+left click on waterfall. Start TX period and while your TX is on move your TX around 2800Hz by shift+left click on waterfall. When TX period is over does your RX return to selected (from band selector) frequency? Mine does not, it gets the TX (vfoB) frequency that must then be corrected with band selector back to right RX frequency. This happens if I have settings/Radio configured as ICOM 7300, or if I have started rigctld with script before starting wsjtx and then using Hamlib Net rigctld/localhost:4532 in settings/Radio. Both ways same result. OS is Fedora 35 linux. -- Saku OH1KH 5p1kzx Michael via wsjt-devel kirjoitti 2.6.2022 klo 18.32: Hi Everyone I have tested new the Hamlib with WSJT-X and JTDX in RIG and Fake It. I tested it with IC-7300, IC-7000 and IC-706Mk2g - behaviour as expected and no problems so far. 73 de Michael 5p1kzx ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Hi Michael ! Could you test with your IC-7300 this way: set "split rig" and check "Allow TX frequency changes while transmitting" in settings/general tab Set your TX around 300Hz by shift+left click on waterfall. Start TX period and while your TX is on move your TX around 2800Hz by shift+left click on waterfall. When TX period is over does your RX return to selected (from band selector) frequency? Mine does not, it gets the TX (vfoB) frequency that must then be corrected with band selector back to right RX frequency. This happens if I have settings/Radio configured as ICOM 7300, or if I have started rigctld with script before starting wsjtx and then using Hamlib Net rigctld/localhost:4532 in settings/Radio. Both ways same result. OS is Fedora 35 linux. -- Saku OH1KH 5p1kzx Michael via wsjt-devel kirjoitti 2.6.2022 klo 18.32: Hi Everyone I have tested new the Hamlib with WSJT-X and JTDX in RIG and Fake It. I tested it with IC-7300, IC-7000 and IC-706Mk2g - behaviour as expected and no problems so far. 73 de Michael 5p1kzx ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Hi Mike!
I have been using version that I have downloaded from Git on 2022-03-18
It has a problem that seems to be also in this latest version.
Fedora 35 linux
Wsjt-x v2.5.4 d28164-dirty
Icom Ic 7300
I am starting rigctld from script with:
mypath=/usr/local/bin/
myrigctld=rigctld
myvfo='--vfo'
start_rig (){
start_rig1
start_rig2
}
start_rig1 (){
echo -n "IC7300 start " >> /tmp/start.log
/usr/bin/date >> /tmp/start.log
$mypath$myrigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200
-C auto_power_on=0 $myvfo &
Then at WSTX settings I use rig Net Hamlib rigctld localhost:4532, split
rig.
Everything seems to work ok (as earlier version) except that if wsjtx
has started TX period and then I move tx frequency with Shift+left mouse
it moves ok but when RX period comes back rig's vfoA stays on TX
frequency and does not come back to RX frequency.
This happens only if you are a bit too late moving TX frequency I.E. TX
period has already started. If you do it before TX period starts it
moves ok and RX vfoA stays on rx frequency as should.
I have not bothered to report that because it is a marginal bug and can
be avoided by not moving TX when transmit is on, or return right RX
frequency right after TX period ends (if TX frequency was moved) using
band selector.
This is only "split rig" problem, and there only then when TX frequency
differs from RX (I.E. on both ends of band slot)
Black Michael via wsjt-devel kirjoitti 31.5.2022 klo 19.04:
I need everyone to test the latest Hamlib
Testing in Rig Split and Fake It would be appreciated.
Successes/Failures please report.
New hamlib for installation directions
#1 Shut down WSJTX/JTDX
#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit
version of WSJTX/JTDX -- hopefully your browser doesn't block it but
may warn you multiple times.
If you can do a "Save As" you can save it directly in \WSJT\WSJTX\bin
and replace the libhamlib-4.dll that is there.
http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll
http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.net/
#3 If you don't save directly you need to open a file browser and move
the file that way.
If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk
Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Saku
OH1KH
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Hound operation fails.
Hi! Is <3X2021> one of then calls where Hound qso fails? Nothing done here, other Hound qsos are gone well before but not this one. Wsjx did not notice he answered to me. Just continue calling. When I finally understood to push T3-button at right time I got RR73 but even then my Hound just continued to give R-report. Halted TX and logged qso. Fedora35, WSJT-X v2.5.4 d28164-dirty -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!
Hi Marco! Reason that you could not get it working with my suggestion below, and needed "-a" is written here: "il file binario corrisponde". Bash thinks ALL.TXT is a binary file. How ever a clean ALL.TXT is pure text file and grep can handle it directly. Maybe your WSJT-X has crashed some day in past during the write of ALL.TXT and there are some "hieroglyphs" written to file that makes grep think it is a binary file. As seen your ALL.TXT size I suggest you move the file. cd ~/.local/share/WSJT-X mv ALL.TXT ALLOLD1.TXT WSJT-X then opens a new ALL.TXT on next start. Then you can make more ALLOLDx files, monthly, or by yearly basis. Depending how much you use WSJT-X. -- Saku OH1KH Saku via wsjt-devel kirjoitti 19.2.2022 klo 10.01: i I Think you were using linux. Then open command console and: cd ~/.local/share/WSJT-X grep -ni HisCall ALL.TXT | grep -i YourCall Shows qso in fast and easy way (with line numbers of ALL.TXT). Just replace the callsigns in command. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!
Hi I Think you were using linux. Then open command console and: cd ~/.local/share/WSJT-X grep -ni HisCall ALL.TXT | grep -i YourCall Shows qso in fast and easy way (with line numbers of ALL.TXT). Just replace the callsigns in command. Jim Shorney via wsjt-devel kirjoitti 19.2.2022 klo 6.57: You should be able to find this in your all.txt file. 73 -Jim NU0C On Sat, 19 Feb 2022 01:46:13 -0300 Marco Calistri via wsjt-devel wrote: I asked to the DX station's QSL manager if he can send me the details of the QSO (Time and RST) registered by the Fox station on his ClubLog, so hopefully I could manually include the QSO also into my log. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] "Pwr" Slider Acting Goofy in WSJT-X v2.5.4
HI Tony! Have you tried to move mouse cursor on Pwr slider, not click at all, but use mouse roll to move slider instead? Anthony Hackenberg via wsjt-devel kirjoitti 12.2.2022 klo 0.05: However, the minute I mouse click on that slider's position, the slider's pointer jumps down to the bottom -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.5.4 GA Release
Joe Taylor via wsjt-devel kirjoitti 3.1.2022 klo 18.54: You can also download the packages from our SourceForge site: https://sourceforge.net/projects/wsjt/files/ It may take a short time for the SourceForge site to be updated. Is the [remote "origin"] url = https://git.code.sf.net/p/wsjt/wsjtx fetch = +refs/heads/*:refs/remotes/origin/* not in use any more? "git pull" gives: "Already up to date" there and it is over month since last "git pull" was issued. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] TX mode change bug (?)
Hi! OS Fedora 35 rig Icom ic 7300 Hamlib self compiled Hamlib 4.5~git ti joulu 14 22:54:46 2021 + SHA=db3837 Wsjtx self compiled WSJT-X v2.5.3 69f9ec-dirty Hamlib started from script: rigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0 --vfo & Wsjtx settings: Hamlib NET rigctl / 127.0.0.1:4532 / PTT CAT / Mode DATA/Pkt / Split Rig - Noticed just that if VFO B has been used for any other mode than USB-D Wsjtx will not change the mode when it starts transmitting. When band is changed from selector VFO A goes to that band: When QSO or CQ is started, or Tune pressed, VFO B is activated and set to same band, but VFO B mode is not touched. It must be set manually from rig panel. Easily reproduced. Closing Wsjtx or switching bands does not make any difference. -- Another problem, but hard to reproduce, is that randomly the RX VFOA takes frequency from recently used in TX VFOB. So RX jumps to frequency that was used while transmitting. This does not happen always and so far I have not found any procedure to make it happen every time. User just must be aware of that and quickly reset RX frequency back with band selector. This problem exists also with v2.5.2 -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Again problems with ic7300/rigctld/wsjtx[SOLVED]
Saku kirjoitti 14.12.2021 klo 12.19: Hamlib error: Invalid parameter vfo_fixup: vfo=Sub, vfo_curr=currVFO rig_set_vfo: rig does not have Sub rig.c(2607):rig_set_vfo return(-1) while exchanging VFOs It seems that again ic7300 is broken with latest hamlib source. I think situation is not any better with wsjtx 2.5.3 source (that I would like to get with git pull, please) Not tested that yet with tarball contents. Any help/comments, please. FYI: OS Fedora35 Solved this one. - Uninstall all related packages (wsjtx, hamlib) if any. - uninstall all self compiled versions (wsjtx, hamlib) if any. - search any remaining hamlib libraries cd /; sudo find -name libham* specially look at /lib* /var/lib and ~/.local/lib folders - remove all related files found. The oldest in my system was from 2018 -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Again problems with ic7300/rigctld/wsjtx
Today I upgraded Fedora 34 to version 35. As expected the self compiled wsjtx did not start any more. So I run my "doall.sh" script that: - pulls Hamlib from [remote "origin"] url = https://github.com/Hamlib/Hamlib.git - compiles and installs it [saku@hamtpad .git]$ rigctld --version rigctl Hamlib 4.5~git ti joulu 14 05:12:29 2021 + SHA=16cf19 - pulls wsjtx from [remote "origin"] url = https://git.code.sf.net/p/wsjt/wsjtx - compiles and installs it Wsjtx version 2.5.2 Rig is icom ic7300. rigctld is "pre started" with crontab script: /usr/local/bin/rigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0 --vfo & Wsjtx uses rig "Hamlib Net rigctld" / Network server: 127.0.0.1:4532/Ptt cat/Data/pkt/Split Rig These were the settings with Fedora34, some versions older hamlib and wsjtx 2.5.2 (that is the same as git pull said everything is up to date) Then it worked, now telnet 127.0.0.1 4532 one letter commands work I.E. Cqrlog logging program works. But wsjtx does not work. Settings/Test CAT stays red and pressing it gives error splash: Hamlib error: Invalid parameter vfo_fixup: vfo=Sub, vfo_curr=currVFO rig_set_vfo: rig does not have Sub rig.c(2607):rig_set_vfo return(-1) while exchanging VFOs It seems that again ic7300 is broken with latest hamlib source. I think situation is not any better with wsjtx 2.5.3 source (that I would like to get with git pull, please) Not tested that yet with tarball contents. Any help/comments, please. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Frequent exchanges repeats on some circustances
I agree with Reino! I have set TX 1Hz up after three retries. It is amazing how often it helps! If that does not make effect within few tries then just randomly jump TX around band during every TX period so long that opponent station receives your signal. Sometimes trying first to jump to opponent's TX frequency may also help as often he/she transmits on frequency that looks free during his/her RX period (that is the human mind...). Answering directly on his/her TX frequency for CQ is not good idea as so many other stations may do the same. -- Saku OH1KH Reino Talarmo via wsjt-devel kirjoitti 21.11.2021 klo 12.48: I'm noticing the occurrence depicted by the below print wherein you can see many attempts to end the QSO which doesn't close and are being repeated many retries despite my RST_R (-13) being fair. Hi Marco, One possible reason is a strong interference on your frequency and a change of your TX frequency could help. 73, Reino OH3mA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Enhancement
HI! I have done simple list file of US_callsign=state to cqrlog that can be used with wsjtx remote connection. The list is created from file that can be downloaded from fcc (ftp://wirelessftp.fcc.gov/pub/uls/complete/l_amat.zip) holding all information of callsign holders. When US callsign is received from remote wsjtx-UDP the list is scanned to find the callsign. If it is found the state is added to monitor line and also to temporary list file of callsign=state. Temporary file exists only during current wsjtx remote session and it is used first to look at callsign before search of the full list file. That way the seek time is much shorter with callsigns that are currently working on band that is monitored. Good : -callsign/states are up to date better than using qrz or other callbooks that depends on users update activity Bad : - list does not tell state of mobile or portable station - list can not be used with all countries state/county base as there is no free information of callisgin holders as it is against privacy laws (at least here in Finland) I have another suggestion for this: There is already working software for multicarrier fox. That same part of program could be used to send additional data as free text on second carrier. User could activate additional transmits, let's say on every 10th CQ transmission, that could then send user defined free text carrier with cq carrier. That text could hold special information about locator, state or what ever fits to free text frame length. What I am personally missing is the information of (rare) locators of /MM stations that do not now fit to standard CQ message of special callsign. I know the odd sides; - Using two carriers will drop the signal level (when same TX power used) and takes more bandwidth on already crowded bands. That is why to send it only on every 10th transmission, or what ever seems to be suitable. - Perhaps free text message should be tied somehow to main carrier, maybe using same kind of hash code as special callsigns have now. That would then help to connect free text to cq in case of several stations sending them in same period. -- Saku OH1KH John Korpal via wsjt-devel kirjoitti 18.11.2021 klo 20.12: Grid Locator to State Mapping Enhancement ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Possible WSJT-X 2.5.2 Bug(s)
Black Michael kirjoitti 12.11.2021 klo 15.54: Try a new config and see if that fixes the problem. wsjtx -r test Mike W9MDB Hi Mike! No help. It is what it is and has always been so. Image: started with test setup, minimized horizontally, closed, started again. F34/LXDE: laptop 1280x800(default) + external monitor 1440x900 (right), wsjtx at right (monitor) -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Possible WSJT-X 2.5.2 Bug(s)
HI! I see the problem #1 every day when I open wsjtx. And every day I shrink it horizontally to minimum. And again it starts wider than set at last time. It is a "property" and I have tried to modify the main window with QT designer, but as it branches to several pages it seems to be very hard to modify and I have not yet succeeded to create version that would be at minimum width from start. It is very bad thing, but seems to be that one just have to live with it. I think most people use the main window larger than minimum and so it is out of interest to make it keep its size, even when minimized. With problem #2 I have noticed that transmit tone can suddenly change to PC internal sound card and then back again to rig's sound card. It may happen even during same transmit period. And other nasty "feature" is that sometimes, when split/rig is used, receive frequency (vfo1) may get it's frequency from last used TX frequency (of vfo2). So suddenly you find out that half of waterfall is empty and when check the RX frequency it has jumped to last used TX frequency. How ever I count both these to be caused by RF problems because they are related to band and power used and also the weather outside that twists OCF dipole properties. Fedora 34/Icom 7300 Stephen Mitchell via wsjt-devel kirjoitti 11.11.2021 klo 13.57: I recently updated WSJT-X on my PC to the latest version and ever since I’ve noticed two things: 1. I sized the windows for the waterfall and decodes to my liking but with the latest version, when I start the application the decodes window continues to open up larger than the waterfall window, which stays at the size I set it to. 2. When I launch the application it sets the frequency .055 Hz higher than what the frequency should be. I’ve included a screenshot of what happens when I first launch the program. I don’t know if these are true bugs or if I just don’t have something configured properly. Thank you – K7CB -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] wsjtx 2.5.1 window width?
Just compiled version 2.5.1 (from sourceforge). When I first started that one the main window was about 6cm wider than old one in my display. I could shrink it to back reasonable width (those 6cms), but when I closed it and started again it's again back to that huge width. After that I visited settings (F2) and when returned I noticed that is can shrink window only half (~3cm) of that I could before visiting settings. And after restart window is again huge in width. Could someone point the part of source where this initial setting is defined, please? Perhaps I could find it by my self with enough seeking, testing and again seeking, but it that takes long time. I have tired it few times in past, without success. I have used QT designer to look files in widgets, but I have not found the way how the source and designed views are linked. With Freepascal and Lazarus form design is clear, but with C and QT it is mystery. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
There is something to do with man pages. For example: [saku@hamtpad ~]$ rigctld --version rigctl Hamlib 4.4~git ke loka 13 21:02:40 2021 + SHA=16a879 - chk_vfo Returns “CHKVFO 1\n” (single line only) if rigctld was invoked with the -o/--vfo option and “CHKVFO 0\n” if not. When in VFO mode the client will need to pass 'VFO' as the first parameter to set or get commands. VFO is one of the strings de‐ fined in set_vfo above. Manual page rigctld(1) line 672 (press h for help or q to quit) - [saku@hamtpad ~]$ telnet localhost 4532 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. \chk_vfo 1 q RPRT 0 Connection closed by foreign host. - An old rigctld Version 3.1 says: saku@servo2:~$ telnet localhost 4532 Trying 127.0.0.1... Connected to servo2. Escape character is '^]'. \chk_vfo CHKVFO 1 q Connection closed by foreign host. - For sake of the work done for pull requested fix for cqrlog I wish that man page is wrong and current version's answer is right. (only plain number in return). -- Saku OH1KH On 18.10.2021 16.29, Bill Somerville via wsjt-devel wrote: On 18/10/2021 14:21, Barry Jackson via wsjt-devel wrote: On 15/10/2021 16:18, Black Michael wrote: Try this rigctld -v -Z -v -m 2003 -s 4800 -r /dev/ttyUSB0 -t 4532 --serial_handshake=None --write_delay=5 Hi Mike, Going back to this command of yours with syntax that does not work, is there a current up-to-date ridctld documentation somewhere. I have tried the man page which has errors and I also see many alternatives to the syntax that also don't work around the internet. Am I maybe confusing parameters for rigctl with those for rigctld if they are different? Any help would be appreciated as I don't know which documentation to believe ;) Cheers, Barry G4MKT Barry, both rigctl and rigctld have pretty comprehensive built in usage documentation. Use: rigctl(d) -h for command line usage, and: rigctl(d) -l to list model number assignments, and: rigctl(d) -m -L to see the available configuration options along with their default values. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Maintenance Question: How To disable .WAV samples and reduce ALL.TXT size
Or you can zip the file: zip -j9m ~/ALL1.zip ~/.local/share/WSJT-X/ALL.TXT This will zip and remove ALL.TXT. Change number 1 to 2 ...3... etc. on next times. Zipping will reduce the file size approx 80% and you still have everything there if needed. On 16.10.2021 0.38, Bobby Chandler via wsjt-devel wrote: Marco, I just use Editpad or Notepad++ to replace all lines in the ALL.TXT that don't have my call. This reduces size considerably. Bobby/N4AU On 10/15/2021 2:28 PM, Marco Calistri via wsjt-devel wrote: Il 15/10/21 07:11, Reino Talarmo ha scritto: *Question 2:*Is there a way (I mean a correct/suggested way) to periodically empty the "ALL.TXT" file which in my case has reached almost 250 Mb in size? Hi Marco, You got already proposals not to empty ALL.TXT file, but rename it and put in a safe place for a later reference. There is a very simple emptying method already: File – Erase ALL.TXT, but you need to do it yourself now and then, hi! 73, Reino OH3mA Yes Reino, Thanks, I've not noticed that the "Erase ALL.TXT" and "Erase *.wav and *.c2" were available into the File menu, my lack!! Best regards! --- *73 de Marco, PY1ZRJ (former IK5BCU)* ** ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- n...@outlook.com ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Maintenance Question: How To disable .WAV samples and reduce ALL.TXT size
Hi! With linux command console you can do it fast with: grep -i oh1kh ~/.local/share/WSJT-X/ALL.TXT > ~/MYALL.TXT That makes file MYALL.TXT to your home directory. Just replace my call with your own. After checked MYALL.TXT you can delete the ALL.TXT rm ~/.local/share/WSJT-X/ALL.TXT And when ever you want to do it again just modify ">" to ">>" to be like: grep -i oh1kh ~/.local/share/WSJT-X/ALL.TXT >> ~/MYALL.TXT and lines with your call is added to existing file ~/MYALL.TXT On 16.10.2021 0.38, Bobby Chandler via wsjt-devel wrote: Marco, I just use Editpad or Notepad++ to replace all lines in the ALL.TXT that don't have my call. This reduces size considerably. Bobby/N4AU On 10/15/2021 2:28 PM, Marco Calistri via wsjt-devel wrote: Il 15/10/21 07:11, Reino Talarmo ha scritto: *Question 2:*Is there a way (I mean a correct/suggested way) to periodically empty the "ALL.TXT" file which in my case has reached almost 250 Mb in size? Hi Marco, You got already proposals not to empty ALL.TXT file, but rename it and put in a safe place for a later reference. There is a very simple emptying method already: File – Erase ALL.TXT, but you need to do it yourself now and then, hi! 73, Reino OH3mA Yes Reino, Thanks, I've not noticed that the "Erase ALL.TXT" and "Erase *.wav and *.c2" were available into the File menu, my lack!! Best regards! --- *73 de Marco, PY1ZRJ (former IK5BCU)* ** ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- n...@outlook.com ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Some minor issues.
Marco Calistri kirjoitti 29.9.2021 klo 16.49: Hi dear Saku I was hopefully waiting a feedback from your side as being one member of the CQRLOG developers team as well as a WSJT-X user. However, sorry to say this, but your reply doesn't sounds pretty clear to me... Despite this I will try to follow your suggestion about starting rigctld by a separate session. I demonstrated though my answer to Mike that CQRLOG has not any influence on the anomalies I faced (minor issue 1: no AFSK using NET rigctl and minor issue 2: radio split issue). I could keep using my current settings on both CQRLOG and WSJT-X since I feel that Hamlib will not works anymore as it was before (using NET rigctl) but at least I would like to get rid of the need to manually push VFO A=B button on my FT-100 every time I switch the band from WSJT-X. Thanks and best regards! HI Marco! Cqrlog does not have influence to A=B needs, but it is related to this. To get rid of pushing A=B after band change with wsjtx rigctld that access rig needs starting parameter "--vfo" if you start rigctld outside of wsjtx and use "Hamlib Net rigctld" as rig in wsjtx configuration. That helped at least me with Icom IC7300. As reminder: You can not start wsjtx with your rig model and serial port as rig in configuration(F2/radio) if you also start cqrlog with your rig model and serial port in preferences/TRXControl. This will cause two programs trying to share same serial port to access to your rig at same time and that will not work. You have to start rigctld with rig parameters separately and then make your programs call that rigctld with "Hamlib net rigctld" as rig in programs. ( https://github.com/OH1KH/cqrlog/blob/loc_testing/compiled/setting_rigctld_for_all_programs.pdf ) But when "--vfo" is used to get wsjtx happy problem arise with cqrlog that does not like "--vfo" parameter at rigctld start at all. And the reason is, as said, rigctld one letter commands need additional parameter about vfo (VFOA, VFOB, currVFO etc...) for almost all commands. This makes it not being backward compatible any more with older rigctld commands. So making wsjtx happy with "--vfo" makes cqrlog unhappy because it uses legacy one letter commands for accessing rigctld that then do not work any more. If you try latest hamlib 29 10:46:53 2021 + SHA=a2b3a8 you could also try my fix for cqrlog at https://github.com/OH1KH/cqrlog/tree/hamlib_vfo It has a new checkbox at preferences/TRXcontrol called "Use \chkvfo". It is default checked and then tries to find out has user started rigctld with or without "--vfo" parameter. With that information it changes command format for accessing rigctld from cqrlog. When unchecked it acts like previous cqrlogs. I.E: disables this fix. It seems to work with IC7300 when "--vfo" parameter is used and both cqrlog and wsjtx become happy. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Some minor issues.
Hi Marco! Sounds familiar, hi... As you use #2 Net Hamlib rigctld as cqrlog's rig you have to start rigctld elsewhere with rig parameters. I guess that happens via bash script. There you should use "--vfo" to get wsjtx work with split=rig. Unfortunately that causes problems with cqrlog. It does not work if parameter "--vfo" is used as using it changes the format of rigctld short (one letter) commands. They are no more backwards compatible because almost every command needs vfo stated as first parameter when start parameter "--vfo" is used. There is a workaround to start rigctld with rig parameters and "--vfo" via bash script. That makes wsjtx happy with rig #2 Hamlib Net rigctld configured there, but then you need to start another rigctld without "--vfo" for cqrlog and that 2nd rigctld accesses the 1st rigctld that then accesses your rig. For doing this: With bash script start rigctld with your normal rig parameters and "--vfo" wsjtx: rig #2 Net Hamlib rigctld selected, server localhost:4532 cqrlog/trxcontrol: "Run rigctld when program starts" checked rig #2 Hamlib Net rigctld selected localhost Port 14532 !!! Note the port number !!! Extra command line arguments I.E. do not write anything there Other settings do not affect with rig #2 no need to set them Instead of "localhost" I prefer using 127.0.0.1 because sometimes IPv6, if enabled, causes troubles when "localhost" is used directing connects to IPv6 that may not been supported by all programs. I'm working with fix for cqrlog, it is under testing and Mike has done good work at Hamlib side to get this issue solved. Specially Icom rigs that can not report vfo with "v" command have caused extra work. As soon as I have tested it properly I will make pull request to cqrlog's GitHub Another way to resolve this is leave the "--vfo" parameter away from bash started rigctld and then set wsjtx split=fake it. Then it is happy without "--vfo" and also cqrlog works as always before. For the audio issue I can not give help. All I know that pulse audio (pipewire) does not work properly. It has been so always, at least with Fedoras. Alsa is the only one that works. And when you change band and press Tune there as the first thing to do the first period transmit after that is always without audio. So do not use Tune button for tuning the new band first, just start transmit immediately and let the first transmit period activate autotuner (just wondering what the Tune button is for...) -- Saku OH1KH Marco Calistri via wsjt-devel kirjoitti 29.9.2021 klo 0.51: Il 28/09/21 18:08, Black Michael ha scritto: #1 Does the rig behave when NOT running cqrlog? #2 Please run rigctld like this, duplicate the problem, and send me the log.txt file rigctld -m 1021 --vfo -v -Z >log.txt 2>&1 Mike W9MDB Hi Mike, Yes, CQRLOG is not affecting at all in these behaviors. In attachment the two logs: 1 - *rigctld.usb.log.txt *produced when selecting "NET rigctl" into WSJT-X: result is that no AFSK is generated and FT-100 just switch the PTT on/off. 2 - *FT-100ctld.usb.log.txt* produced when selecting FT-100 as Rig into WSJT-X. In this case I tried to change band from 10 to 17 meters and going back to 10 meters and the result is that *_only_* the receiving VFO changes correctly though WSJT-X commands, while the transmitting VFO holds on 10 meters initial frequency. So yes, both issues are still present independently of CQRLOG and as I told, they are news issues since the newer software versions (hamlib/wsjt-x) has been released. Regards, -- *73 de Marco, PY1ZRJ (former IK5BCU)* ** ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X vs JTDX sensitivity comparison
HI ! My opinion: I have also tested this some time ago running both programs in parallel with same linux PC, same rig IC7300, OCF dipole 80-10m. If wsjt-x decode is set to "Normal" or "Deep" I would rather say "slightly better, in some cases". But difference is so small that it did not cause any need to move to JTDX. Rich - K1HTV via wsjt-devel kirjoitti 14.9.2021 klo 20.55: *The JTDX decode capability on weak signals is significantly better * -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
Good point Claude!
But I have at the moment only IC7300, WiFi Mouse and Hp laser printer
connected to PC via USB.
I have several symlinks, even for gps (because of some tests years ago)
But I do not have gpsd installed at the moment.
[saku@hamtpad ~]$ cat /etc/udev/rules.d/92-persistent-usb.rules
#own CI-V box
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b",
ATTRS{idProduct}=="2303", ATTRS{product}=="USB 2.0 To COM Device",
SYMLINK+="rig"
#IC7300
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4",
ATTRS{idProduct}=="ea60" ,ATTRS{serial}=="IC-7300 03003483",
SYMLINK+="icom7300"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403",
ATTRS{idProduct}=="6001", ATTRS{serial}=="A601VSBR", SYMLINK+="cwkeyer"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b",
ATTRS{idProduct}=="2303", ATTRS{product}=="USB-Serial Controller D",
SYMLINK+="gps"
#ESP WiFi device via USB-TTL converter
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4",
ATTRS{idProduct}=="ea60" , ATTRS{serial}=="0001", SYMLINK+="ardu"
#Xduino UNO V
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86",
ATTRS{idProduct}=="7523", SYMLINK+="ardu"
#Arduino UNO V2
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341",
ATTRS{idProduct}=="0001", SYMLINK+="ardu"
Claude Frantz via wsjt-devel kirjoitti 4.9.2021 klo 15.47:
On 8/27/21 10:06 AM, Saku via wsjt-devel wrote:
Hi Saku & all,
I have noticed a similar problem when using a GPS mouse as time source
for ntpd. The source of the problem is gpsd, especially when using the
"-n" command line flag, which is necessary here, although this
information is not included in the man page.
The solution was to set the "gpsd.service" as disabled with systemctl:
systemctl disable gpsd.service
At next, I have inserted the following line in
/etc/udev/rules.d/99-hamlib.rules:
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60",
ATTRS{serial}=="IC-7300 [0-9]*", TEST!="/dev/rigA", SYMLINK+="rigA"
Now, the IC-7300 appears as /dev/rigA. This was necessary because the
GPS mouse includes the same chip.
Finally, I have created a file "/etc/modprobe.d/my-local.conf" with:
alias pps-ldisc /dev/null
alias tty-ldisc-18 /dev/null
in order to avoid that gpsd try to use any tty device as PPS device.
When beginning, I plug in the XCVR and the GPS mouse on the USB
sockets. Then I start rigctld on /dev/rigA. Then gpsd "systemctl start
gpsd.service". I verify that gpsd is receiving data from the mouse
"gpsmon". After some delay, I verify that ntpd is using the signal
from gpsd via the shared memory: "ntpq -4p 127.0.0.1". Then I can
start wsjtx.
Perhaps you have a similar interference with gpsd.
Best wishes,
Claude (DJ0OT)
--
Saku
OH1KH
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
Hi Reino, Bill and Mike! FYI It looks like the PTT staying on was an RFI problem after all. Nothing changed in station setup, but a wire from the rear chassis of IC7300 to a filter box that ICOM has in it's power cable was loosen (fully detached). As it is at back side of rig it is not visible for operator. Noticed it yesterday when a new problem started: During FT8 TX period the sound card was switched between ICOM's internal card and PC's sound card several times during a TX period. Because nothing was changed at PC's side I finally peeked the wires behind the rig. I think this is now fixed, but the other problem still remains: When using self compiled binaries from latest versions of hamlib and wsjtx (4.3/2.5.0rc5) the "split/rig" does not work leaving vfoB to previously used band when band is changed. It should change to band of vfoA when first transmit period begins (or Tune), that it actually does for a second, but then reverts back to previously used band. I did already sent a link (to Mike) to a short video that shows the problem. https://drive.google.com/file/d/1wW3xr6d2NiN7sLTUj3WCU_aOKqOQ5z7l/view?usp=sharing I have now reverted back to hamlib 4.1 and wsjtx 2.4.0, both installed from Fedora 34 packages. That combination works with "rig/split" while the latest versions need "rig/Fake it" to work properly. Reino Talarmo via wsjt-devel kirjoitti 27.8.2021 klo 11.20: Hi! Now during few days I have noticed that calling cq with FT4 causes PTT to stay on during RX period. Nearly to end of it. Then small RX gap and TX starts again to next TX period (at proper time). This happens at random times after started CQ calling. When this starts to happen it may also cause error that rig is not responding. But not always. On other times it may just blink once the "green dot" besides band selector to yellow and back to green. After some time of calling cq with these problems TX enable drops away, no errors, and no receiving any more. Waterfall stays blank while stations can be heard from speaker I.E. there is traffic. Stopping and starting WSJTx does not help for long. If PTT problem has happened it soon continues after program restart. Rebooting PC helps and gives longer time until the PTT again stays on. This does not happen with FT8. It is a random problem, and so hard to reproduce but has happened now daily when I have started to use FT4 again with these versions of WSJTX and Hamlib. I may also be a rigctld problem, it is not the very latest from Git. Anyway it causes WSJTX to be unstable. Anybody seen this kind of problem with FT4 and 2.5.0rc5 ? Setup: Fedora 34 Self compiled WSJTX 2.5.0rc5 using Hamlib 4.3~git ti elo(Aug) 03 05:04:13 2021 + SHA=f29ee3 source IC7300 / USB baud rate Auto (19200 in rigctld settings) /Link to [remote] /CI-V tranceive off rigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0 rigctld started from script with IC7300 settings, WSJTX uses Net Hamlib rigctld @ localhost:4532 Terve Saku, Have you ever experienced RFI? Those symptoms do fit to that. Easiest quick check is to reduce output power and see, if any change. Experts may find another reason or reasons. 73, Reino OH3mA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
Yep! Yesterday I cleaned all, cloned again Hamlib from GitHub and WSJTX from sourceforge and then compiled. What I found out first is that split/rig does not work, I thought this was fixed some time ago with IC7300. Well, it is not. With latest sources it happens to work so that if setting is split/rig then if I start to work on 21Mc it works, but if I then change to 14Mc RX will go to 14Mc but TX at vfoB stays on 21Mc. So I have to use split/fake it to make it work properly. -- Saku OH1KH Black Michael kirjoitti 31.8.2021 klo 15.37: Are you compiling with the latest hamlib? Hamlib 4.3 release is rolling out very soon. You can check out the current version... git clone https://github.com/Hamlib/Hamlib.git <https://github.com/Hamlib/Hamlib.git> Mike W9MDB On Tuesday, August 31, 2021, 01:22:47 AM CDT, Saku via wsjt-devel wrote: There is no effect setting poll rate 1s, 2s or 5s. Always fails after a while. I would say that shorter poll rate seems to raise problems faster. I think I clean up everything and recompile all again. -- Saku OH1KH Saku via wsjt-devel kirjoitti 30.8.2021 klo 17.27: Black Michael via wsjt-devel kirjoitti 27.8.2021 klo 18.22: > Those cache times are showing 10134ms = 10 seconds since the last time > ptt was polled. For FT4 that's not good. > > What is your polling rate in WSJT-X? > > Mike W9MDB Hi MIke! Poll rate is 5sec. Compared to FT4 period it is too long, but I expect that every needed command is placed at time it should happen (not placed in poll queue) and reply for sent command comes immediately and at all other times (when not any special job to execute) rig is polled by poll rate. But if every rig cat command sent and responded go via poll queue then I just wonder how it has worked this far from the beginning of FT4 mode. I'll try next to minimize the poll rate and see what happens. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
There is no effect setting poll rate 1s, 2s or 5s. Always fails after a while. I would say that shorter poll rate seems to raise problems faster. I think I clean up everything and recompile all again. -- Saku OH1KH Saku via wsjt-devel kirjoitti 30.8.2021 klo 17.27: Black Michael via wsjt-devel kirjoitti 27.8.2021 klo 18.22: Those cache times are showing 10134ms = 10 seconds since the last time ptt was polled. For FT4 that's not good. What is your polling rate in WSJT-X? Mike W9MDB Hi MIke! Poll rate is 5sec. Compared to FT4 period it is too long, but I expect that every needed command is placed at time it should happen (not placed in poll queue) and reply for sent command comes immediately and at all other times (when not any special job to execute) rig is polled by poll rate. But if every rig cat command sent and responded go via poll queue then I just wonder how it has worked this far from the beginning of FT4 mode. I'll try next to minimize the poll rate and see what happens. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
Black Michael via wsjt-devel kirjoitti 27.8.2021 klo 18.22: Those cache times are showing 10134ms = 10 seconds since the last time ptt was polled. For FT4 that's not good. What is your polling rate in WSJT-X? Mike W9MDB Hi MIke! Poll rate is 5sec. Compared to FT4 period it is too long, but I expect that every needed command is placed at time it should happen (not placed in poll queue) and reply for sent command comes immediately and at all other times (when not any special job to execute) rig is polled by poll rate. But if every rig cat command sent and responded go via poll queue then I just wonder how it has worked this far from the beginning of FT4 mode. I'll try next to minimize the poll rate and see what happens. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
Thanks Bill! Pulled last Hamlib from GItHub, compiled and installed. Then cloned wsjt-x from sourceforge, made CMAKE_PREFIX_PATH to point that cloned Hamlib directory and compiled. Now I have running version that again has same problem than some time ago: If I use 17m, then change to 20m to work there then rig's vfoB does not change transmitting still on 17m and receiving on 20m with vfoA I think it is now time to restore previously compiled version (that did not have this error) and then take weekend without any programming. Have nice weekend! PS. FT4 problem still existed also with this version, too. 2021-08-27 14:33:15.401025][00:00:58.757069][RIGCTRL:trace] rig_get_ptt: cache miss age=10134ms There are similar with get_mode, get_vfo and get_split_vfo with ages/widths with times from 23ms to 52460ms -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
Bill Somerville via wsjt-devel kirjoitti 27.8.2021 klo 14.05: if you are not going to use the bundled Hamlib sources then there is little point in starting with the WSJT-X sources tarball we provide. That tarball is specifically set up to build WSJT-X using that bundled Hamlib. You would be better to simply clone the WSJT-X git source repository f I think a while ago I told (might be just in mail to Mike, not to dev-list) how I tar and checksum Git-hamlib clone with names of Hamlib in wsjt-x tarball, replace the original files and then do build. I think it is not clever (at least not easiest) way and asked is there a proper way. If I search GitHub with "wsjt-x" I get 57 repositories. Then there is SourceForge. To tell the truth I have difficulties to know where is the latest official source (elsewhere than tarball@Joe's web page). Mainly because I am not Git guru and I can do just some basic things there. Hamlib is easy to find from GItHub. It is just "hamlib" and can be found as first hit of search. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
Bill Somerville via wsjt-devel kirjoitti 27.8.2021 klo 11.42: Hi Saku, have you tried using the rigctld-wsjtx that is bundled with WSJT-X, or the one built with the Hamlib package you linked WSJT-X with? 73 Bill G4WJS. HI Bill! No, not tested with rigctld-wsjtx. But when extracted wsjtx source I removed the hamlib part and replaced it with this Git source I mentioned. So there is only one version of Hamlib in this PC. On directly compiled and installed from Git clone source and that same source is transferred to wsjtx build. So there should not be any lib conflicts. I may try to do Git pull again and recompile to get very latest Hamlib when time permits. I also try to find if there is any clue how to reproduce this problem. And to Reino: If there has not been RF problems before, and when FT8 works ok also now, I suspect that is not RF problem with FT4. But I can test it also with reduced power. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC5 main window size issue
Hei! Do you set *absolute minimums* for H and W and then close/open wsjtx? As Bill says if window is a bit bigger for both directions, with my display resolution ~2cm in H and ~1,5cm in W, retains it. That breaks the whole display window positioning setup in every start with this rather small HP L1908w (1440x900-60Hz) monitor. Kari Sillanmäki via wsjt-devel kirjoitti 12.8.2021 klo 10.51: I'm running WSJT-X on XUbuntu 18.04.5 LTS with XFCE 4.12.2 desktop. In my system WSJT-X remembers the size/location of the main window. Still something to do with Fedora / LXDE ?? 73's de Kari, oh2gqc / oh6bz -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC5 main window size issue
HI! If you set wsjtx main window to minimum horizontal and vertical size it is not saved/loaded when wsjtx starts again resulting bigger main window that was set. Saving window W and H and X,Y position at close and reload them at start should give same sized window. OS Fedora Linux 34/ LXDE Cqrlog compiled with QT5 widgets can do this, so I assume it is not LXDE/QT5 problem to restore window size and position. -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X V2.5.0-rc4 (Fedora 34)
I have done just so: use /usr prefix to override package hamlib. With Fedora it is no problem to remove Hamlib package: rpm -e --nodeps hamlib And it does not remove all ham programs at same time because of dependencies. --- I have now pulled my hamlib clone directory from git and compiled it. I also compiled wsjtx 2.3.1 for use. Getting wsjtx source and doing compile by the instructions of INSTALL file makes folder hamlib-prefix and compiles that with wsjtx. And it is not the latest version of hamlib. I made some "innovations": copied hamlib git version to same name as wsjtx 2.3.1/hamlib-prefix, then tar:ed the folder (using that old name) and made md5sum of it. After that replaced those hamlib files that come with wsjtx source and compiled by INSTALL instructions. Could someone say how this should be done properly? I.E add latest hamlib to (any version) of wsjtx source. How ever my trick worked and now I have latest hamlib and properly working wsjtx 2.3.1 -- Saku OH1KH Bill Somerville via wsjt-devel kirjoitti 3.8.2021 klo 16.32: Mike, OK, then uninstall the system package, so long as no other package depends on it. You are advocating breaking packaging dependencies for no good reason. Installing a package into /usr/local, or indeed /opt, or /opt/local is standard practice on 8nix systems when it is required to override some system installed package. Your advice will lead to users with broken distributions! There is no good reason to install a package into /usr on a system where /usr is used for installation of managed packages. The Linux ldconfig system makes it certain where libraries are loaded from, look at the manpage for ldconfig and at least try and learn how these systems work. There is no ambiguity about loading of libraries, it is set by /etc/ld/so/conf, and so long as users do not screw up the default PATH assignments the same applies to executables and executable scripts. 73 Bill G4WJS. On 03/08/2021 14:21, Black Michael via wsjt-devel wrote: Everybody that does that ends up with multiple ham installations and no idea which libhamlib.so wsjtx is using. You can always install a package over the top of it with no problem. Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X V2.5.0-rc4 (Fedora 34)
HI Mike ! No error reported. Frequency just stays on where it was set by "monitor returns to last used frequency". No change, no error. I do not see any connection of File/Settings/Frequencies and rig polling. It should read what rig display has in not depending on what is in band selector frequencies list. Dial -200 is not bad idea. Then you can set your tx to be 150Hz that is usually empty. I guess most (specially old) rigs can pass that, but they do not hear calls over 2500Hz that leaves 2500Hz-3400Hz unusable. By experience below 200Hz reaches most stations while 2.5-3.4kHz fails more often. -- Saku OH1KH Black Michael via wsjt-devel kirjoitti 3.8.2021 klo 16.10: WSJT-X most certainly does poll the rig. Though only every 5 seconds since you set it that way. Of course it won't poll if it gets an error. Perhaps you need to reset your frequencies in File/Settings/Frequencies -- right-click in the list and "Reset". And dialing down to get "free tx space" below 200 is a bad ideamost everybody won't hear you down there as it's below their bandwidth cutoff. Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X V2.5.0-rc4 (Fedora 34)
Thanks Bill! I have not touched Settings/general ... I cannot remember when was the last time. Perhaps it was some day in stone age. :-) Both "monitor off..." and "monitor returns ..." were unchecked. Checked now the "monitor returns to last used frequency" and it helps for "OOB" problem. Assume it has appeared at some time since version 2.3.1 as It did not need to check that before. I think that wsjtx should get the current frequency from rig. Checking "monitor returns to last used frequency" just hides the actual problem by setting the rig. That is because if starting wsjtx it sets now 6m frequency without "OOB" but wsjtx cannot notice if I set 20m using rig buttons. It just shows still 6m, I.E. it does not poll rig like it did before. With last used ver2.3.1 manual change with vfo did affect also to wsjtx frequency display. And that is also what "monitor returns to last used frequency"'s popup help text claims, too. Same thing continues if I change band from wsjtx band selector. Rig changes frequency, but if I after that change frequency with vfo wsjtx does not notice that. Rig poll rate is 5s, but I have used to wait for the change a bit. I have to test what happens in real qso as I sometimes drop dial -200Hz with vfo to get free TX space from under 200Hz of waterfall. - I did downgrade back to wsjtx-2.4.0-1.fc34.x86_64 and noticed it has the same problem. Frequency display does not follow rig if vfo is turned while cqrlog, accessing the same rigctld daemon, notices frequency changes. ;-( - grep says: [RIGCTRL][2021-08-03 12:04:34.582825][00:00:00.186587][info] Hamlib version: Hamlib 4.3~git Sun Jul 25 23:51:03 2021 + SHA=67b787 -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X V2.5.0-rc4 (Fedora 34)
Hi! Just upgraded my Fedora from 33 to 34. Removed all self compiled hamlib and wsjtx versions and installed packages from repository: wsjtx-2.4.0-1.fc34.x86_64 hamlib-4.1-1.fc34.x86_64 It seems to work. Only one question arises: *Is it in purpose that every time I start wsjtx it shows yellow "OOB" on red background and frequency display is filled with zeros.* After band is selected frequency shows out ok and all works. Just annoying that it does not get frequency at start by itself like before. I use rigctrld started from script before wsjtx. Start line is: /usr/bin/rigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0 & (as you can see the rig is icom 7300) Wsjtx settings use rig: Hamlib Net rigtcĺd, sever: localhost:4532, split: rig ldd /usr/bin/wsjtx | grep ham libhamlib.so.4 => /lib64/libhamlib.so.4 (0x7fd30f59e000) - After that I installed 2.5.0_rc4 from wsjtx web page package: wsjtx-2.5.0_rc4-1.x86_64 Again every time wsjtx is started it shows yellow/red "OOB" with zero frequency. When band is selected from selector frequency shows ok. But every time I try to "Tune" or start tx from "Enable TX" the yellow/red "OOB" and zero frequency returns and TX does not start. Also following error appears: Hamlib error: Feature not available rig.c(5605):rig_has_vfo_op return(0) rig.c(3790):rig_set_split_freq return(-11) rig.c(4331):rig_set_split_freq_mode return(-11) while setting split TX frequency and mode If I return band back from band selector same repeats. But If I ignore "OOB" and try again "Tune" or "Enable TX" transmitter starts and I can keep qso. How ever at logging phase the "Band" column is empty as can be expected when "OOB" is visible. Perhaps rig timeout is too short in wsjtx (??) and it can not get response from daemon running rigctld that have to ask it from rig. But from where to adjust that? If I go configuration/radio and test CAT and PTT everything works ok. *So rc4 is unusable with "split"="rig". If I set "Fake it" all works after I have cleared the start phase "OOB" like with 2.4.0* -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.5.0-rc3 RST_RCVD logging issue
Rather good way to get qso one period faster. Important with VHF ES DXing (mostly 6m). Conditions change so fast. There are not so many 4 character grids in Japan. And if callsign's QRZ or HamQTH entry is up to date external logger adds the locator, usually 6 characters, or even more precise. -- Saku OH1KH Derek Turner via wsjt-devel kirjoitti 17.7.2021 klo 9.33: And why do JAs en mass ignore locators which are fundamental in FT8 exchanges for the rest of us ? 73 de G4SWY Del +++ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
