Re: [wsjt-devel] Hamlib Error
If it runs at startup but fails during/after transmit than it is probably RFI. Here are some potential solutions -- ordered by cost. #1 Free - Move USB cables to another port -- some ports are more susceptible than others.#2 Free -- Check your grounding system. rod-outside-the-shack is a common problem when it's not bonded to the main house ground. http://www.k9yc.com/GroundingAndAudio.pdf #3 Add some USB shield isolators (see my QRZ page).#4 Good USB cables like thishttps://www.amazon.ca/Tripp-U023-006-Device-Ferrite-Chokes/dp/B003MQ29B2/ref=sr_1_5?crid=11YRNPWDVWGCU=usb+cable+with+choke=1658187349=usb+cable+with+choke%2Caps%2C139=8-5 #5 Maybe free (if you have chokes...otherwise can get a bit costly) -- add chokes to USB cables first, then all other cables including power, ethernet, and control cables. Fair-Rite torroids are good quality -- do NOT buy cheap Chinese ones -- https://www.fair-rite.com/product/toroids-5943003801/ You can use clip-ons but torroids allow multiple wraps and give better results.https://www.fair-rite.com/product/round-cable-snap-its-431176451/ I couldn't find type 31 torroids at Fair-Rite as of 20220721 but Palomar has some palomar-engineers.com/ferrite-products/ferrite-cores/ferrite-ring-toroid-combo-pack/ Mike W9MDB On Thursday, July 21, 2022 at 12:29:33 PM CDT, Marty Wayne via wsjt-devel wrote: I was working 20 Meter FT-4 and at one point I got a Hamlib error, communication timed out. See report below. Im not computer savvy. What might be the issue? Rig-FT-1000MP iOS 12.5 SignaLink USB interface WSJTx 2.5.2 WSJTx 2.5.4 Hamlib error: Communication timed out rig_get_vfo: returning -5(Communication timed out ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeoutft1000mp.c(1249):ft1000mp_get_vfo return(-5) Communication timed out ft1000mp_get_update_data: Timeout ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeoutft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeoutft1000mp.c(1249):ft1000mp_get_vfo return(-5) Communication timed out ft1000mp_get_update_data: Timeout ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeoutft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeout)rig_get_vfo: elapsed=439ms rig.c(2587):rig_get_vfo return(-5) Communication timed out rig_get_vfo: returning -5(Communication timed out ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeoutft1000mp.c(1249):ft1000mp_get_vfo return(-5) Communication timed out ft1000mp_get_update_data: Timeout ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeoutft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeoutft1000mp.c(1249):ft1000mp_get_vfo return(-5) Communication timed out ft1000mp_get_update_data: Timeout ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeoutft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication timed out read_block_generic(): Timed out 0.402040 seconds after 0 chars ft1000mp_get_update_data: Timeout ft1000mp_get_update_data: Timeout)rig_get_vfo: elapsed=439ms rig_get_vfo: elapsed=439ms while testing getting current VFO Timestamp: 2022-07-21T17:16:46.329Z 73, Marty, W6NEV _ . . . . _ _ _ . . . . _ . . . . . _ mcway...@comcast.net 408-234-8023 ___ 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] “Disable Tx after sending 73” not working
First off let's try the latest hamlibNew 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/\Note: If compiling on Unix-like systems please uninstall any Hamlib package you have before installing the new build #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 =Then..if you still see the problemPlease place this file as described belowhttps://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 fileMike W9MDB On Saturday, July 16, 2022 at 09:35:18 AM CDT, Gene Marsh via wsjt-devel wrote: Hi all, My setup: Windows 10/i5/8GB WSJT-X v2.5.4 d38164 FTDX10 I checked “Disable…” again, then closed the app. Then tried again. Same. Rebooted. Same thing. I saw the same thing on the last version (2.5.1?). Also tried to reinstall. Same thing. Am I missing something simple ( I do have many DOH! moments)? 73 de W8NET Miles “Gene” Marsh 3905 Century Club Master #47 3905 Century Club 2022 Eyeball host___ 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] Q65: Using an rx-only sdr panadapter in parallel with rig transceiver
This can be done using either rigctld or FLRig and rigctlcom. rigctlcom provides a TS-2000 emulator that can work with most any program needing a COM port to talk to the rig and work simulataneously with WSJTX connected to rigctld or FLRig. So you can set up WSJTX to use Hamlib NET rigctl or FLRig. This will allow other programs to also talk to your rig. Then you run rigctlcom on a virtual serial port pair. rigctlcom Version 1.3Usage: rigctlcom -m rignumber -r comport -s baud -R comport [OPTIONS]... A TS-2000 emulator for rig sharing with programs that don't support Hamlib to be ableto use a connected radio transceiver or receiver with FLRig or rigctld via Hamlib. Example: Using FLRig with virtual COM5/COM6 and other program: rigctlcom -m 4 -R COM5 -S 115200 Note that the serial speed here really doesn't matter as it's virtual port so can always run at maximum speed. SpectraVue can then connect to the other paired COM port and WSJTX frequency changes will then be updated in SpectraVue I found the TS-850 rig entry in SpectraVue works -- there's some comment about the TS-2000 needing an IF mod so not sure what that means. For rigctld userigctlcom -m 2 -R COM5For FLRig userigctlcom -m 4 -R COM5 Mike W9MDB On Thursday, July 14, 2022 at 03:50:10 PM CDT, Rob O'Leary via wsjt-devel wrote: Hi Alex, I have thought of doing something like this but I expect/hope that we are not the only people wanting to do sync a panadapter/rx SDR to their wsjtx band and so there might be a way to do it that I don't have to invent/code. Regards Rob On 14/07/2022 21:28, Alex Lelievre wrote: > Hi Rob, > > I’ve modified Hamlib so that when I switch frequency on my radio it also > sends a command to my SDR software to go to that frequency via CAT. I’m sure > there are tools out there that do this without the need to modify existing > software but figured I’d put it out there in case that helps you slightly. > > best, > alex K6LOT > > >> On Jul 14, 2022, at 12:42 PM, Rob O'Leary via wsjt-devel >> wrote: >> >> Hi >> >> I have searched the email list and the online user guide, so I hope I havent >> missed obvious documentation... >> >> We use wsjt-x to control an icom746 connected to a 10GHz transverter. We >> operate Q65-D for EME. We have fed a 618MHz receive IF to a receive only SDR >> to allow us to see a wider slice of spectrum (doppler etc), currently >> running spectravu. This IF is further down converted to 144MHz into the >> icom746 receive.) >> >> I think I could run 2 instances of wsjtx, 1 for the sdr and 1 for the >> icom746 but then if we change sked frequency in the eme settings, we would >> have to do it twice and soon mess it up! >> >> Please could you explain if there is a way to sync the SDR frequency to the >> doppler corrected rx freq that is sent to the icom746 and how to set this up? >> >> Thanks >> >> Rob >> >> >> >> ___ >> 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT-857 rig control bug in WSJT-X 2.6.0-rc1
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 Sunday, July 10, 2022 at 09:33:28 AM CDT, Nigel Haynes via wsjt-devel wrote: I have been using the WSJT-X 2.6.0-rc1 without issue on several rigs, but when I tried to setup an FT-857 for rig control, I was having errors. I am using a signalink for sound, so need to select VOX in the settings. When selecting VOX, it gives an error when connecting via Test CAT. If I select CAT PTT, everything works (except it doesn’t because the rig wants audio via the mic and not the cat port on the rear where the signalink is sending the audio.) I installed the latest production release, 2.5.4, and everything is good. As a test, I have it working on 2.5.4, then installed WSJT-X 2.6.0-rc1 and launched the same shortcut, and get the error. I then reinstalled 2.5.4 and it works as expected. The rig also switches from VFOA to VFOB and back a few times before the error. Recap: WSJT-X 2.6.0-rc1 has an issue on the FT-857 rig control and will not connect when VOX PTT is selected. It connects (rig control) with CAT PTT, but need to use VOX. Thanks, Nigel Haynes supernigel.hay...@gmail.com ___ 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
[wsjt-devel] Hamlib testing #Hamlib
I need everyone to test the latest Hamlib please!! All known rig bugs have been fixed. Testing in Rig Split and Fake It would be appreciated as well as rigctld testing. Successes/Failures please report. Some recent important fixes are IC-9700 in split mode should work better now and split operations should be more stable for all other rigs. 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
Re: [wsjt-devel] 2.6.0-rc1
Please place this file as described belowhttps://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 fileMike W9MDB On Tuesday, June 28, 2022 at 09:27:22 AM CDT, OG55W via wsjt-devel wrote: I have used rc1 one week 16h per day. Have to restart the compter twice evey day as the Program almost close surprisingly. Using Win11 64, USB device router and micro KEYER II with FTdx101D. Keijo OG5O Lähetetty Windowsin Sähköpostiista Lähettäjä: jarmo via wsjt-devel Lähetetty: tiistai 28. kesäkuuta 2022 8.06 Vastaanottaja: wsjt-devel@lists.sourceforge.net Kopio: jarmo Aihe: [wsjt-devel] 2.6.0-rc1 Now few days running 24h (listening) mostly and seen nothing peculiar. Only first time calling CQ, many stations called me, but autoseq didn't pick any. Yes, then noticed, CQ NONE... Ok, this let you choose station, but same thing can be done with autoseq unchecked... So, "cq: first" and "cq: max dist" could be enough. Actually liked very much that option "max dist" when called DX... Didn't neet care EU callers, when called long distance... Very good.. 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Connecting the Yaesu FTdx10
From my notes helping somebody else. FTDX-10 Data/Pkt mode bandwidth not working..had to use USB mode Data Out Level=0 () Some more info https://ki5gfu.com/2021/10/14/ftdx-10-setting-up-wsjt-x-configuration-for-digital-eg-ft8/ Mike W9MDB On Thursday, June 23, 2022 at 05:02:21 PM CDT, BRIAN JONES via wsjt-devel wrote: Got the Yaesu FTdx10 a couple of weeks ago and and trying to > get on FT8 everything said I needed a laptop or PC with windows 10/11. > So last Monday I went out & caught one with win11 home installed, > while I was in the shop they got it setup for me with all the updates > etc. sorted. jobs a good one so I thought! > Having used WJST before with a Icom bit of junk the 7300, very similar > settings to the FTdx10. As having set all parameters up to Yaesu and a > lot of the geeks say the same including, downloading virtual ports, > firmware both off Yaesu & BktTimesync; Then loaded WSJT-X . Now on > settings got radio setting done clicks box turns green 1st part sorted > the pressing next button radio goes into TX clicks ok, box closes and > all I keep getting is a box with red circle and X in red ring with > message (ERROR IN SOUND INPUT) but can you tell me where the sound input > is coming from my Radio or my Laptop, then how to stop this error and > get back on the air with FT8 & FT4? If anyone has a PDF with all settings for windows 11 so all I would need to do is swop over com port numbers. Up to now I have wasted close to 35 hours trying to get up & running and up to now no one knows what or where this problem is! Did send an email to Joe Taylor K1JT even though he sent me to Wiki to find a cure! I had Icoms NAIL the 7300 ( had four for just one band in the UK 70Mhz ) totally deaf as a post. But Icom UK recon they can hear signals off a DUMMY LOAD dummies. my email address is below if anyone has a clue as I don't Thanks. 2e0...@gmail.com > Regards > Best 73 > Brian De M6OXO ___ 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] Hamlib rigcontrol and PTT
All 5-v On Thursday, June 23, 2022 at 09:18:14 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: I'll get you that log later today. What verbose level do you need on rigctld (how many v)? Thanks Hrafnkell TF3HR On Thu, Jun 23, 2022 at 1:44 PM Black Michael via wsjt-devel wrote: And if CAT PTT still fails I need to see debug info -- add ">log.txt 2>&1" to the rigctld line. rigctld --model=3011 --rig-file=/dev/ttyUSB0 --serial-speed=4800 --port=4532 --set-conf=stop_bits=1,dtr_state=ON,rts_state=ON --ptt-file=/dev/ttyUSB1 --ptt-type=RTS -Z >log.txt 2>&1 Then send me the log file. Mike W9MDB On Thursday, June 23, 2022 at 08:19:19 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: It works fine when I'm running WSJT-X on the same computer as hamlib rigctld and I can set it to access the serial port directly for PTT.But in this case I'm running WSJT-X on Windows but running hamlib rigctld on a Raspberry Pi. WSJT-X does not have access to the /dev/ttyUSB* on the raspberry pi.The communication between WSJT-X and hamlib happens over a network. So I'm expecting the hamlib code in WSJT-X to delegate the PTT to hamlib as a rig_set_ptt command that then turns into a network message and the rigctld backend then performs a PTT. Browsing the code shows that there HamlibTranceiver::do_ptt() does indeed call rig_set_ptt. Is it possible that WSJT-X is trying to open a local COM port on windows when setting up the communication to hamlib even though it is not set to use DTR or RTS PTT?Could it be that the code still tries to open a local COM port even though the rig control is set to a network server and PTT is selected as CAT? Thanks for your help Hrafnkell TF3HR On Thu, Jun 23, 2022 at 12:06 PM Black Michael via wsjt-devel wrote: WSJT-X has to be set up to use the same RTS keying and the the /dev/ttyUSB1 port. Just tested it here and it uses it correctly (though I tested on Windows). Mike W9MDB On Thursday, June 23, 2022 at 03:53:35 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: > Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be >why it's not working.I have rts_state and dts_state ON to power the CAT >cable. The --set_conf option only seems to apply to the rig-file device, not >the ptt device. I can remove the rts_state=ON, it has no effect on PTT PTT over hamlib is working, it's just WSJT-X that is not using it. I can use e.g. a voice keyer in Log4OM and it does PTT properly through hamlib. 73 de Hrafnkell TF3HR On Wed, Jun 22, 2022 at 11:07 PM Black Michael via wsjt-devel wrote: The 706MKIIG does not do CAT PTT per se but the ptt-type=RTS should work. Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be why it's not working. And dtr_state=ON would only be needed if your CAT cable needs power from the computer to work. Mike W9MDB On Wednesday, June 22, 2022 at 11:35:27 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: Hi I'm running WSJT-X v2.5.4 on a Win10 computer.I've set up hamlib rigctld (version 4.4) on a Raspberry Pi and connected it to my Icom706mk2g.I'm using two com ports from the RPi, one for CAT control and one for PTT.I've set WSJT-X to use hamlib for rig control and pointed it to the ip:port of my RPi. Test CAT works fine and WSJT-X can set and read the frequency if I have PTT method set to Vox.If I set PTT method to CAT then Test CAT fails with the error:Rig failureHamlib error: IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)rig.c(1047):rig_open return(-6) IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)iofunc.c(361):port_close return(0) while opening connection to rig I can use the hamlib CAT PTT from other software such as Log4OM without issues.I would expect CAT PTT with hamlib rigcontrol in WSJT-X to behave the same, that is use hamlib calls to do PTT. My rigctld command line isrigctld --model=3011 --rig-file=/dev/ttyUSB0 --serial-speed=4800 --port=4532 --set-conf=stop_bits=1,dtr_state=ON,rts_state=ON --ptt-file=/dev/ttyUSB1 --ptt-type=RTS -Z Am I setting something wrong or misunderstanding something? Thanks Hrafnkell TF3HR___ 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 ___ 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] RC1 quits
In \Users\[username]\AppData\Local\WSJT-X rename the WSJT-X.ini file. That will allow you to start a new setup. Mike W9MDB On Wednesday, June 22, 2022 at 07:06:52 PM CDT, Donhawbaker via wsjt-devel wrote: At first RC1 worked fine. But now it boots up, shows the splash beta screen, then the TS-2000 beeps, and when I hit Okay, the program quits. I have no access to the setup screen. I reloaded the program twice. Same result. 2.5.4 runs fine. ___ 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] Hamlib rigcontrol and PTT
And if CAT PTT still fails I need to see debug info -- add ">log.txt 2>&1" to the rigctld line. rigctld --model=3011 --rig-file=/dev/ttyUSB0 --serial-speed=4800 --port=4532 --set-conf=stop_bits=1,dtr_state=ON,rts_state=ON --ptt-file=/dev/ttyUSB1 --ptt-type=RTS -Z >log.txt 2>&1 Then send me the log file. Mike W9MDB On Thursday, June 23, 2022 at 08:19:19 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: It works fine when I'm running WSJT-X on the same computer as hamlib rigctld and I can set it to access the serial port directly for PTT.But in this case I'm running WSJT-X on Windows but running hamlib rigctld on a Raspberry Pi. WSJT-X does not have access to the /dev/ttyUSB* on the raspberry pi.The communication between WSJT-X and hamlib happens over a network. So I'm expecting the hamlib code in WSJT-X to delegate the PTT to hamlib as a rig_set_ptt command that then turns into a network message and the rigctld backend then performs a PTT. Browsing the code shows that there HamlibTranceiver::do_ptt() does indeed call rig_set_ptt. Is it possible that WSJT-X is trying to open a local COM port on windows when setting up the communication to hamlib even though it is not set to use DTR or RTS PTT?Could it be that the code still tries to open a local COM port even though the rig control is set to a network server and PTT is selected as CAT? Thanks for your help Hrafnkell TF3HR On Thu, Jun 23, 2022 at 12:06 PM Black Michael via wsjt-devel wrote: WSJT-X has to be set up to use the same RTS keying and the the /dev/ttyUSB1 port. Just tested it here and it uses it correctly (though I tested on Windows). Mike W9MDB On Thursday, June 23, 2022 at 03:53:35 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: > Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be >why it's not working.I have rts_state and dts_state ON to power the CAT >cable. The --set_conf option only seems to apply to the rig-file device, not >the ptt device. I can remove the rts_state=ON, it has no effect on PTT PTT over hamlib is working, it's just WSJT-X that is not using it. I can use e.g. a voice keyer in Log4OM and it does PTT properly through hamlib. 73 de Hrafnkell TF3HR On Wed, Jun 22, 2022 at 11:07 PM Black Michael via wsjt-devel wrote: The 706MKIIG does not do CAT PTT per se but the ptt-type=RTS should work. Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be why it's not working. And dtr_state=ON would only be needed if your CAT cable needs power from the computer to work. Mike W9MDB On Wednesday, June 22, 2022 at 11:35:27 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: Hi I'm running WSJT-X v2.5.4 on a Win10 computer.I've set up hamlib rigctld (version 4.4) on a Raspberry Pi and connected it to my Icom706mk2g.I'm using two com ports from the RPi, one for CAT control and one for PTT.I've set WSJT-X to use hamlib for rig control and pointed it to the ip:port of my RPi. Test CAT works fine and WSJT-X can set and read the frequency if I have PTT method set to Vox.If I set PTT method to CAT then Test CAT fails with the error:Rig failureHamlib error: IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)rig.c(1047):rig_open return(-6) IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)iofunc.c(361):port_close return(0) while opening connection to rig I can use the hamlib CAT PTT from other software such as Log4OM without issues.I would expect CAT PTT with hamlib rigcontrol in WSJT-X to behave the same, that is use hamlib calls to do PTT. My rigctld command line isrigctld --model=3011 --rig-file=/dev/ttyUSB0 --serial-speed=4800 --port=4532 --set-conf=stop_bits=1,dtr_state=ON,rts_state=ON --ptt-file=/dev/ttyUSB1 --ptt-type=RTS -Z Am I setting something wrong or misunderstanding something? Thanks Hrafnkell TF3HR___ 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 ___ 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 ___ 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] Hamlib rigcontrol and PTT
Then PTT CAT should work. WSJTX should send the "T" command to rigctld and rigctld then uses the RTS keying. I just confirmed that works. 2022-06-23T08:37:29.191879-0600: rigctl(d): T 'currVFO' '3' '' ''2022-06-23T08:37:29.191879-0600: rigctl_parse: vfo_opt=02022-06-23T08:37:29.191879-0600: 2:rigctl_parse.c(2466):rigctl_set_ptt entered2022-06-23T08:37:29.191879-0600: rigctl_set_ptt: set_ptt ptt=32022-06-23T08:37:29.191879-0600: rigctl_set_ptt: ptt=32022-06-23T08:37:29.191879-0600: 3:rig.c(2845):rig_set_ptt entered2022-06-23T08:37:29.191879-0600: ser_set_rts: RTS=12022-06-23T08:37:29.191879-0600: rig_set_ptt: rigport=COM21, pttport=127.0.0.1:12345, ptt_share=02022-06-23T08:37:29.243640-0600: 3:rig_set_ptt: elapsed=52ms2022-06-23T08:37:29.243640-0600: 3:rig.c(3114):rig_set_ptt returning(0) Mike W9MDB On Thursday, June 23, 2022 at 08:19:19 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: It works fine when I'm running WSJT-X on the same computer as hamlib rigctld and I can set it to access the serial port directly for PTT.But in this case I'm running WSJT-X on Windows but running hamlib rigctld on a Raspberry Pi. WSJT-X does not have access to the /dev/ttyUSB* on the raspberry pi.The communication between WSJT-X and hamlib happens over a network. So I'm expecting the hamlib code in WSJT-X to delegate the PTT to hamlib as a rig_set_ptt command that then turns into a network message and the rigctld backend then performs a PTT. Browsing the code shows that there HamlibTranceiver::do_ptt() does indeed call rig_set_ptt. Is it possible that WSJT-X is trying to open a local COM port on windows when setting up the communication to hamlib even though it is not set to use DTR or RTS PTT?Could it be that the code still tries to open a local COM port even though the rig control is set to a network server and PTT is selected as CAT? Thanks for your help Hrafnkell TF3HR On Thu, Jun 23, 2022 at 12:06 PM Black Michael via wsjt-devel wrote: WSJT-X has to be set up to use the same RTS keying and the the /dev/ttyUSB1 port. Just tested it here and it uses it correctly (though I tested on Windows). Mike W9MDB On Thursday, June 23, 2022 at 03:53:35 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: > Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be >why it's not working.I have rts_state and dts_state ON to power the CAT >cable. The --set_conf option only seems to apply to the rig-file device, not >the ptt device. I can remove the rts_state=ON, it has no effect on PTT PTT over hamlib is working, it's just WSJT-X that is not using it. I can use e.g. a voice keyer in Log4OM and it does PTT properly through hamlib. 73 de Hrafnkell TF3HR On Wed, Jun 22, 2022 at 11:07 PM Black Michael via wsjt-devel wrote: The 706MKIIG does not do CAT PTT per se but the ptt-type=RTS should work. Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be why it's not working. And dtr_state=ON would only be needed if your CAT cable needs power from the computer to work. Mike W9MDB On Wednesday, June 22, 2022 at 11:35:27 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: Hi I'm running WSJT-X v2.5.4 on a Win10 computer.I've set up hamlib rigctld (version 4.4) on a Raspberry Pi and connected it to my Icom706mk2g.I'm using two com ports from the RPi, one for CAT control and one for PTT.I've set WSJT-X to use hamlib for rig control and pointed it to the ip:port of my RPi. Test CAT works fine and WSJT-X can set and read the frequency if I have PTT method set to Vox.If I set PTT method to CAT then Test CAT fails with the error:Rig failureHamlib error: IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)rig.c(1047):rig_open return(-6) IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)iofunc.c(361):port_close return(0) while opening connection to rig I can use the hamlib CAT PTT from other software such as Log4OM without issues.I would expect CAT PTT with hamlib rigcontrol in WSJT-X to behave the same, that is use hamlib calls to do PTT. My rigctld command line isrigctld --model=3011 --rig-file=/dev/ttyUSB0 --serial-speed=4800 --port=4532 --set-conf=stop_bits=1,dtr_state=ON,rts_state=ON --ptt-file=/dev/ttyUSB1 --ptt-type=RTS -Z Am I setting something wrong or misunderstanding something? Thanks Hrafnkell TF3HR___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel __
Re: [wsjt-devel] Hamlib rigcontrol and PTT
WSJT-X has to be set up to use the same RTS keying and the the /dev/ttyUSB1 port. Just tested it here and it uses it correctly (though I tested on Windows). Mike W9MDB On Thursday, June 23, 2022 at 03:53:35 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: > Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be >why it's not working.I have rts_state and dts_state ON to power the CAT >cable. The --set_conf option only seems to apply to the rig-file device, not >the ptt device. I can remove the rts_state=ON, it has no effect on PTT PTT over hamlib is working, it's just WSJT-X that is not using it. I can use e.g. a voice keyer in Log4OM and it does PTT properly through hamlib. 73 de Hrafnkell TF3HR On Wed, Jun 22, 2022 at 11:07 PM Black Michael via wsjt-devel wrote: The 706MKIIG does not do CAT PTT per se but the ptt-type=RTS should work. Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be why it's not working. And dtr_state=ON would only be needed if your CAT cable needs power from the computer to work. Mike W9MDB On Wednesday, June 22, 2022 at 11:35:27 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: Hi I'm running WSJT-X v2.5.4 on a Win10 computer.I've set up hamlib rigctld (version 4.4) on a Raspberry Pi and connected it to my Icom706mk2g.I'm using two com ports from the RPi, one for CAT control and one for PTT.I've set WSJT-X to use hamlib for rig control and pointed it to the ip:port of my RPi. Test CAT works fine and WSJT-X can set and read the frequency if I have PTT method set to Vox.If I set PTT method to CAT then Test CAT fails with the error:Rig failureHamlib error: IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)rig.c(1047):rig_open return(-6) IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)iofunc.c(361):port_close return(0) while opening connection to rig I can use the hamlib CAT PTT from other software such as Log4OM without issues.I would expect CAT PTT with hamlib rigcontrol in WSJT-X to behave the same, that is use hamlib calls to do PTT. My rigctld command line isrigctld --model=3011 --rig-file=/dev/ttyUSB0 --serial-speed=4800 --port=4532 --set-conf=stop_bits=1,dtr_state=ON,rts_state=ON --ptt-file=/dev/ttyUSB1 --ptt-type=RTS -Z Am I setting something wrong or misunderstanding something? Thanks Hrafnkell TF3HR___ 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 ___ 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] Hamlib rigcontrol and PTT
The 706MKIIG does not do CAT PTT per se but the ptt-type=RTS should work. Why do you have rst_state=ON? That conflicts with ptt-type=RTS and might be why it's not working. And dtr_state=ON would only be needed if your CAT cable needs power from the computer to work. Mike W9MDB On Wednesday, June 22, 2022 at 11:35:27 AM CDT, Hrafnkell Eiriksson via wsjt-devel wrote: Hi I'm running WSJT-X v2.5.4 on a Win10 computer.I've set up hamlib rigctld (version 4.4) on a Raspberry Pi and connected it to my Icom706mk2g.I'm using two com ports from the RPi, one for CAT control and one for PTT.I've set WSJT-X to use hamlib for rig control and pointed it to the ip:port of my RPi. Test CAT works fine and WSJT-X can set and read the frequency if I have PTT method set to Vox.If I set PTT method to CAT then Test CAT fails with the error:Rig failureHamlib error: IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)rig.c(1047):rig_open return(-6) IO errornetwork.c(441):network_close return(0)iofunc.c(361):port_close return(0)iofunc.c(361):port_close return(0) while opening connection to rig I can use the hamlib CAT PTT from other software such as Log4OM without issues.I would expect CAT PTT with hamlib rigcontrol in WSJT-X to behave the same, that is use hamlib calls to do PTT. My rigctld command line isrigctld --model=3011 --rig-file=/dev/ttyUSB0 --serial-speed=4800 --port=4532 --set-conf=stop_bits=1,dtr_state=ON,rts_state=ON --ptt-file=/dev/ttyUSB1 --ptt-type=RTS -Z Am I setting something wrong or misunderstanding something? Thanks Hrafnkell TF3HR___ 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] wsjtx_2.6.0-rc1_amd64.deb
Please test using rigctl to ensure this works. rigctl-wsjtx -m 16011 -r /dev/xx -s 57600 Adjust com port and baud rate to suit. Then run these two command W *TT 0 W *T0 0 First one should turn PTT on and 2nd one should turn it off. I don't have the ability to build a deb package for you. But if you can compile hamlib yourself it's been patched for this. Mike W9MDB On Thursday, June 16, 2022, 08:43:11 PM CDT, Andrew Neumeier via wsjt-devel wrote: Hello to the group, Downloaded the new release candidate today, trying it on a Omni VII. It has locked the rig in transmit such that the rig must be turned off and back on to receive. All the settings appear the same. I have returned to using the previous version. Have yet to investigate this further. I only tried FT8 mode, no others. The same situation occurs if I engage the TUNE button on the main screen or use the PTT button in settings. 73, Andy, ka2uqw ___ 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] Fwd: WSJT-X M1
Turn on "Controls" and adjust your "Start" to "Start 100" and your waterfall will look better. Flatten does not like to see the edges of one's bandpass. Mike W9MDB On Thursday, June 16, 2022, 09:06:49 PM CDT, Alex Lelievre via wsjt-devel wrote: I’ve been testing the 2.6.0-rc1 native Apple Silicon build. It’s working very nicely. You can grab it here: https://www.dropbox.com/s/dj7dx4swnh1pnas/wsjtx.app.zip?dl=0 There is a source code patch I need to apply to avoid a crash but otherwise works in FT8 mode perfectly (this is all I really test). I would love to be able to submit this patch as a pull-request. The patch is in grid2deg.f90. I’ve posted the patch to this list previously. It’s a string length issue with the newer and stricter gfortran compiler. Switching to MSK144 causes a runtime error immediately: At line 3 of file /Users/alex/opensource/wsjtx-build/wsjtx-prefix/src/wsjtx/lib/hspec.f90 Fortran runtime error: Actual string length is shorter than the declared one for dummy argument 'line1' (0/80) I tried to fix this by changing the parameters from 80 to (*). This didn’t really help because the problem is that the line1 variable is zero length so my fix only changes the runtime error to a hard crash. Oops- but the code does get a tiny bit further and I can see the mode change before crashing. I also have some additional feedback from Clarke K1JX who is testing the native build of 2.6.0rc-1: (For context: 2.6.0 fixes a crash in hamlib on Apple Silicon when using Elecraft rigs for CAT, yay!). Clarke writes: > It’s been going for about a half hour here, including a lot of transmit. > > So, obviously, the KX3 connects properly. > > For the first time in several versions, the slider controls for the waterfall > display and the Pwr work properly. I’d managed to get the Pwr set right and > just left it before, but it was impossible to set the waterfall. Now, it’s > like a miracle just happened. > > In addition, the slider control displays look right now, too. In the regular > Intel version I tried this afternoon, that wasn’t the case. > > Decodes are almost instant now and much smoother. I looked down and there > was 54 stations decoded in one FT8 period. Very fast. > > So, overall I’d have to say that you did great! I’ll keep you apprised of > what happens. > > 73, > > Clarke Thanks to Clarke for testing and thanks to everyone who contributes to WSJT-X! 73, alex K6LOT ___ 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] Hamlib testing
Please send new debug log. Mike On Monday, June 6, 2022, 12:55:22 PM CDT, Saku via wsjt-devel wrote: 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
You can get the absolute latest with git clone git clone https://github.com/Hamlib/Hamlib.git Mike W9MDB On Friday, June 3, 2022, 11:46:11 AM CDT, Saku via wsjt-devel wrote: 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/ 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 | | Date: 3.6.2022 klo 10.58 | | To: wsjt-devel@lists.sourceforge.net | | CC: Saku | 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 ___ 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 mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforg
Re: [wsjt-devel] Hamlib testing
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 belowhttps://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 fileMike 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/ 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 | | Date: 3.6.2022 klo 10.58 | | To: wsjt-devel@lists.sourceforge.net | | CC: Saku | 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 ___ 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 mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
I think this has been fixed in the latest Hamlib.http://n0nb.users.sourceforge.net/ Mike W9MDB On Friday, June 3, 2022, 03:06:21 AM CDT, Saku via wsjt-devel wrote: 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
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 | | Date: 3.6.2022 klo 10.58 | | To: wsjt-devel@lists.sourceforge.net | | CC: Saku | 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 ___ 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] Hamlib testing
You mean the Doppler tracking in the Astronomical window doesn't work? Mike W9MDB On Thursday, June 2, 2022, 07:24:04 AM CDT, Don Hawbaker wrote: On the 2.3 GHz EME band, we have to operate cross band. US transmits on 2304.1 while Europe transmits on 2320.1. Like wise, US receives on 2320.1 and Europe receives on 2304.1. That is a 16 MHz split. I use A B VFO and a transceiver that can receive 160.1 and transmit 144.1. But I cannot see a way to do Doppler correction. There is a schedule frequency, 2304.1 and all transceiver corrections are based on that frequency. Any ideas? Manual Doppler correction is not that hard at 2.3 GHz, I was just wondering if I missed some feature I could use. Thanks. Yes, I could switch the transverter LO frequency, but that is an additional complication I would like to avoid. It would have to be manual and would require running more wires. Some transverters, SG Labs, have to be restarted every time you switch LOs. Sent from my iPad > On May 31, 2022, at 12:09 PM, Black Michael via wsjt-devel > wrote: > > > 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
It's also to avoid the edges of your bandpass which can affect your transmitted power. Mike W9MDB On Wednesday, June 1, 2022, 11:14:49 PM CDT, Peter Sumner via wsjt-devel wrote: Hello Jarmo, when 'rig' or 'fake-it' is enabled the transmit frequency is moved to improve the location of your TX tones. As a test, try changing your TX baseband freq to say 200 Hz and set TX on, note the TX VFO frequency, then move baseband TX to 2300Hz and repeat, I would bet that you will see the are different frequencies offset on the TX vfo. For me I only use fake-it where the main VFO gets moved when I go to TX and it then comes back when I receive, it's all done to fight audio harmonics in the TX chain and defeat those masty images across our waterfall of people who unwittingly overdrive things. Regards, Peter, vk5pj On Thu, Jun 2, 2022 at 1:18 PM jarmo via wsjt-devel wrote: > Wed, 1 Jun 2022 16:13:42 + (UTC) > Black Michael via wsjt-devel > kirjoitti: > > Tested, but don't understand behaviour? Why freq goes -500 Hz when > tx'ing and stays there. I.E. I set 21074, both vfo, when first TX, lets > say vfo-b goes 21073500 and stays there. Where is this "delta" defined? > Ok, I don't use "rig split", because I have other vfo in use cw/ssb, > easy to change, when ever needed. And I don't use memories either... > Only simple things for simple person :) > > Jarmo, oh1mrr >> Could you please test the 890S in Rig Split? >> I have a report that the TS590SG works in Rig Split OK. >> Mike W9MDB >> >> >> >> On Wednesday, June 1, 2022, 10:57:51 AM CDT, jarmo via wsjt-devel >> wrote: >> Wed, 1 Jun 2022 08:05:06 -0700 >> Jim Preston via wsjt-devel >> kirjoitti: >> >> > On 5/31/2022 9:04 AM, Black Michael via wsjt-devel wrote: >> > > I need everyone to test the latest Hamlib >> > > Testing in Rig Split and Fake It would be appreciated. >> > > Successes/Failures please report. >> >> Works ok with TS-590SG and TS-890S. Tested only "fake it". Fedora 36 >> >> 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 > ___ 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] Hamlib testing
Could you please test the 890S in Rig Split? I have a report that the TS590SG works in Rig Split OK. Mike W9MDB On Wednesday, June 1, 2022, 10:57:51 AM CDT, jarmo via wsjt-devel wrote: Wed, 1 Jun 2022 08:05:06 -0700 Jim Preston via wsjt-devel kirjoitti: > On 5/31/2022 9:04 AM, Black Michael via wsjt-devel wrote: > > I need everyone to test the latest Hamlib > > Testing in Rig Split and Fake It would be appreciated. > > Successes/Failures please report. Works ok with TS-590SG and TS-890S. Tested only "fake it". Fedora 36 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
Re: [wsjt-devel] Hamlib testing
According to what I have the Xeigu X6100 does not have a Data/Pkt mode. You have something that indicates it does? If you can generate some debug with this and put the Xiegu into Data/Pkt before you start WSJT-X I can see what it is providing. Please place this file as described belowhttps://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 fileMike W9MDB On Tuesday, May 31, 2022, 04:17:41 PM CDT, Al Pawlowski via wsjt-devel wrote: I have two radios - ANAN-100B/Thetis and Xiegu X6100. Rig & Fake It split operation both work fine for the ANAN using FlexRadio/ANAN PowerSDR/Thetis, even when changing tx frequency during tx. Mode set for Data/PKT. I did not test USB. Fake It split operation works for the X6100 using Xiegu X6100, even when changing tx frequency during tx. Rig caused comm errors and no VFO changes. Mode set for USB. Data/Pkt does not work (comm errors) for either split operation. Al Pawlowski Los Osos, CA USA On May 31, 2022, at 10:38, wsjt-devel-requ...@lists.sourceforge.net wrote: Date: Tue, 31 May 2022 16:04:45 + (UTC) From: Black Michael To: WSJTX Group , WSJT Software Development Subject: [wsjt-devel] Hamlib testing Message-ID: <721045236.2890952.1654013085...@mail.yahoo.com> Content-Type: text/plain; charset="utf-8" I need everyone to test the latest Hamlib?Testing in Rig Split and Fake It would be appreciated.Successes/Failures please report. ___ 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] Hamlib testing
Could you please collect some debug demonstrating this? I think I may know
what's happening.When you change frequency while transmitting does VFOA or VFOB
change frequency?
$mypath$myrigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C
auto_power_on=0 $myvfo >/tmp/log.txt 2>&1 &
Mike W9MDB
On Tuesday, May 31, 2022, 12:27:15 PM CDT, Saku via wsjt-devel
wrote:
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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Hamlib testing
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
Re: [wsjt-devel] New Feature(s)
And JTAlert solves all of that problem for Windows. Mike W9MDB On Tuesday, May 17, 2022, 09:10:44 AM CDT, Dave Slotter, W3DJS via wsjt-devel wrote: A simpler solution, rather than asking the developers for a new feature, was simply be to enlarge the wsjtx window to make the list longer. On Tue, May 17, 2022, 9:28 AM Alan via wsjt-devel wrote: Hi, I have 2 suggestions: 1. When there are a large number of users on any one band the Band Activity screen overflows and you are looking for a particular station to work it often takes too long to find the call in the list thereby missing out on calling it. My suggestion is that a marker option (coloured text) could be allocated to a call making it easy to find it when the list is long and overflowing. 2. To make the screen easier and quicker to read indent the second call by the same ammount thus all callsigns would fall directly under one another. Thanks & 73Alan ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bug Report
How is your shack grounded? You'll find some adaptors on my QRZ page which you can use that can help.In the FT-991A case you can use the USB A-B adaptor which will break the USB shield connection to the rig and then you can use a-a cables instead like USB 3.0 cables which have better shielding. If you would can you test to see if there is a short between pin 4 on the FT-991 and the shield? Probably is shorted. Would like to add it to my list. Mike W9MDB On Monday, May 9, 2022, 10:13:56 AM CDT, W2JDM via wsjt-devel wrote: Perfect! That seems to be the issue. Set power down to 5W with no issues at all. Back up to 50W or above, and problems again. Ordered some ferrites and should be good to go! Didn’t even think of this as I have been very careful about grounding everything. Both the radio and tuner are grounded. Proves that RF can leak in even in a grounded system. From: David Tiller Date: Monday, May 9, 2022 at 10:33 AM To: WSJT software development Cc: W2JDM Subject: Re: [wsjt-devel] Bug Report Jason, This sounds like a textbook example of RFI getting into your computer or USB cable. I had a similar issue on 80m and found that a few well-placed ferrites on my USB cable fixed the issue. Search for "FT8 RFI" for other folks advice. To verify, try transmitting into a dummy load or at _very_ low power. If it doesn't happen, you've proven it's due to RFI. On May 9, 2022, at 10:25 AM, W2JDM via wsjt-devel wrote: WSJTX Version: 2.5.4 OS – Mac Monterey 12.3.1 Radio – Yaesu 991A SiliconLabs Driver – 6.0.2 for Mac When tuned to 40m (and only 40m), using FT8, the software loses CAT control shortly after transmitting. The symptoms are that it will hold the transmit too long and eventually show ORANGE status in WSJTX. It will reset and reconnect, but not after losing the QSO due to timing issues. This occurs each and every time I transmit on 40m, including when using TUNE. I want to emphasize that it seems to ONLY occur on 40m and not any other band. I use other software that also has CAT control over the 991A and it works as designed. I have also changed the mode to FT4 and 40m behaves normally. It seems isolated to only when using FT8 and 40m. Please let me know if you need any additional details. 73 Jason – W2JDM ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Decoding the Report from a DX Station from the UDP package
Yes...you need to parse the message yourself. It is in the Logged ADIF message but sounds like want it besides there. Mike W9MDB On Saturday, May 7, 2022, 06:09:11 AM CDT, Jaime Robles via wsjt-devel wrote: Good morning all, I am the developer of KLog. (https://github.com/ea4k/klog) I am having problems to find the report received from a contacted station when it answers my first call. What I have found is that WSJTX sends the received report in the message field in a Decode package... but it is only sent there? I mean... other data is sent in specific parts so I can easily find and extract them but not for the received report. Ona way is to parse the message, extracting my call, the DX Call and getting just the report. It is something not difficult but I feel I am missing something. The code to parse the UDP packages is here: https://github.com/ea4k/klog/blob/master/src/udpserver.cpp Thank you for your comments. Jaime, EA4K ___ 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] wsprd cli options
Are you looking for more than this? /wsprd: invalid option -- '?' Usage: wsprd [options...] infile infile must have suffix .wav or .c2 Options: -a path to writeable data files, default="." -B disable block demodulation - use single-symbol noncoherent demod -c write .c2 file at the end of the first pass -C maximum number of decoder cycles per bit, default 1 -d deeper search. Slower, a few more decodes -e x (x is transceiver dial frequency error in Hz) -f x (x is transceiver dial frequency in MHz) -H do not use (or update) the hash table -J use the stack decoder instead of Fano decoder -m decode wspr-15 .wav file -o n (0<=n<=5), decoding depth for OSD, default is disabled -q quick mode - doesn't dig deep for weak signals -s single pass mode, no subtraction (same as original wsprd) -v verbose mode (shows dupes) -w wideband mode - decode signals within +/- 150 Hz of center -z x (x is fano metric table bias, default is 0.45) On Sunday, May 1, 2022, 06:14:36 AM CDT, Jim Lill via wsjt-devel wrote: Where can I find detailed info or guidance on the use of the options, -C etc that can be applied to wsprd? tnx es 73 -Jim WA2ZKD ___ 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] up coming contest beta test
What exactly did you hear about? I know wsjtx improved may be releasing a new version soon with some additional contest support. Mike W9MDB On Thursday, April 14, 2022, 07:54:35 AM CDT, robert evans LAST_NAME via wsjt-devel wrote: Could we beta test this new ver. that I heard about on the DVRA meeting? BCNU DE N2LO~> ___ 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] SUGGESTION
And can you make CTRL-click keep it on please?There are use cases for it. Mike W9MDB On Sunday, March 6, 2022, 11:20:58 AM CST, DG2YCB, Uwe via wsjt-devel wrote: Hi all, Since I had similar requests for such a function in the past, I already programmed a time limit for the TUNE button a few weeks ago. This will be included in the next WSJTX release. 10 seconds is of course much too short, but I think 2 minutes is reasonable. This should be long enough to tune your antenna, but it effectively prevents unwanted continuous transmissions. 73 de Uwe, DG2YCB Von: Carey Fisher via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] Gesendet: Sonntag, 6. März 2022 14:26 An: WSJT software development Cc: Carey Fisher Betreff: Re: [wsjt-devel] SUGGESTION Uh, no! On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel wrote: Hello Not a huge priority, but one of those nice to have please… With the TUNE button, can this be limited to timeout at 10 seconds maximum please? >From experience, we all make silly mistakes, whilst tuning my FT-991A I got >distracted, with the result, I nuked the radio (since fixed) running on full >power on TUNE. It is not a pleasant experience the acrid smell of burning >electronic components! 73 Gavin ZL3GAV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Carey Fisher careyfis...@gmail.com ___ 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] Problem with flrig/wsjtx on Ubuntu
How do you have your audio hooked up?And what do you have the Transmit Audio Source set to in WSJT-X? You may need--set-conf=ptt_type=RIGor--set-conf=ptt_type=RIGMICDATA Mike W9MDB On Sunday, March 6, 2022, 12:04:57 AM CST, jarmo wrote: Sat, 5 Mar 2022 16:45:28 + (UTC) Black Michael via wsjt-devel kirjoitti: > There was a problem with muting that should be fixed in the latest > hamlib.But I'm not sure this is related to what you're describing > with rigctld. > > Mike W9MDB Hi Mike I compiled latest hamlib and no better. It can be tested by choosing wsjtx setting first radio as TS590SG or FT857, default settings, everything works OK, audio out, TX goes ok. BUT change radio into Hamlib Net rigctl, start rigctld first with "script" or manually, then try TX, audio out is muted. I have not found reason, but as said earlier, this started when took version 2.5.x of wsjtx in use. I'm not sure, if Fedora has this fault. Is it change from ALSA-PULSEAUDIO into ALSA-PIPEWIRE audio system... Hard to test with my skills... Jarmo, oh1mrr ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] SUGGESTION
My suggestion would be to default the Tune to 30 seconds (some tuners are slow) and then have CTRL-Click make it stick. Mike W9MDB On Sunday, March 6, 2022, 06:10:13 AM CST, Reino Talarmo via wsjt-devel wrote: I also belong to the continuous carrier lot. Already now there is the TX watch dog that can be set from 1 min to 99 min or disabled. I assume that the 1 min value could be good enough in most cases for those who don't want boil their rig.. The 1 min value seems to be maximum 1 min time depending when the Tune is activated. The watch god hit at 0, 15, 30 or 45 s of a minute. 73, Reino OH3mA On 3/6/22 04:39, Claude Frantz via wsjt-devel wrote: > > On 3/6/22 10:28, Charles Suckling via wsjt-devel wrote: > > Hi Charly & all, > >> I personally find it useful to be able to generate a continuous >> carrier with WSJT-X using the Tune button. > > I share this opinion, it's an important feature because many XCVR's do > not offer this function in a simple manner. > > Best wishes, > Claude (DJ0OT) ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Problem with flrig/wsjtx on Ubuntu
There was a problem with muting that should be fixed in the latest hamlib.But I'm not sure this is related to what you're describing with rigctld. Mike W9MDB On Saturday, March 5, 2022, 12:51:11 AM CST, jarmo via wsjt-devel wrote: Fri, 4 Mar 2022 18:22:10 +0100 Juergen Christlieb via wsjt-devel kirjoitti: > After everything worked fine for months, I suddenly no longer get any > control on the trx (possibly after an Ubuntu update?). Have meanwhile > flrig 1.3.49 and wsjtx 2.5.4 newly installed and of course tried all > possible settings. Recording and PTT works perfectly, but the signal > from the PC is not transmitted to the trx. > > Who can help? > > Many thanks in advance - Chris Not using flrig, but have had this issue with TS-590SG and FT-859D. All started when version 2.5.x came. Os is Fedora 35. I can get signal out just using RIG as TS-590SG and FT-859, but If I choose RIG as Hamlib Net rigctl, Signal is muted. I don't know if it has something to do ALSA/PIPEWIRE, but something dramatic happened, when 2.5.x version came.. Jarmo ___ 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] Fw: TS-590SG
Should be fixed in latest hamlib... New hamlib for Windows 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 #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 On Monday, February 14, 2022, 12:52:29 AM CST, jarmo via wsjt-devel wrote: Edelleenlähetetty viesti: Päiväys: Sat, 12 Feb 2022 10:37:52 +0200 Lähettäjä: jarmo Vastaanottaja: wsjt-devel@lists.sourceforge.net Aihe: TS-590SG Latest Hamlib update from Git.. rigctl Hamlib 4.5~git pe helmi 11 23:46:32 2022 + SHA=ea7eff TS-590Sg stopped working with WSJTX 2.5.4 Hope my picture shows some info. It is sgreenshot taken from Anydesk, so might not include all info.. Hamlib error: Protocol error rig_get_vfo: returning -8(Protocol error -9:kenwood.c(1051):kenwood_get_if return(-8) Kind a found and got someway working. Hamlib error was caused, because of CQRLOG also connecting. Now, I have CQRLOG set using 2 Hamlib NET rigctl and WSJTX using TS-590SG. If I set in WSJTX RIG as HAMLIB NET Rigctl, output audio is MUTED, but when radio is TS-590SG all is OK.. This "audio syndrome" came with wsjtx 2.5.x version. Ok, we can live with this configuration... Hopefully helping others struggling with TS590SG/CQRLOG/WSJTX 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
Re: [wsjt-devel] want to avoid duplicate/redundant effort: any work done towards integrating HackRF into WSJT-X?
No work that I know of. Do you have a reference for CAT control? It appears it's only for receiving and not transmitting, right? Mike W9MDB On Sunday, February 13, 2022, 04:42:53 PM CST, Lillian Kish via wsjt-devel wrote: I want to add direct rig control for the HackRF SDR into WSJT. Before I go and reinvent the wheel, i want to ask if any work has been done on this before? Thanks! ___ 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] Waterfall disappeared - I killed it somehow..??
Change the pulldown that says Reference to something else. Mike W9MDB On Sunday, February 13, 2022, 04:59:21 PM CST, Howard Ling via wsjt-devel wrote: Somehow I managed to make the waterfall disappear. I suspect that this was a bad combination of mouse movements & clicks, but don’t know what I did The results looks like attached Can someone help me fix this please..?? Thanks in advance 73, Howard, G4CCH ___ 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] a priori
No it's not by design -- it's an error in parsing that I thought was fixed before. Mike W9MDB On Wednesday, January 26, 2022, 09:10:11 AM CST, Reino Talarmo via wsjt-devel wrote: >The problem was that a signal decoded on 80M. I replied with a -18 SNR but >when the station replied with a R-13 it had the a priori code ? a3 after it. >WSJT-X didn't advance to the RR73 but instead sent the -18 report again. I >then received another R-13 ? a3 and then R-13 ? a2 with WSJT-X not advancing >to the RR73 both times. The next report was R-13 but no a priori code after it and WSJT-X advanced to the RR73. If you have any further questions please let me know. Hi Fred, I assume that what you saw is by design. It is left for the operator to decide, whether he is happy with the ? a2 addition or not. You could have hit the Tx 4 button on the Now row to send RR73 as you we happy. 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
[wsjt-devel] IOS Build
Anybody out there doing Mac compiles with XCode that could test a cross compile for IOS with WSJT-X? https://forum.qt.io/topic/130514/error-when-cross-compiling-for-ios-with-xcode13 Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT-991A WSJT-X unusable for me
There was a bug in the FT991 capabilities which has been fixed. Waiting to
hear if it fixes the chatter.
Still have another fix to do for non-targetable VFO B rigs to set mode on VFOB
just once.
Mike W9MDB
On Sunday, January 16, 2022, 11:46:39 AM CST, Tom M0LTE via wsjt-devel
wrote:
Probably one for the main mailing list (https://wsjtx.groups.io/g/main) rather
than the dev mailing list
That said, can you describe your whole cable setup please? The issue may be
obvious.
Tom M0LTE
On Sun, 16 Jan 2022 at 16:06, Richard Shaw via wsjt-devel
wrote:
Fedora Linux 35hamlib master (as of a couple of days ago)
WSJT-X 2.5.4
That being said, this has been a problem for some time for me over the last
couple of hamlib releases and several WSJT-X releases. Mike has worked with me
a couple of times to fix this, but it never STAYS fixed.
When trying to TX in WSJT-X I get rapid relay clatter. Sometimes it's only been
when using flrig, sometimes with both flrig and hamlib, which is the case right
now.
Running Flrig + Fldigi works fine. Running rigctl{,d} and putting the radio in
TX works fine.Trying "Test PTT" in WSJT-X works fine
But anytime I try to make a contact or press the PTT button I get rapid TX
relay clatter. The audio is turned all the way down so it can't be too much
audio signal, and anyway that usually goes into TX fine and then shuts down the
radio when that happens.
Here's a link to the rigctl
log:https://www.dropbox.com/s/js4fiixbnzm9tsg/WSJT-X_RigControl.log
Thanks,RichardKF5OIM
___
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT-991A WSJT-X unusable for me
I just made a patch.Let me know if this fixes the chatter. rig split is the problem. If you still get chatter try Fake It. The 991 does not have targetable mode so have to make another fix to allow Rig Split to set mode on VFOBas long as the chatter problem is fixed now. Mike W9MDB On Sunday, January 16, 2022, 11:22:34 AM CST, Richard Shaw via wsjt-devel wrote: On Sun, Jan 16, 2022 at 11:03 AM DG2YCB, Uwe via wsjt-devel wrote: Richard, Can you rule out that this is not an RF interference? Because my FT-991 runs flawlessly with WSJTX v2.5.4 on Linux Mint 20.2. Nothing else appears to be affected. Fldigi running PSK31, pat running ardop, keying CW, etc. On Sun, Jan 16, 2022 at 11:09 AM Tom M0LTE wrote: Probably one for the main mailing list (https://wsjtx.groups.io/g/main) rather than the dev mailing list That said, can you describe your whole cable setup please? The issue may be obvious. I posted here because Mike has helped me on the hamlib front on a couple of occasions already and been able to fix it, but it keeps rearing its ugly head. Nothing fancy, RF output hooked up to an 80m loop w/ 4:1 balun. Computer side is connected via the single USB connected using the radio's on board sound card. ttyUSB0 for CAT and ttyUSB1 for PTT. Radio is in DATA-U mode. Interestingly I don't get the green circle showing SPLIT until I change frequencies using the drop down. I would think it would initiate split on the front end. Thanks,RichardKF5OIM___ 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] FT-991A WSJT-X unusable for me
Uwe,
Are you using rig split? Richard is.
There is a problem in there for rig split.
Mike W9MDB
On Sunday, January 16, 2022, 11:03:11 AM CST, DG2YCB, Uwe via wsjt-devel
wrote:
Richard,
Can you rule out that this is not an RF interference? Because my FT-991 runs
flawlessly with WSJTX v2.5.4 on Linux Mint 20.2.
73 de Uwe DG2YCB
Von: Richard Shaw via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Gesendet: Sonntag, 16. Januar 2022 17:05
An: WSJT software development
Cc: Richard Shaw
Betreff: [wsjt-devel] FT-991A WSJT-X unusable for me
Fedora Linux 35
hamlib master (as of a couple of days ago)
WSJT-X 2.5.4
That being said, this has been a problem for some time for me over the last
couple of hamlib releases and several WSJT-X releases. Mike has worked with me
a couple of times to fix this, but it never STAYS fixed.
When trying to TX in WSJT-X I get rapid relay clatter. Sometimes it's only been
when using flrig, sometimes with both flrig and hamlib, which is the case right
now.
Running Flrig + Fldigi works fine.
Running rigctl{,d} and putting the radio in TX works fine.
Trying "Test PTT" in WSJT-X works fine
But anytime I try to make a contact or press the PTT button I get rapid TX
relay clatter. The audio is turned all the way down so it can't be too much
audio signal, and anyway that usually goes into TX fine and then shuts down the
radio when that happens.
Here's a link to the rigctl log:
https://www.dropbox.com/s/js4fiixbnzm9tsg/WSJT-X_RigControl.log
Thanks,
Richard
KF5OIM
___
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] Cleaner Updates/Installs
This is a long-standing problem that needs to be fixed.
WSJT-X should use a default path that includes the version#.
That will provide two things
#1 Very easy for user to start whichever version they want
#2 Avoid duplicate program entries
This patch makes the default install directory match the WSJT-X version.
diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index eceae4edf..ae1c70900 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -5,7 +5,8 @@
set (CPACK_PACKAGE_VENDOR "@PROJECT_VENDOR@")
set (CPACK_PACKAGE_CONTACT "@PROJECT_CONTACT@")
set (CPACK_RESOURCE_FILE_LICENSE "@PROJECT_SOURCE_DIR@/COPYING")
-set (CPACK_PACKAGE_INSTALL_DIRECTORY ${CPACK_PACKAGE_NAME})
+#set (CPACK_PACKAGE_INSTALL_DIRECTORY
${CPACK_PACKAGE_NAME}$NAME{CPACK_PACKAGE_VERSION_PATCH})
+set (CPACK_PACKAGE_INSTALL_DIRECTORY
"@CPACK_PACKAGE_NAME@-PACK_PACKAGE_VERSION_MAJOR@.@CPACK_PACKAGE_VERSION_MINOR@.@CPACK_PACKAGE_VERSION_PATCH@")
set (CPACK_PACKAGE_EXECUTABLES wsjtx "@PROJECT_NAME@")
set (CPACK_CREATE_DESKTOP_LINKS wsjtx)
set (CPACK_STRIP_FILES TRUE)
Mike W9MDB
On Monday, January 10, 2022, 12:57:41 AM CST, Dave Fitches via wsjt-devel
wrote:
Hi folks,
Firstly - awesome work with the program to everyone involved (past and
present!)
Just one nit-picky thing...
When we have a new version come out, and I install it, it creates a brand new
Start Menu folder for the new version.
So I now have in my Start Menu:
wsjtx 2.40
wsjtx 2.50
wsjtx 2.52
wsjtx 2.54
Likewise in my installed programs listing in "Add/Remove Programs" I have all 4
versions of the software listed. And given the program installs to the same
location every time it installs, if I remove the old versions of the software,
it causes no end of problems.
To remove the old versions I have to remove the oldest. Then because all the
files are gone, to remove the next oldest I have to re-install the new version.
THEN remove the next oldest. ...rinse and repeat.
To my mind - it should be working thus:
* If you're installing over an existing version in the SAME INSTALL DIRECTORY
(Default behaviour), then it should update the existing package and update the
version number in the Installed Programs list to prevent duplicate listings of
the same install location, and either use a Common Name for the Start Menu
folder, or remove the OLD Start Menu folder for the previous version number and
add the NEW version into Start Menu.
* If you're installing to a brand new directory and there's an existing copy
installed elsewhere, leave the existing stuff alone because some people might
want to run an old version and a new version, so list them seperately.
I admit - I have ZERO programming chops to do any of these things myself, but I
can make constructive suggestions for future releases!
Again - I wish to say I am in awe of the software as it stands! These points
above are piddling things, especially when compared to the joy this program
brings to a new Ham Operator working off a compromised antenna using QRP, and
is still able to make DX contacts despite that! If there was a "Donate here to
support this software" link - I'd be doing it!
Thanks and 73
de VK3DVF
--
= Dave 'Rusti' Fitches =
,--__|\ Dave 'Rusti' Fitches
/ \ VK3DVF
\_,--\_x/ * Mobile : +61-419-466-744
v * E-mail : vk3...@fitches.com
Melbourne, Victoria, Australia
___
Please Note: Unless this e-mail has been sent as PRIVATE, PERSONAL or
CONFIDENTIAL, the receiver may forward copies of it on the condition
that they send an advisory message to the original sender.
If however the message has been marked PRIVATE, PERSONAL or CONFIDENTIAL
prior consent MUST be obtained before the message can be forwarded.
___
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 2.5.4 RIG control error when using FTDX-3000 + USB Port.
Please use the latest hamlib and use the wsjtx_log_config.ini file to generate debug.Run 2.5.2 and generate one debug log.Then run 2.5.4 and generate another.Send both logs to my QRZ email address mdblac...@yahoo.com New hamlib for Windows 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 #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 == Please place this file in C:\Users\[username]\AppData\Local\WSJT-Xhttps://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0 Restart WSJT-X and duplicate the problem.Shut down WSJT-X Then send me the WSJT-X_RigControl.log file that will be in the same location. Mike W9MDB On Sunday, January 9, 2022, 01:23:26 AM CST, Yoshi,I via wsjt-devel wrote: Hi there, CAT control fails on FTDX-3000 + USB Port. If you use the FTDX-3000+USB port, two RS232C ports are created. No matter which one you use, it will not work, the RIG control error and TEST CAT will turn red. Of course I tried all the speeds of RS232C, but it remained an error. I renamed WSJT-X.ini, started WSJT-X again and started from the initial settings, but it is the same. There is no station around me using FTDX-3000 + USB, so I'm stopping here. Reverting to WSJT-X 2.5.2 and using the old WSJT-X.ini does not give any errors and is working fine. Are there any stations in a similar state? -- 73s de JH8XVH Yoshi -- このEメールはアバスト アンチウイルスによりウイルススキャンされています。 https://www.avast.com/antivirus ___ 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 syslog and the .WAV files issue.
Look at the menu Save and pick None -- that will stop keeping the wav files. The dropped audio is due to sound card latency enough to cause frames of sound data to be missed. Usually because the computer is too busy. Disk I/O can cause lots of problems. Make sure you exclude all your ham software directories from your virus scanner. Mike W9MDB On Saturday, January 1, 2022, 07:14:19 PM CST, Marco Calistri via wsjt-devel wrote: Hello and happy new year 2022! I have two request: 1- What this error I saw in the syslog means: [SYSLOG][2022-01-01 23:55:44.398661][01:12:40.285677][warning] Detected dropped audio source samples: 472 (0.009834 S) 2- Why you, dears developers, do not include the full disabling of the software save the so large . WAV files? I think that not everyone is using such audio files and due their size if you forget to empty the related folder, they tend to fill the disk space. IMHO you should include an user option to fully disable such audio files creation. Las but not least: from time to time I noticed WSJT-X closes suddenly without any apparent reason, then I need to restart it. Many thanks for your kindest attention and good DX! --- 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] WSJTx/HamLib Operation with Xiegu X6100
Are you sure the DTR/RTS isn't due to your serial interface needing them high to power the serial device?That's the only time I've ever seen those needed. You can download the new DLL from here http://n0nb.users.sourceforge.net/ later tonight that will be dat4ed 20211227. I added the X6100 with dtr and rts set high. And when you say Rig Split does not work what behavior do you see? Please place this file in C:\Users\[username]\AppData\Local\WSJT-Xhttps://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0 Restart WSJT-X and duplicate the problem.Shut down WSJT-X Then send me the WSJT-X_RigControl.log file that will be in the same location. Mike W9MDB On Monday, December 27, 2021, 06:04:17 PM CST, Al Pawlowski via wsjt-devel wrote: Just got one of the new X6100’s and wanted to pass on a setup I have found to operate with WSJTx - v2.5.3, x64 on Win10. Rig = Xiegu X108G - I read online IC-7000 would work also. it did not work well for me. Serial port = com10 - dropdown menu shows 3 new ports when the X6100 is plugged into a USB port - com8, com10 & USB. On my machine, com8 is audio in, com10 is both CAT and audio out. USB does nothing. Port does not work if speed not set to 19200. Data & Stop bits = default. Handshake = default, but port works better if DTR & RTS = high. PTT = CAT. Transmit Audio Source = greyed out. Split Operation = Fake It - Rig does not work. At the X6100, audio and CAT are via the the DEV USB-C port and in Radio Settings 1: Line Out Lv = 1 - about 60% level on WSJTx input, 0 gives no output to WSJTx, higher than 2 overloads WSJTx’s input. Line In Lv = 2 - full power out with WSJTx output set for -0.3dB, higher settings add distortion. Maybe a separate X6100 driver setup with default 19200 port speed, handshake and mode should be added to HamLib. Probably, the DTS/DTR = high and Mode = Rig not working should be further investigated also. Al Pawlowski, K6AVP Los Osos, CA USA ___ 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] 2.5.3 crash/issues after computer sleep
You are letting your PC go to sleep with all this running?Or are you saying that was just accidental? Mike W9MDB On Monday, December 27, 2021, 10:27:36 AM CST, Alan Groups via wsjt-devel wrote: Hi, I left WSJT-X running on Rx while I had to do something else, which unexpectedly took longer than I anticipated and the PC entered sleep mode. On awakening it I completed a QSO and on auto-log WSJT-X crashed, status.txt file error, path not found (it's in temp folder). Clicked OK to the error and the error box came back, clicked OK again and it went away. However it came back after auto logging another QSO. Restarting WSJT-X cleared it permanently. I've since tried to reproduce the issue, this time actively putting the PC to sleep using Start>Right click>Sleep. On awakening it WSJT-X would no longer key the rig, even though it was going into transmit mode, but this time the status.txt file error didn't appear. However, as above, a restart of WSJT-X cleared the issue. So far I've been unable to repeat either issue but I haven't seen this kind of behaviour before. W10 Pro 64 bit -- Alan G0TLK ___ 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 2.5.3 crashes on TX5 with slash in call
The problem is somewhat random. We've already found a fix for it and a new version should be released soon. Mike W9MDB On Friday, December 24, 2021, 11:19:53 AM CST, alan2--- via wsjt-devel wrote: Hi, I don't see this behaviour when sending a TX5 (at low power into a dummy load of course!) from my own call to my own call with /P added. If I try the same but with /MM instead of /P I don't see the behaviour either, but the /MM is not transmitted and is also not shown anywhere in the UI apart from the TX5 box. W10 64 Pro, latest updates Alan G0TLK On 24/12/2021 07:48, Rich - K1HTV via wsjt-devel wrote: I have run into a problem with WSJT-X 2.5.3 when transmitting a TX5 message to any station with a "/" followed by /MM or /P and probably other characters. I'm running the Win 64 bit version on a Windows 10 computer with the latest updates. After transmitting the TX5 message, the receive cycle starts and runs for 11 seconds. At that point the clock in the lower left corner stops and a few lines of decoded data is displayed, then the program ends. The problem ican be reproduced. A jt9.exe process is left running, which must be deleted with Task Manager before WSJT-X can be started again. The issue only occurs with stations with a forward slash in the callsign. I tried using a non-standard callsign such as 3DA0XXX, with no problem, only with calls with slash. I've gone back to WSJT-X Version 2.5.2 and ran the same tests without the program crashing after a TX5 message with a forward slash in the call. 73, Rich - K1HTV ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Reproducing 2.5.3 /4 crash WSJT-x
I was able to reproduce this under WinDbg and using audio loopback and my own callsign.It happened after the transmit of W9MDB R-20Which also matches the behavior seen by Tom AA4VV Critical error detected c374 (6fbc.6fb8): Break instruction exception - code 8003 (first chance) ntdll!RtlReportCriticalFailure+0x56: And here's the stack -- not very informative. Appears to be in the event handler. Gotta' love C++ name mangling.[0x0] ntdll!RtlReportCriticalFailure + 0x56 [0x1] ntdll!RtlpHeapHandleError + 0x12 [0x2] ntdll!RtlpHpHeapHandleError + 0x7a [0x3] ntdll!RtlpLogHeapFailure + 0x45 [0x4] ntdll!RtlpFreeHeapInternal + 0x825 [0x5] ntdll!RtlFreeHeap + 0x51 [0x6] msvcrt!free + 0x1c [0x7] wsjtx + 0xc04b0 [0x8] wsjtx + 0xcc5f9 [0x9] Qt5Core!ZN9QMimeType18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv + 0x57c75 [0xa] Qt5Core!ZN8QProcess14setEnvironmentERK11QStringList + 0x1ee [0xb] Qt5Core!ZN8QProcess18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv + 0x205 [0xc] Qt5Core!ZN9QMimeType18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv + 0x57cab [0xd] Qt5Core!ZN18QWindowsPipeReader20emitPendingReadyReadEv + 0x32 [0xe] Qt5Core!ZN14QMetaCallEvent13placeMetaCallEP7QObject + 0x31 [0xf] Qt5Core!ZN7QObject5eventEP6QEvent + 0x175 [0x10] Qt5Widgets!ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent + 0x7e [0x11] Qt5Widgets!ZN12QApplication6notifyEP7QObjectP6QEvent + 0x253 [0x12] wsjtx + 0x218934 [0x13] Qt5Core!ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent + 0x19a [0x14] Qt5Core!ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData + 0x175 [0x15] qwindows!qt_plugin_instance + 0x28ee [0x16] Qt5Core!ZN21QEventDispatcherWin3213processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE + 0x930 [0x17] qwindows!qt_plugin_instance + 0x28d5 [0x18] Qt5Core!ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE + 0x135 [0x19] Qt5Core!ZN16QCoreApplication4execEv + 0x75 [0x1a] wsjtx + 0x37fcbc [0x1b] wsjtx + 0x13c7 [0x1c] wsjtx + 0x14cb [0x1d] KERNEL32!BaseThreadInitThunk + 0x10 [0x1e] ntdll!RtlUserThreadStart + 0x2b On Tuesday, December 21, 2021, 02:44:35 PM CST, Tom Berry via wsjt-devel wrote: On 12/21/2021 3:04 PM, Joe Taylor via wsjt-devel wrote: > Hi all, > > If you have seen a bug that can cause WSJT-X 2.5.3 to crash when > callsigns like W9YOY/M or K0VQM/4 are involved, please help us to > isolate and fix it. What we really need is a sequence of steps that > will reliably reproduce the crash. > > If you have seen this bug, please let us know. If you can reproduce > it, please send us a recipe. > > -- 73, Joe, K1JT > I have had the problem with my Apache Labs 7000 radio and HI3T/QRP. I called him. He answered with AA4VV -08 I then sent AA4VV R-10 Then the program exited. WSJT would not run until I rebooted the computer. I called him again and the same think happened. (after reboot) WSJT-X 2.5.3 Win 10 Apachie Labs 7000 Radio FT8. 73 Tom AA4VV ___ 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] Reproducing 2.5.3 /4 crash WSJT-x
If you could please run WinDbg and attach it to the WSJT-X process.Maybe it will tell us something. https://www.microsoft.com/en-us/p/windbg/9pgjgd53tn86?rtc=1=pivot:overviewtab Mike W9MDB On Tuesday, December 21, 2021, 02:44:35 PM CST, Tom Berry via wsjt-devel wrote: On 12/21/2021 3:04 PM, Joe Taylor via wsjt-devel wrote: > Hi all, > > If you have seen a bug that can cause WSJT-X 2.5.3 to crash when > callsigns like W9YOY/M or K0VQM/4 are involved, please help us to > isolate and fix it. What we really need is a sequence of steps that > will reliably reproduce the crash. > > If you have seen this bug, please let us know. If you can reproduce > it, please send us a recipe. > > -- 73, Joe, K1JT > I have had the problem with my Apache Labs 7000 radio and HI3T/QRP. I called him. He answered with AA4VV -08 I then sent AA4VV R-10 Then the program exited. WSJT would not run until I rebooted the computer. I called him again and the same think happened. (after reboot) WSJT-X 2.5.3 Win 10 Apachie Labs 7000 Radio FT8. 73 Tom AA4VV ___ 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] Reproducing 2.5.3 /4 crash WSJT-x
Nope...tested several calls on loopback both on receiver and transmitter side in both QSO directionsno problems. The only common thread is the suffix it seems. I even used one user's WSJT-X.ini file though I don't have his rig so had to change that one thing.Ran the same test that he said crashed and didn't happen here. So far it seems it's all Windows users and not Linux or Mac that I've noticed yet. Mike On Tuesday, December 21, 2021, 12:56:58 PM CST, Joe Taylor via wsjt-devel wrote: Hi Mike, Have you had any success duplicating the problem some have seen with calls like W9YOY/M or K0VQM/4 ? I have been unable to make v2.5.3 crash, using any of these recipes. -- Joe On 12/20/2021 2:21 PM, Black Michael via wsjt-devel wrote: > There's a problem duplicating this error...I tried a loopback test here > and no crashes > > Soquestion for those seeing this problem. > > For Dana...it sounds like you did a restart of WSJT-X and duplicated the > problem, right? > > So maybe there's a setting in WSJT_X that is related. > > Can you send your WSJT_X.ini file? > > Mike W9MDB > > > > > On Monday, December 20, 2021, 12:23:32 PM CST, Dana Myers via wsjt-devel > wrote: > > > Hello, > > I'm seeing a crash - twice a moment ago - when W9YOY/M called me. Using > 2.5.3. Also running > JT-Alert for WSJT-X > > Perhaps related? > > 73, > Dana K6JQ > > > On 12/17/2021 7:43 AM, Al via wsjt-devel wrote: > ( wsjt-x 2.5.3, W11 ) > > Set mode FT8 > Enter DX call K0VQM/4 > Generate Std Msgs > select Next 'TX 3' > enable TX > WSJT will crash on second or third transmission attempt > > AL, K0VM > > > ___ > 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 > 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
Re: [wsjt-devel] Reproducing 2.5.3 /4 crash WSJT-x
Hard to test all the corner cases like suffixes under what appear to be certain circumstances. One of the problems I have with hamlib is I get no testing until WSJT-X or JTDX get released. I have 264 rigs now to support and can't test but a few. The git log isn't very helpful and since it's not easily reproducible a bisect isn't worthwhile. valgrind shows nothing on Linux. Mike On Monday, December 20, 2021, 05:02:12 PM CST, Laurie, VK3AMA via wsjt-devel wrote: On 21/12/2021 8:04 am, Black Michael via wsjt-devel wrote: > Well yes it's multi-threaded. Don't believe that's the underlying > cause though. > > Is there a common rig maybe? > > So far we have 1 IC-7300. > > Or a common OS? > > Or a common 32/64-bit version? > > For those that have seen this problem please report > > Rig > OS > 32/64 WSJT-X > Other software running > > Mike W9MDB Mike, I wonder if there were not-fully tested changes in the code before the 2.5.3 release shortly after Bill's sudden passing? Do you have access to the GIT repo? Perhaps something can be gleaned from looking at the 2.5.3 commits. de Laurie VK3AMA ___ 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] Reproducing 2.5.3 /4 crash WSJT-x
Well yes it's multi-threaded. Don't believe that's the underlying cause though. Is there a common rig maybe? So far we have 1 IC-7300. Or a common OS? Or a common 32/64-bit version? For those that have seen this problem please report RigOS32/64 WSJT-XOther software running Mike W9MDB On Monday, December 20, 2021, 02:54:55 PM CST, DANA MYERS via wsjt-devel wrote: This does sound rather like a Heisenbug, I haven't looked at the internal structure of WSJT-X, I bet it's multi-threaded. 73, Dana K6JQ On 12/20/2021 12:26 PM Reino Talarmo via wsjt-devel wrote: Hi Mike, I tested one wsjt-x.ini file that was available Saturday 18.12. from Al, who has the same “feature”. I used two windows 10 computers and set an audio connection between those and used various “/” callsigns. I could not repeat the issue at all. There was also available a windows error log that indicated that the error was Faulting application path: C:\WSJT\wsjtx\bin\wsjtx.exe Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll I have no idea whether that helps at all. Hope that you can find a possible setting issue. 73, Reino OH3mA From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] Sent: 20. joulukuutata 2021 21:21 To: wsjt-devel@lists.sourceforge.net Cc: Black Michael Subject: Re: [wsjt-devel] Reproducing 2.5.3 /4 crash WSJT-x There's a problem duplicating this error...I tried a loopback test here and no crashes Soquestion for those seeing this problem. For Dana...it sounds like you did a restart of WSJT-X and duplicated the problem, right? So maybe there's a setting in WSJT_X that is related. Can you send your WSJT_X.ini file? Mike W9MDB On Monday, December 20, 2021, 12:23:32 PM CST, Dana Myers via wsjt-devel wrote: Hello, I'm seeing a crash - twice a moment ago - when W9YOY/M called me. Using 2.5.3. Also running JT-Alert for WSJT-X Perhaps related? 73, Dana K6JQ On 12/17/2021 7:43 AM, Al via wsjt-devel wrote: ( wsjt-x 2.5.3, W11 ) Set mode FT8 Enter DX call K0VQM/4 Generate Std Msgs select Next 'TX 3' enable TX WSJT will crash on second or third transmission attempt AL, K0VM ___ 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 ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Reproducing 2.5.3 /4 crash WSJT-x
There's a problem duplicating this error...I tried a loopback test here and no crashes Soquestion for those seeing this problem. For Dana...it sounds like you did a restart of WSJT-X and duplicated the problem, right? So maybe there's a setting in WSJT_X that is related. Can you send your WSJT_X.ini file? Mike W9MDB On Monday, December 20, 2021, 12:23:32 PM CST, Dana Myers via wsjt-devel wrote: Hello, I'm seeing a crash - twice a moment ago - when W9YOY/M called me. Using 2.5.3. Also running JT-Alert for WSJT-X Perhaps related? 73, Dana K6JQ On 12/17/2021 7:43 AM, Al via wsjt-devel wrote: ( wsjt-x 2.5.3, W11 ) Set mode FT8 Enter DX call K0VQM/4 Generate Std Msgs select Next 'TX 3' enable TX WSJT will crash on second or third transmission attempt AL, K0VM ___ 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 ___ 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
Get the latest hamlib from here...IC-7300 behavior (and other Icoms) should all be good now. https://github.com/Hamlib/Hamlib.git Mike W9MDB On Tuesday, December 14, 2021, 10:09:11 AM CST, Kari Sillanmäki via wsjt-devel wrote: Hi, I did some tests as well... On 14.12.2021 12.19, Saku via wsjt-devel wrote: > Today I upgraded Fedora 34 to version 35. I'm still at "Ubuntu 18.04.6 LTS" > As expected the self compiled wsjtx did not start any more. Mine does ;) > 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 I pulled hamlib from git://git.code.sf.net/u/bsomervi/ and compiled. The resulting rigctld vesion is: rigctl Hamlib 4.4~git to marras 25 22:02:50 2021 + SHA=7349a0 > > - pulls wsjtx from > [remote "origin"] > url = https://git.code.sf.net/p/wsjt/wsjtx > - compiles and installs it > Wsjtx version 2.5.2 I downloaded the snapshot commit 69f9ec from SourceForge and compiled it. The resulting WSJT-X version is 2.5.3. > Rig is icom ic7300. So is mine. > 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 & Tested starting "./rigctld-wsjtx -r /dev/ttyUSB0 -m 3073 -s 19200" > It seems that again ic7300 is broken with latest hamlib source. With my setup above nearly everything works OK when using Split=Fake-it. Split=Rig still has the old problem where mode is not set to USB-D if WFO-B is not on USB-D already. 73's de Kari, oh2gqc ___ 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] hamlib repo at git.code.sf.net/u/bsomervi/hamlib
Since Bill is silent key now there is no need for that repository anymore and should probably be removed. The Hamlib repository is here https://github.com/Hamlib/Hamlib Mike W9MDB On Tuesday, December 14, 2021, 01:51:02 AM CST, Claude Frantz via wsjt-devel wrote: Hi all, What is about the future maintenance of the special hamlib at git.code.sf.net/u/bsomervi/hamlib ? Best whishes, Claude (DJ0OT) ___ 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] Split, K3 and TS-450 Rig Control
Dave, Please contact me off-listmdblac...@yahoo.com Mike W9DMB On Wednesday, December 1, 2021, 11:25:58 PM CST, Dave J Barnes via wsjt-devel wrote: So a new version of wsjtx is coming in a few days? On 12/1/21 10:49 PM, Black Michael via wsjt-devel wrote: You should be able to build it yourself from the tar.gz file. Just be sure to remove the hamlib package you already have installed as it installs in /usr/local Or you can configure it this way ./configure --prefix=/usr Mike W9MDB On Wednesday, December 1, 2021, 10:24:03 PM CST, Dave J Barnes via wsjt-devel wrote: Any help for Linux users? On 12/1/21 10:16 PM, Black Michael via wsjt-devel wrote: Please try the latest dll. This version is due to be 4.4 to be released in the next few days. New hamlib for Windows installation directions #1 Shut down WSJTX #2 Download either the 32-bit or 64-bit DLL -- 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 #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 On Wednesday, December 1, 2021, 09:29:38 PM CST, Dave J Barnes via wsjt-devel wrote: I looked through the archives but I don't see any resolution to the rig control issues with using split on the TS-450. Split is broken on the K3 too. The only setting that works is "fake it". Using "rig" for split on the K3 will try to adjust the tx frequency to keep the tones in the passband but then quickly changes back to the receive frequency thus transmitting on the wrong frequency. I believe this bug is why the middle of the FT8 segment stays crowded. It used to work. I verified that 2.40 works as I remember -- "rig" split mode keeps the tx frequency adjusted for the passband. Is there an additional setting I need? wsjtx 2.5.2 Linux 64 bit Ubuntu 20.04 djb WB4KDI ___ 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 ___ 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 ___ 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] Split, K3 and TS-450 Rig Control
No. There is no scheduled date for the next release. Mike W9MDB On Wednesday, December 1, 2021, 11:25:58 PM CST, Dave J Barnes via wsjt-devel wrote: So a new version of wsjtx is coming in a few days? On 12/1/21 10:49 PM, Black Michael via wsjt-devel wrote: You should be able to build it yourself from the tar.gz file. Just be sure to remove the hamlib package you already have installed as it installs in /usr/local Or you can configure it this way ./configure --prefix=/usr Mike W9MDB On Wednesday, December 1, 2021, 10:24:03 PM CST, Dave J Barnes via wsjt-devel wrote: Any help for Linux users? On 12/1/21 10:16 PM, Black Michael via wsjt-devel wrote: Please try the latest dll. This version is due to be 4.4 to be released in the next few days. New hamlib for Windows installation directions #1 Shut down WSJTX #2 Download either the 32-bit or 64-bit DLL -- 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 #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 On Wednesday, December 1, 2021, 09:29:38 PM CST, Dave J Barnes via wsjt-devel wrote: I looked through the archives but I don't see any resolution to the rig control issues with using split on the TS-450. Split is broken on the K3 too. The only setting that works is "fake it". Using "rig" for split on the K3 will try to adjust the tx frequency to keep the tones in the passband but then quickly changes back to the receive frequency thus transmitting on the wrong frequency. I believe this bug is why the middle of the FT8 segment stays crowded. It used to work. I verified that 2.40 works as I remember -- "rig" split mode keeps the tx frequency adjusted for the passband. Is there an additional setting I need? wsjtx 2.5.2 Linux 64 bit Ubuntu 20.04 djb WB4KDI ___ 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 ___ 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 ___ 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] Split, K3 and TS-450 Rig Control
You should be able to build it yourself from the tar.gz file. Just be sure to remove the hamlib package you already have installed as it installs in /usr/local Or you can configure it this way ./configure --prefix=/usr Mike W9MDB On Wednesday, December 1, 2021, 10:24:03 PM CST, Dave J Barnes via wsjt-devel wrote: Any help for Linux users? On 12/1/21 10:16 PM, Black Michael via wsjt-devel wrote: Please try the latest dll. This version is due to be 4.4 to be released in the next few days. New hamlib for Windows installation directions #1 Shut down WSJTX #2 Download either the 32-bit or 64-bit DLL -- 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 #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 On Wednesday, December 1, 2021, 09:29:38 PM CST, Dave J Barnes via wsjt-devel wrote: I looked through the archives but I don't see any resolution to the rig control issues with using split on the TS-450. Split is broken on the K3 too. The only setting that works is "fake it". Using "rig" for split on the K3 will try to adjust the tx frequency to keep the tones in the passband but then quickly changes back to the receive frequency thus transmitting on the wrong frequency. I believe this bug is why the middle of the FT8 segment stays crowded. It used to work. I verified that 2.40 works as I remember -- "rig" split mode keeps the tx frequency adjusted for the passband. Is there an additional setting I need? wsjtx 2.5.2 Linux 64 bit Ubuntu 20.04 djb WB4KDI ___ 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 ___ 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] Split, K3 and TS-450 Rig Control
Please try the latest dll.This version is due to be 4.4 to be released in the next few days. New hamlib for Windows installation directions#1 Shut down WSJTX#2 Download either the 32-bit or 64-bit DLL -- 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.dllhttp://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll#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 On Wednesday, December 1, 2021, 09:29:38 PM CST, Dave J Barnes via wsjt-devel wrote: I looked through the archives but I don't see any resolution to the rig control issues with using split on the TS-450. Split is broken on the K3 too. The only setting that works is "fake it". Using "rig" for split on the K3 will try to adjust the tx frequency to keep the tones in the passband but then quickly changes back to the receive frequency thus transmitting on the wrong frequency. I believe this bug is why the middle of the FT8 segment stays crowded. It used to work. I verified that 2.40 works as I remember -- "rig" split mode keeps the tx frequency adjusted for the passband. Is there an additional setting I need? wsjtx 2.5.2 Linux 64 bit Ubuntu 20.04 djb WB4KDI ___ 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 v2.5.2 possible hamlib bugs
It has been fixed. Just need to install the new dll. New hamlib for Windows installation directions#1 Shut down WSJTX#2 Download either the 32-bit or 64-bit DLL -- 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.dllhttp://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll#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 On Thursday, November 18, 2021, 10:23:36 PM CST, Bob McCormick via wsjt-devel wrote: This evening I upgraded the NC1I 23cm EME station from v2.5.1 to v2.5.2 and encountered some problems: - a 3 to 4 second delay before TX is enabled - this acts like a problem we saw on the 70cm station some weeks back and was fixed (regression?) - rig control doppler TX and RX rig frequencies do not seem correct Additionally - in v2.5.2 clicking the Tune button has a noticeable delay, whereas the 70cm station with v2.5.1 the tune is almost instantaneous. Reinstalling v2.5.1 on top of the updated v2.5.2 version restored proper functionality: keying is immediate and frequencies are correct. CAT is to a microHAM microKeyer II that is connected to a K3 PTT is to a virtual COM port on the microHAM router that controls the K3 No settings were changed going back and forth between v2.5.1 and v2.5.2 I see Mike's previous posting in this list about a new hamlib package - I can give that a try sometime, but tomorrow starts the EME contest so don't want to make any more changes until after the contest. Bob W1QA ___ 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] Status File Error WSJT-X v2.5.2
Exclude the path in your antivirus.You can google "defender exclusions" or such depending on your antivirus. Mike W9MDB On Thursday, November 18, 2021, 09:47:23 AM CST, Rich - K1HTV via wsjt-devel wrote: Since I started using WSJT-X version 2.5.2, I have seen thiserror message pop up every few days. Sometimes I must click the OK button multiple times tofinally clear the last of multiple “Status File Error” message boxes. I checked the path and there is no WSJT-X folder in the “k1htv\AppData\Local\Temp”folder. Any idea what might be triggering this error message? 73, Rich – K1HTV ___ 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] VFOs reversing
This thread has side tracked.What rig are you running? Is it possible to set a different mode on VFOB? If not we can put some logic in to avoid setting mode on VFOB. Most rigs can set VFOB to a separate mode but older rigs do not have targetable mode. FR1 is not supposed to turn on split on most rigs...it's a VFO change. FT is what turns on split.The FR1 is changing to VFOB to set the mode and to avoid strange rig flashing we do this:split offchange to vfobset mode change to vfoasplit on Mike W9MDB On Tuesday, November 16, 2021, 11:57:10 PM CST, Sam W2JDB via wsjt-devel wrote: Hi Bill and MIke, "and/or If Split is already set in the radio." Please disregard the comment about the current Split status of the rig. I forgot that in the response to the 'IF;' command, that message contains the split indication.My apologies. 73, Sam W2JDB ___ 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] VFOs reversing
Moreover most rigs with targetable frequency do not have a "set freq on current VFO"newer Icom's are an exception to that.Rigs that do NOT have targetable frequency only have that (a lot of older rigs). So the idea of doing the vfo swapping works non-targetable rigs but not targetable ones. Hamlib supports 254 rigs now and I'm seeing more edge cases of behaviors partly due to speed ups in the serial I/O. Knob twiddling has been a problem for a long time when users start twiddling knobs.The only knob twiddling I really care about supporting is for satellite doppler work since that is computer controlled and critical to operations.Other cases get support if possible but generally at lower priority. Currently hamlib just reports whatever the rig claims is the current VFO and in some cases a simulated answer and I'm not inclined to overrule the rig answer but provide a better VFO method to start using RX/TX VFO options instead of VFOA/B and Main/Sub. Mike W9MDB On Saturday, November 13, 2021, 04:15:54 AM CST, Bill Somerville via wsjt-devel wrote: Sam, WADR before you suggest re-engineering the way WSJT-X controls rigs via Hamlib I think you should take some time to review the Hamlib library API. Note that the client API does not require client applications to know what rig is being controlled or to issue low level CAT commands. https://github.com/Hamlib/Hamlib/wiki/Documentation 73 Bill G4WJS. On 12/11/2021 23:11, Sam W2JDB via wsjt-devel wrote: > Hi, > > The problem that I can see cropping up is that on some rigs you can not > change the frequency of the Sub VFO until it becomes the Main VFO when > the rig status changes to TX. > > You (WSJT-X) might be able to use a workaround by issuing a swap > VFO command change the TX frequency (if needed) on the new > Main VFO and then issue another swap VFO command. > > At this point you can start the TX process and let rig then takes care > of the correct VFO swap. Mike will not need any convoluted code to > track which is the Main VFO or Sub VFO. > > Just my two cents on this problem. > > 73, > > Sam W2JDB > > > > -Original Message- > From: Bill Somerville via wsjt-devel > To: wsjt-devel@lists.sourceforge.net > Cc: Bill Somerville > Sent: Fri, Nov 12, 2021 4:56 pm > Subject: Re: [wsjt-devel] VFOs reversing > > On 12/11/2021 18:09, Black Michael via wsjt-devel wrote: > > This is on an Elecraft K4. > > When transmitting in split mode VFOA=Rx and VFOB=Tx and one changes > > the Tx frequency WSJT-X assumes since VFOB is the current VFO that it > > reverses roles and sets VFOA frequency instead. > > If VFOB is active and split and ptt=on then VFOB is still tx. I > > really don't know if this applies to all rigs though. > > > > Mike W9MDB > > Mike, > > to deal with that sort of behaviour either all rigs must do the same > thing or WSJT-X will have to determine the rig and decide if the current > VFO changes (as reported by Hamlib) when transmitting split on a rig by > rig basis. Given that a number of rigs cannot be queried for the current > VFO I would think that the best option for Hamlib is not to change the > current VFO when transmitting split. > > 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] Yaesu Rig Split problem
New hamlib for Windows installation directions#1 Shut down WSJTX#2 Download either the 32-bit or 64-bit DLL -- 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.dllhttp://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll#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 On Friday, November 5, 2021, 05:39:18 AM CDT, Ari Hyvonen via wsjt-devel wrote: Hi Mike, WSJT-X 2.5.2 64bit Win 10, Yaesu FT-1000MP MKv + Microham Keyer III was testing the Rig Split behaviour with my setup, if I select the Rig Split option, I can see that the VFOB briefly shows the correct frequency, but then jumps back to VFOA frequency. In this test Tx was set to 600Hz, so it should set TX to 28073. This can be seen from microham CAT monitor when I briefly put Tune on this section could be the cause:0360160125: H1-TX: (0) 00 00 00 00 05 -> Select VFO A 0360160156: H1-TX: (0) 00 00 00 00 85 -> A->B 0360160203: H1-TX: (0) 00 00 00 01 01 -> Split on 0360160234: H1-TX: (0) 00 73 80 02 8A -> Set VFO B frequency 0360160265: H1-TX: (0) 00 00 00 00 05 -> Again select VFO A 0360160312: H1-TX: (0) 00 00 00 00 85 - > Again A->B, So this puts back the 28074 to the VFO B 0360160343: H1-TX: (0) 00 00 00 01 01 Regards,Ari, OH6DX 0360158937: Log enabled, (urouter v9.3.4, micro KEYER II v6.21) 0360158937: CAT settings: "Yaesu FT-1000MP MkV", 4800 bps 8N2 (controlled by COM8 4800 bps 8N2 , router queries enabled) 0360159015: H1-RX: (1) 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 (Status Update, VFOA and VFOB: USB, USB, 28074000 Hz, 28074000 Hz) 0360159140: R-TX: (1) 00 00 00 02 10 (Status Update, Current Operation) 0360159187: R-RX: (1) 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 (Status Update, Current Operation: USB, 28074000 Hz) 0360159312: R-TX: (1) 00 00 00 01 FA (Read Internal Status Flags (6 Byte Format)) 0360159343: R-RX: (1) 09 20 00 00 00 00 (Read Internal Status Flags (6 Byte Format): VFO A, split on, dual off, ) 0360159609: H1-TX: (1) 00 00 00 00 FA (Read Internal Status Flags (5 Byte Format)) 0360159640: H1-RX: (1) 01 20 00 03 93 (Read Internal Status Flags (5 Byte Format)) 0360159656: H1-TX: (1) 00 00 00 00 FA (Read Internal Status Flags (5 Byte Format)) 0360159687: H1-RX: (1) 09 20 00 03 93 (Read Internal Status Flags (5 Byte Format)) 0360159703: H1-TX: (1) 00 00 00 03 10 (Status Update, VFOA and VFOB) 0360159796: H1-RX: (1) 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 (Status Update, VFOA and VFOB: USB, USB, 28074000 Hz, 28074000 Hz) 0360159828: H1-TX: (1) 00 00 00 03 10 (Status Update, VFOA and VFOB) 0360159906: H1-RX: (1) 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 (Status Update, VFOA and VFOB: USB, USB, 28074000 Hz, 28074000 Hz) 0360159953: H1-TX: (1) 00 00 00 03 10 (Status Update, VFOA and VFOB) 0360160031: H1-RX: (1) 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 (Status Update, VFOA and VFOB: USB, USB, 28074000 Hz, 28074000 Hz) 0360160125: H1-TX: (0) 00 00 00 00 05 0360160156: H1-TX: (0) 00 00 00 00 85 0360160203: H1-TX: (0) 00 00 00 01 01 0360160234: H1-TX: (0) 00 73 80 02 8A 0360160265: H1-TX: (0) 00 00 00 00 05 0360160312: H1-TX: (0) 00 00 00 00 85 0360160343: H1-TX: (0) 00 00 00 01 01 0360160375: sending of router queries and evaluation of answers suspended (PTT active) 0360160609: H1-TX: (1) 00 00 00 00 FA (Read Internal Status Flags (5 Byte Format)) 0360160625: H1-RX: (1) 01 20 00 03 93 (Read Internal Status Flags (5 Byte Format): content ignored) 0360160656: H1-TX: (1) 00 00 00 03 10 (Status Update, VFOA and VFOB) 0360160765: H1-RX: (1) 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 (Status Update, VFOA and VFOB: content ignored) 0360161609: H1-TX: (1) 00 00 00 00 FA (Read Internal Status Flags (5 Byte Format)) 0360161640: H1-RX: (1) C1 20 00 03 93 (Read Internal Status Flags (5 Byte Format): content ignored) 0360161656: H1-TX: (1) 00 00 00 00 FA (Read Internal Status Flags (5 Byte Format)) 0360161687: H1-RX: (1) C9 20 00 03 93 (Read Internal Status Flags (5 Byte Format): content ignored) 0360161703: H1-TX: (1) 00 00 00 03 10 (Status Update, VFOA and VFOB) 0360161796: H1-RX: (1) 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 1B 02 AD 66 80 00 00 01 00 00 11 33 44 11 11 00 (Status Update, VFOA and VFOB: content ignored) 0360161828: sending
Re: [wsjt-devel] Possible WSJT-X 2.5.2 Bug(s)
I'm able to reproduce this behavior. Minimum window size is not restored. More than default window size is restore. Mike W9MDB On Friday, November 12, 2021, 10:08:56 AM CST, Saku wrote: 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
[wsjt-devel] VFOs reversing
This is on an Elecraft K4.When transmitting in split mode VFOA=Rx and VFOB=Tx
and one changes the Tx frequency WSJT-X assumes since VFOB is the current VFO
that it reverses roles and sets VFOA frequency instead.If VFOB is active and
split and ptt=on then VFOB is still tx. I really don't know if this applies to
all rigs though.
Mike W9MDB
[2021-11-12 17:33:03.956038][00:00:19.736380][RIGCTRL:trace] #:
Transceiver::TransceiverState(online: yes Frequency {24915000Hz, 24913500Hz}
Mode: DIG_U; SPLIT: on; PTT: on)[2021-11-12
17:33:03.956038][00:00:19.736395][RIGCTRL:trace] txf: 24913500 reversed:
true[2021-11-12 17:33:03.956038][00:00:19.736410][RIGCTRL:debug]
rig.c(2866):rig_get_vfo entered[2021-11-12
17:33:03.956038][00:00:19.736421][RIGCTRL:trace] rig_get_vfo: cache check
age=435ms[2021-11-12 17:33:03.956038][00:00:19.736429][RIGCTRL:trace]
rig_get_vfo: cache hit age=435ms[2021-11-12
17:33:03.956038][00:00:19.736441][RIGCTRL:trace] rig_get_vfo:
elapsed=0ms[2021-11-12 17:33:03.956038][00:00:19.736448][RIGCTRL:debug]
rig.c(2897):rig_get_vfo return(0)[2021-11-12
17:33:03.956038][00:00:19.736452][RIGCTRL:trace] rig_get_vfo
VFO=VFOB[2021-11-12 17:33:03.956038][00:00:19.736455][RIGCTRL:trace] reversing
VFOs[2021-11-12 17:33:03.956038][00:00:19.736458][RIGCTRL:trace] RX VFO=VFOB TX
VFO=VFOA[2021-11-12 17:33:03.956038][00:00:19.736460][RIGCTRL:trace]
rig_set_split_freq_mode freq=24913500 mode = PKTUSB[2021-11-12
17:33:03.956038][00:00:19.736467][RIGCTRL:debug]
rig.c(4522):rig_set_split_freq_mode entered[2021-11-12
17:33:03.956038][00:00:19.736474][RIGCTRL:trace] vfo_fixup:(from
rig_set_split_freq_mode:4544) vfo=TX, vfo_curr=VFOB, split=1[2021-11-12
17:33:03.956038][00:00:19.736480][RIGCTRL:trace] vfo_fixup: RIG_VFO_TX changed
to VFOA, split=1, satmode=0[2021-11-12
17:33:03.956038][00:00:19.736490][RIGCTRL:debug] rig_set_split_freq_mode:
vfo=VFOA, tx_freq=24913500, tx_mode=PKTUSB, tx_width=-1[2021-11-12
17:33:03.956038][00:00:19.736495][RIGCTRL:trace] ../../src/src/rig.c(4590)
trace[2021-11-12 17:33:03.956038][00:00:19.736501][RIGCTRL:debug]
rig_set_split_freq called vfo=VFOA, curr_vfo=VFOB[2021-11-12
17:33:03.956038][00:00:19.736507][RIGCTRL:debug] rig_get_freq(2098) called
vfo=VFOA[2021-11-12 17:33:03.956038][00:00:19.736522][RIGCTRL:trace]
vfo_fixup:(from rig_get_freq:2104) vfo=VFOA, vfo_curr=VFOB, split=1[2021-11-12
17:33:03.956038][00:00:19.736529][RIGCTRL:debug] ../../src/src/rig.c(2107)
vfo=VFOA, curr_vfo=VFOB[2021-11-12
17:33:03.956038][00:00:19.736553][RIGCTRL:trace] rig_get_freq: VFOA cache hit
age=432ms, freq=24915000[2021-11-12
17:33:03.956038][00:00:19.736559][RIGCTRL:trace] rig_get_freq:
elapsed=0ms[2021-11-12 17:33:03.956038][00:00:19.736565][RIGCTRL:debug]
rig.c(2169):rig_get_freq return(0)[2021-11-12
17:33:03.956038][00:00:19.736571][RIGCTRL:trace] vfo_fixup:(from
rig_set_split_freq:3970) vfo=VFOA, vfo_curr=VFOB, split=1[2021-11-12
17:33:03.956038][00:00:19.736576][RIGCTRL:trace] ../../src/src/rig.c(3983)
trace[2021-11-12 17:33:03.956038][00:00:19.736582][RIGCTRL:debug] rig_set_freq
called vfo=VFOA, freq=24913500[2021-11-12
17:33:03.956038][00:00:19.736590][RIGCTRL:trace] vfo_fixup:(from
rig_set_freq:1907) vfo=VFOA, vfo_curr=VFOB, split=1[2021-11-12
17:33:03.956038][00:00:19.736595][RIGCTRL:trace] rig_set_freq: TARGETABLE_FREQ
vfo=VFOA[2021-11-12 17:33:03.956038][00:00:19.736600][RIGCTRL:trace]
../../src/src/rig.c(1934) trace[2021-11-12
17:33:03.956038][00:00:19.736608][RIGCTRL:debug] kenwood_set_freq called
vfo=VFOA freq=24913500[2021-11-12
17:33:03.956038][00:00:19.736614][RIGCTRL:trace] kenwood_set_freq:
tvfo=VFOA[2021-11-12 17:33:03.956038][00:00:19.736620][RIGCTRL:debug]
rig_get_freq(2098) called vfo=VFOA[2021-11-12
17:33:03.956038][00:00:19.736632][RIGCTRL:trace] vfo_fixup:(from
rig_get_freq:2104) vfo=VFOA, vfo_curr=VFOB, split=1[2021-11-12
17:33:03.956038][00:00:19.736639][RIGCTRL:debug] ../../src/src/rig.c(2107)
vfo=VFOA, curr_vfo=VFOB[2021-11-12
17:33:03.957035][00:00:19.736664][RIGCTRL:trace] rig_get_freq: VFOA cache hit
age=432ms, freq=24915000[2021-11-12
17:33:03.957035][00:00:19.736671][RIGCTRL:trace] rig_get_freq:
elapsed=1ms[2021-11-12 17:33:03.957035][00:00:19.736677][RIGCTRL:debug]
rig.c(2169):rig_get_freq return(0)[2021-11-12
17:33:03.957035][00:00:19.736685][RIGCTRL:debug] kenwood_transaction
called[2021-11-12 17:33:03.957035][00:00:19.736690][RIGCTRL:trace]
kenwood_transaction: cache invalidated[2021-11-12
17:33:03.957035][00:00:19.736695][RIGCTRL:trace] kenwood_transaction: cmdstr =
FA00024913500[2021-11-12 17:33:03.957035][00:00:19.736700][RIGCTRL:trace]
rig_flush: called for network device[2021-11-12
17:33:03.957035][00:00:19.736705][RIGCTRL:debug] network_flush
called[2021-11-12 17:33:03.957035][00:00:19.736741][RIGCTRL:trace]
write_block(): TX 14 bytes[2021-11-12
17:33:03.957035][00:00:19.736755][RIGCTRL:trace] 46 41 30 30 30 32 34
39 31 33 35 30 30 3b FA00024913500;
Re: [wsjt-devel] Possible WSJT-X 2.5.2 Bug(s)
Try the latest hamlib and see if that fixes the problem.
New hamlib for Windows installation directions#1 Shut down WSJTX#2 Download
either the 32-bit or 64-bit DLL -- 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.dllhttp://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll#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
On Friday, November 12, 2021, 10:42:54 AM CST, Sam W2JDB
wrote:
Hi,
I don't know if this is a Hamlib problem or a WSJT-X problem.
I run a TS590S (Windows 10) and as you are aware I wrote my own logging/rig
control software.
When testing version 2.5.2 I noticed extraneous beeps from the TS590S
whenWSJT-X switches from RX to TX.
Using my software, I was able to determine that WSJT-X is sending extraneous
Split commands ("FT1;" and "FT0") as it switches from RX to TX.
The settings in WSJT-X is set to use CAT for PTT and SPLIT=RIG.There should be
no reason to send these extraneous commands once WSJT-X starts and sets the
TS590S into SPLIT.
If this process is a regression in the new version, then please disregard
thefollowing paragraph
If the process was used so as to ascertain/set which VFO is used for RX and/and
TX, it would have been much more efficient to use the "FR"/"FT" commands in
conjunction with the "FA"/"FB" commands as it would be a lot less wear and tear
on the relay in the rig.
73, Sam W2JDB
___
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)
Try a new config and see if that fixes the problem. wsjtx -r test Mike W9MDB On Friday, November 12, 2021, 01:14:04 AM CST, Saku via wsjt-devel wrote: 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: - 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. - 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 mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.5.2 & Funcube Pro+ Hamlib VFO Frequency Issue & Workaround
What rig entry are you using? Mike W9MDB On Saturday, November 6, 2021, 11:30:04 AM CDT, Chris via wsjt-devel wrote: Hi All, I’ve installed WSJT-X version 2.5.2 on my Win10 64-bit PC, working with a Funcube Pro+ receiver. I’ve used this receiver with previous versions of WSJT-X, up to and including 2.5.1 without any errors being shown. However, on running 2.5.2 whenever a frequency is selected on the main window drop-down list, or when the Monitor button is pressed from off to on, or if a change of decoder mode forces a frequency change, then a Rig Control error appears as: Hamlib error: Feature not available rig.c(2544):rig_get_mode return(0) rig_set_mode called, vfo=currVFO, mode=USB, width=-1 rig.c(2350):rig_set_mode return(-11) while setting current VFO mode Timestamp: 2021-11-06T12:07:36.463Z The workaround is merely two mouse clicks … press OK on the Rig Control error window then click on OK to exit the Settings window and this clears the error and everything works as normal until the user changes frequency (or the Mode changes the frequency) or the Monitor button is toggled off to on. The Rig Control status LED(?) on the main window always shows green. And the Test CAT button turns green on the SettingsàRadio tab, if pressed. Something has definitely changed regarding the Rig Control software in this 2.5.2 version as I had no issues in previous versions of 2.5.x If I can help you test the software with a Funcube Pro+ then please do not hesitate to contact me. 73 Chris (Shortwave Listener in UK) ___ 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] vfo errors
I assume that's not fatal though, correct? It should operate normally after startup. Mike W9MDB On Friday, November 5, 2021, 08:06:46 AM CDT, Al Flapan via wsjt-devel wrote: I am running vn2.5.2 on a W10 pro 64 bit PC with an ICOM IC7100 connected via the USB data cable. Attached is the syslog file showing the errors. ___ 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] Yaesu rig split problems
And what rig is this? VFOA moves just like VFOB does in split so shouldn't make any difference in F/H mode. Mike W9MDB On Thursday, November 4, 2021, 05:26:18 PM CDT, Marco Calistri via wsjt-devel wrote: Hello Mike, My answers inline. Il 04/11/21 09:35, Black Michael via wsjt-devel ha scritto: I'm trying to solve rig split operation problems with Yaesu rigs and need some Yaesu operator help... I need any Yaesu owners to state their rig model and whether or not "Rig split" works in WSJT-X or if you see flashing on the rig when Rig split is turned on. So 3 questions #1 Can you make QSOs? Yes #2 Does rig operation look smooth? Should be a little activity as freq & mode get set on both VFOs but it I'd like to know if the display goes a little nuts when it's happening with Rx/Tx flickering or such. Yes Mike W9MDB Additional notes: Split works well here but lately, in order to be able to work some of the latest DX Expeditions, I switched this option to "FAKE-IT" due the fact that otherwise, when I'm into F/H mode using "SPLIT" my VFO moves too much off from the FOX station frequency. As you probably may remind, I cannot use USB mode here if use hamlib net rigctl, just DIG-MODE in this case otherwise the TX audio mutes. --- 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] Yaesu rig split problems
And why USB and not Data mode? Might help others to know or is there a bug there? Mike W9MDB On Thursday, November 4, 2021, 09:57:31 AM CDT, da...@beauchesne.net wrote: I have a FTDX-5000 with WSJT-X 2.5.1 and use split with no difficulty. (And have had no difficulty running split all the way back to the first version of WSJT-X that supported FT8.) I do not use DATA modes – just plain USB filtering. David, AK2L From: Black Michael via wsjt-devel Sent: Thursday, November 4, 2021 05:36 To: WSJTX Group ; WSJT Software Development Cc: Black Michael Subject: [wsjt-devel] Yaesu rig split problems I'm trying to solve rig split operation problems with Yaesu rigs and need some Yaesu operator help... I need any Yaesu owners to state their rig model and whether or not "Rig split" works in WSJT-X or if you see flashing on the rig when Rig split is turned on. So 3 questions #1 Can you make QSOs? #2 Does rig operation look smooth? Should be a little activity as freq & mode get set on both VFOs but it I'd like to know if the display goes a little nuts when it's happening with Rx/Tx flickering or such. Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yaesu rig split problems
And what do you have for the Mode selection? Seems the problem is when that is Mode=USB or Mode=Data/Pkt Mike W9MDB On Thursday, November 4, 2021, 07:59:09 AM CDT, Peter Sichel wrote: I have FTdx10 and split operation works as expected locally (rx VFO-A and tx VFO-B). I learned from the developer of RUMLogNG that VFO-B isn’t readily available to logging software.The software can only track VFO-A regardless of which VFO is controlling the transceiver. Kind regards, - Peter, K1AV On Nov 4, 2021, at 8:35 AM, Black Michael via wsjt-devel wrote: I'm trying to solve rig split operation problems with Yaesu rigs and need some Yaesu operator help... I need any Yaesu owners to state their rig model and whether or not "Rig split" works in WSJT-X or if you see flashing on the rig when Rig split is turned on. So 3 questions#1 Can you make QSOs?#2 Does rig operation look smooth? Should be a little activity as freq & mode get set on both VFOs but it I'd like to know if the display goes a little nuts when it's happening with Rx/Tx flickering or such. Mike W9MDB ___ 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
[wsjt-devel] Yaesu rig split problems
I'm trying to solve rig split operation problems with Yaesu rigs and need some Yaesu operator help... I need any Yaesu owners to state their rig model and whether or not "Rig split" works in WSJT-X or if you see flashing on the rig when Rig split is turned on. So 3 questions#1 Can you make QSOs?#2 Does rig operation look smooth? Should be a little activity as freq & mode get set on both VFOs but it I'd like to know if the display goes a little nuts when it's happening with Rx/Tx flickering or such. Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Windows installers alerting for malware on VirusTotal
I just submitted wsjtx-2.5.1-win64.exe to virus total and got 1 hit on a generic (it shows 2 but lists 1).https://www.virustotal.com/gui/file/b2007bf26ede3e8f68866d817971645c3c6fb88c9a952ba7bc3982993ce453c8 None of the listed items that are inserted are on my system so it's definitely a false positive. Anti-virus vendors are false alarming on all sorts of things nowadays. All you have to do is submit it and they whitelist it pretty quickly. Not seen 1 piece of ham software yet that had a virus in it. JTAlert gets alerted on every release and gets whitelisted every release too. Mike W9MDB On Tuesday, October 26, 2021, 05:46:53 PM CDT, Joseph Botto via wsjt-devel wrote: Hello all, Over the last few releases of WSJT-X, the Windows installers available for download from the main WSJT-X site (https://physics.princeton.edu/pulsar/k1jt/wsjtx.html) have been alerting on VirusTotal for malware. This has been exhibited going back to at-least the 2.3.x branch. The VirusTotal scan results can be viewed directly by uploading one of the installers to VirusTotal, and either seeing the archived results, or re-running the scans. While the installers are only alerting for 3/64 scanner products (which indicates that they are likely false positives), I personally won't install anything downloaded from the internet that has even one alert. Would the WSJT-X developers be able to contact those alerting scanners to see why the installers are being flagged as containing malware? 73, -Joe BottoKM4SQShttp://km4sqs.blogspot.com/ https://github.com/km4sqs ___ 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] wsjtx vn 2.5.1 issue
Tomorrow replace the hamlib-4.dll in the WSJTX directory from the W32 or W64 zip file from herehttp://n0nb.users.sourceforge.net/ It will be dated 20211022 Tell us if it works OK. Mike W9MDB On Thursday, October 21, 2021, 08:14:49 PM CDT, Al Flapan via wsjt-devel wrote: I updated to this version from vn 2.5.0 and am back to seeing the hamlib error unknown vfo found. I did not get this with vn 2.5.0. I am attaching my syslog file. I am using an ICOM IC7100. Al AF4FA ___ 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] 2.5.1, KX-3, and Macs
Does the Mac version use static or shared libraries? If you open up a terminal -- cd to the wsjtx directory and do this rigctl - 2>&1 q| grep Hamlib What does it show?Should look like this: rigctl Hamlib 4.4~git Wed Oct 20 21:21:43 2021 + SHA=655337 Mike W9MDB On Thursday, October 21, 2021, 01:12:22 PM CDT, Virginia Greene via wsjt-devel wrote: I just tried 2.5.1. Although there was no mention in the release notes that the problem I’d reported earlier with regard to Elecraft KX3’s, MacOS, and split operation had been specifically fixed, I’d hoped that a new compilation using an updated HamLib version would fix the problem. It has not. This is both in DATA and USB modes. So, although there was absolutely truth in advertising with regard to 2.5.1, the problem still exists. And, 2.3.1 still works perfectly. Just reporting. 73, Clarke K1JX ___ 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] Fwd: Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
That has been fixed in the latest hamlib. You can download the appropriate 32-bit or 64-bit zip file from herehttp://n0nb.users.sourceforge.net/ Extract the libhamlib-4.dll and replace the one in the WSJTX directory. Mike W9MDB On Tuesday, October 19, 2021, 05:11:40 AM CDT, Barry Jackson via wsjt-devel wrote: There seems to be a regression in hamlib-4.3.x which I have been testing for our dev branch. I maintain the wsjtx package for Mageia (Linux) and do all my testing with my Kenwood TS-450S. We use the system hamlib. Fake-it works, but any attempt to use RIG for split now fails with the error in the attached image. I am using rigctld which works perfectly with hamlib-4.2. Looking at hamlib change logs it seems there were changes to split for Kenwood so I have my suspicions. Reading some other posts here I saw reference to adding --vfo to rigctld command so I did try it, however it makes no difference in this case. I did consider sending this to hamlib list but since Bill has a foot in both camps I decided that here was probably best ;) Thanks, Barry G4MKT ___ 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] Serial port Oddity
The only note we have in hamlib is the Linux sets RTS/DTR high on opening and
we set it low.
We obviously can't debug your code for you but it sounds like you have the
wrong port when you deassert RTS. You should be able to create a test which
just toggles ptt on/off every second or so to see if it's working. Double
check you have the correct port and that you have the correct control.
Here's the RTS code from hamlib.
#if defined(TIOCMBIS) && defined(TIOCMBIC) rc = IOCTL(p->fd, state ?
TIOCMBIS : TIOCMBIC, );
#else
rc = IOCTL(p->fd, TIOCMGET, );
if (rc >= 0)
{
if (state)
{
y |= TIOCM_RTS;
}
else
{
y &= ~TIOCM_RTS;
}
rc = IOCTL(p->fd, TIOCMSET, );
}
#endif
Mike W9MDB
Mike W9MDB
On Tuesday, October 19, 2021, 05:19:03 AM CDT, Simon W-W via wsjt-devel
wrote:
Hello,
I have been developing a universal radio interface that can do Cat control and
sound card etc.
I am using a Silicon systems CP210x type USB to serial chip along with CM108
for sound. Using an FE1.1s USB2 hub chip to distribute the USB.
I noted that if you have cat running on one serial port and using another to
key the PTT via RTS or DTR is where I note something odd.
When running the PTT test it will key the RTS and then never release it.
The pattern changes if you have PTT and RTS keying off the same chip. When it
is like that it works OK. It’s like the port is not being refreshed or unset
after asserting RTS when running in a split mode.
I had Com 18 as CAT and com 19 keying RTS for PTT. This way it never de
asserts. Running PTT via RTS (com18) while the cat is also running on com 18
for instance, things work OK. DTR is another mystery. It pulses quickly and
that’s it.
Sometimes in High RF environments, I like to have the PTT done by RTS / DTR so
tha the transceiver does not get stuck in TX if the cat commads get hung up for
some reason.
Normally I run TX via cat but noted this anomaly.
Have you seen this before?
Thanks,
Simon
ZL1SWW / ZL1EW.
___
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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
I updated the man page. This was changed to maintain combability with older versions. So the new way is the correct way. Mike W9MDB On Monday, October 18, 2021, 11:30:45 AM CDT, Saku via wsjt-devel wrote: 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Rig LF Rolloff
On more potential solution -- In fox mode run pseudo-split and drop the frequency 500Hz automaticallyi.e. Fake-It mode for both RX & TX. Mike W9MDB On Sunday, October 17, 2021, 09:11:52 AM CDT, Virginia Greene via wsjt-devel wrote: Bill, This actually kept me up last night! For “Normal” FT8 operation, your solution makes 100% perfect sense. The only downside I can see is that you lose that 200 Hz or 300 Hz at the top end of the band. That is a very fair trade-off. But, in DXpedition mode with a Fox and Hounds, it gets murkier. First, consider the Hound end. Let’s assume that the Hound knows that his/her radio rolls off at the low end and really should be offset by 200 Hz, so s/he shifts the VFO by 200 Hz. If the Fox is using the default TX frequency of 300 Hz, that fools the Hound’s system into believing that the Fox is now at 500 Hz, where the Hound’s receiver hears well. That all should work well. But, imagine that the Fox has five streams running. The lowest would appear at 500 Hz for the Hound, with subsequent ones beginning at 560 Hz, 620 Hz, 680 Hz, and 740 Hz. If the Hound does not get through in three tries or the Fox fades so that Hound doesn't receive a transmission from the Hound, won’t the Hound get moved to the “repechage” band to get another couple minutes of attempts to send the signal report? When the Fox is at 300 Hz and up, that repechage band is 300 Hz above the Fox TX frequencies, where the Fox can still hear callers. BUT, if the Fox is at 500 Hz TX or above, won’t the Hound get moved 300 Hz *below* the Fox TX frequencies? As in, perhaps, 0 Hz relative to the bottom of FT8 channel? In this case, the Fox would never be able to hear the Hound there. So, when a Hound offsets her/his frequency by 200 Hz to accommodate the receiver low frequency roll-off, s/he essentially eliminates use of the repechage band. That may be the price a Hound pays for not having a properly working FT8 radio. That and remembering to call above 1200 Hz. Now, think about when a Fox is using a radio where the receive passband rolls off below 400 or so Hz, as is all too often the case. Just look at the most popular radios used on DXpeditions. With a single transmit stream, the Hounds will move to 300 Hz to send their reports. Unless the Hound is at least as many dB stronger than the filter roll-off, the Hound might get lost in the noise when s/he responds. That leads to multiple decode cycles being used, tying up the Fox. The rate drops, not only due to the immediate need for multiple decode cycles that otherwise might not be necessary, but also because the Hound likely will start the same dance again to initiate a contact. That presumes that the Fox does not log the contact while the Hound is in the repechage zone. (My observation is that most Hounds just go off and call again. Why? Dunno. I also notice that very few repechage contacts get made for whatever reason.) I’ve observed the above many, many times. Even just yesterday. It seems to me that there’s a few solutions for this. One is that all Hounds should be armed for bear with large antennas and big power. That way, they’ll overcome the Fox’s receiver filter roll-off. Of course, that precludes weaker signal contacts for tough propagation paths where the Hound only merits a -18 signal report from the Fox to begin with. Plus, it’s kind of against the spirit of FT8 being a weak signal mode usable by stations with more moderate power. A second would be for Foxes to all use radios that receive well to below 300 Hz. Problem solved for the Fox end, which really affects all the Hounds calling, too. That still puts the burden on all the Hounds to have receivers that are flat to below 300 Hz or shift their VFO by 200 Hz and sacrifice the ability to use the repechage band . Maybe that’s just tough on the Hounds who don’t know enough to do that. A third solution is for the Fox to move his or her TX frequency to 700 Hz. With five streams, the topmost one would begin at 940 Hz - still good. Essentially every Hound would have no problem, even if their receiver rolled off below 400 Hz. Any Hound that gets moved to the repechage band would get placed 300 Hz below the Fox TX frequency, which means they’d start at 400 Hz - pretty much within almost all Fox receivers, even with low frequency roll-off. (Isn’t that how it works?) The problem with all of these is that it requires cooperation from everybody to make it work. People would need to read the manual and know where their receiver rolls off. That’s easy enough to discover, but how many FT8 users actually do? Then, they’d need to adjust, repair, or replace their radio to have no meaningful low frequency receiver roll-off. My own solution, if I was king of the WSJT universe, would be to make the default FT8 Fox TX frequency 700 Hz. Almost every Fox just uses the default frequency. Why should they know any different?
Re: [wsjt-devel] Wsjtx crash
Probably in the same directory as the wsjtx executable. Mike W9MDB On Saturday, October 16, 2021, 11:37:36 PM CDT, jarmo via wsjt-devel wrote: Started to play with ref.spec, started measure, never got stop measuring, or didn't find stop measuring button. Wsjtx 2.5.0 self compiled, Fedora 34, latest hamlib 4.4 git version. Now try start wsjtx, it starts for few seconds and then crash, get message, if I translate it right from Fin to Eng "memory overflow" (created core-file). Where this core-file is created, can't find it? Jarmo ___ 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] Grid Location info does not attach on outgoing messages.
If you do File/Open log directory you should see the folder.It's the "WSJT-X.ini" file that contains everything. Mike W9MDB On Saturday, October 16, 2021, 10:37:27 PM CDT, William Spencer via wsjt-devel wrote: On all modes my grid locator info does not appear in the message lines. I have checked the settings and the info is in the correct box. This used to work for a long time, but I clicked the wrong box and now it doesn’t happen. I clicked on a command that said ‘reset’ thinking it would just reset com with the radio, but it seemed more like a ‘reset to default’ action as all my settings were gone. After reentering all the settings, all works except this. I decided today that since I was on ver. 2.3 and ver. 2.5 is out that I would just uninstall 2.3 and install 2.5. Apparently, some lib file must not have gotten uninstalled as when I opened 2.5 all my settings were there as well as the problem! The hardware is a P400 and I’m not sure what the OS is, but I think it is Buster. My question for the group is that if anyone knows what folder the settings data is in and is it easily editable? If not, how can I be assured I have gotten all the old folders and data deleted before I start another clean install? 73, Bill KY4O Sent from Mail for Windows ___ 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] Exaggerated reports given to lower tone freqs
I can see the opposite possibility in this data. Looks like below 300 the levels are low, high from about 300-400, then pretty consistent Red line here is 50-point moving average of 5000 points. Above 2200 we're getting into the region where bandpass limits might have an effect of some sort (lack of noise or perhaps more likely to have higher power transmitters?). Mike W9MDB On Friday, October 15, 2021, 11:45:16 PM CDT, Rich - K1HTV via wsjt-devel wrote: Has anyone experienced exaggerated dB signal reports givenby WSJT-X to decoded FT8 signals of stations transmitting tone frequenciesbelow 500 Hz? I use a K3 with 2.8 KHz filter using WSJT-X Version 2.5.0 . Ihave also seen this in earlier versions. When stations using low audio tones are decoded, the signal levelsthat WSJT-X gives them far exceeds the levels given to signals with higherfrequency tones of equal intensity level observed visually on the wide graph. I have run the “Measure Reference Spectrum” tool on a quietfrequency and have the “Ref Spec” checkbox on the Wide Graph checked. This didn’tresolve the noted anomaly. I first observed this on Foxes running 3 or 4streams using tones below 500 Hz with the lower tones appearing a few DB stronger than the higher tones. Any idea as to why this may be happening. 73, Rich – K1HTV ___ 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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
Got it...thanks Bill. Mike W9MDB On Friday, October 15, 2021, 01:13:21 PM CDT, Bill Somerville via wsjt-devel wrote: On 15/10/2021 19:05, Barry Jackson via wsjt-devel wrote: On 15/10/2021 18:37, Black Michael via wsjt-devel wrote: What's the title of that manual? I'd hope it would be available on-line. Do you have a scanner on your printer? Also...are you able to checkout the master repo and test the fix I just posted? Mike W9MDB It's called: "TS-450S TS-690S External Control Instruction Manual" 20 pages of command tables, lists, error messages etc. Yes I do have a scanner, should not take too long to scan them and put them in a tarball for you. It may be tomorrow though. Likewise with the test, it's evening here now. Cheers, Barry G4MKT Hi Barry, I have already sent Mike a copy of that document. 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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
What's the title of that manual? I'd hope it would be available on-line. Do you have a scanner on your printer? Also...are you able to checkout the master repo and test the fix I just posted? Mike W9MDB On Friday, October 15, 2021, 12:29:17 PM CDT, Barry Jackson via wsjt-devel wrote: On 15/10/2021 17:46, Black Michael via wsjt-devel wrote: > I'll have a fix for this shortlyI put in a split check for Elecraft > rigs and that is doing the "FT" query which isn't supported as Bill notes. > > Bill...do you know of a CAT manual for the TS590/690? I can't seem to > find one. > > Mike W9MDB > I do have the paper one. Maybe the bits you need are not too big? Barry G4MKT ___ 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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
I turned it into a generic "don't set unless necessary". Was causing power problems on the K4 too.Hopefully it's fixed now and applies to all rigs that can get split status and trying to set split on again. Split off will always run a command. Mike W9MDB On Friday, October 15, 2021, 11:23:49 AM CDT, Bill Somerville via wsjt-devel wrote: On 15/10/2021 16:57, Barry Jackson via wsjt-devel wrote: On 15/10/2021 16:18, Black Michael wrote: Since you're not getting any answer with hardware flow it sounds like you have a 3-wire RS232 cable. So how are your cable pinouts connected? Try this rigctld -v -Z -v -m 2003 -s 4800 -r /dev/ttyUSB0 -t 4532 --serial_handshake=None --write_delay=5 I tried as above but got: rigctld: unrecognized option '--serial_handshake=None So I did: rigctld -v -Z -v -m 2003 -s 4800 -r /dev/ttyUSB0 -t 4532 -C serial_handshake=None,write_delay=5 Output attached which is an improvement. I then started wsjtx and results were not good, band switching failed rather randomly - again attached. Cheers, Barry G4MKT Hi Barry and Mike, the problem there seems pretty straightforward, Hamlib is attempting an FT; query and the TS-450S/TS-690S only have the set version of that command, no query version. 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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
My boo-boo...meant TS-450.I have several TS-590 cat manuals. Mike On Friday, October 15, 2021, 12:11:04 PM CDT, Reino Talarmo wrote: Mike, Could it be this https://www.kenwood.com/i/products/info/amateur/pdf/ts_590_g_pc_command_e.pdf ? 73, Reino OH3mA From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] Sent: 15. lokakuutata 2021 19:47 To: wsjt-devel@lists.sourceforge.net Cc: Black Michael Subject: Re: [wsjt-devel] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine) I'll have a fix for this shortlyI put in a split check for Elecraft rigs and that is doing the "FT" query which isn't supported as Bill notes. Bill...do you know of a CAT manual for the TS590/690? I can't seem to find one. Mike W9MDB On Friday, October 15, 2021, 11:30:50 AM CDT, Bill Somerville via wsjt-devel wrote: On 15/10/2021 17:21, Barry Jackson via wsjt-devel wrote: On 15/10/2021 15:57, Bill Somerville via wsjt-devel wrote: the TS-450S and TS-690S use RTS/CTS hardware handshake flow control. I have never see a rig with a serial CAT interface that uses XON/XOFF flow control, RTS/CTS is ubiquitous on Kenwood rigs with the exception of some handhelds that only have a 3-wire CAT serial connection, and more recent rigs that have a menu option to disable the default RTS/CTS hardware handshake flow control. Your interface may loop RTS and CTS at the rig end, that will provide a default RTS signal and will work with no flow control settings at the PC end. Yes it does only have 3 wires in the DIN plug to the rig from the dongle, I had never opened it previously. It has worked with handshake=None in wsjtx in the past, but XONXOFF always worked with all digital radio software, so I had always left it at that setting. It always needed the one stop bit, not two, contrary to the manual. Bring back parallel ports! :) Cheers, Barry G4MKT Barry, your interface probably loops RTS and CTS. XON/XOFF is passive until there is a looming buffer overrun, so selecting that option when there is actually no need for it usually works. Almost certainly your correct setting is no flow control, which is fine given your probable interface wiring. Note this is why WSJT-X has the option to change the flow control since it is not quite as Mike states "the defaults are always correct". 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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
I'll have a fix for this shortlyI put in a split check for Elecraft rigs and that is doing the "FT" query which isn't supported as Bill notes. Bill...do you know of a CAT manual for the TS590/690? I can't seem to find one. Mike W9MDB On Friday, October 15, 2021, 11:30:50 AM CDT, Bill Somerville via wsjt-devel wrote: On 15/10/2021 17:21, Barry Jackson via wsjt-devel wrote: On 15/10/2021 15:57, Bill Somerville via wsjt-devel wrote: the TS-450S and TS-690S use RTS/CTS hardware handshake flow control. I have never see a rig with a serial CAT interface that uses XON/XOFF flow control, RTS/CTS is ubiquitous on Kenwood rigs with the exception of some handhelds that only have a 3-wire CAT serial connection, and more recent rigs that have a menu option to disable the default RTS/CTS hardware handshake flow control. Your interface may loop RTS and CTS at the rig end, that will provide a default RTS signal and will work with no flow control settings at the PC end. Yes it does only have 3 wires in the DIN plug to the rig from the dongle, I had never opened it previously. It has worked with handshake=None in wsjtx in the past, but XONXOFF always worked with all digital radio software, so I had always left it at that setting. It always needed the one stop bit, not two, contrary to the manual. Bring back parallel ports! :) Cheers, Barry G4MKT Barry, your interface probably loops RTS and CTS. XON/XOFF is passive until there is a looming buffer overrun, so selecting that option when there is actually no need for it usually works. Almost certainly your correct setting is no flow control, which is fine given your probable interface wiring. Note this is why WSJT-X has the option to change the flow control since it is not quite as Mike states "the defaults are always correct". 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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
Actually a few rigs with xon/xoff including the old Kenwood THD74 according to our defaults. .serial_handshake = RIG_HANDSHAKE_XONXOFF,./kenwood/thd74.c .serial_handshake = RIG_HANDSHAKE_XONXOFF,./aor/ar8200.c .serial_handshake = RIG_HANDSHAKE_XONXOFF,./aor/sr2200.c .serial_handshake = RIG_HANDSHAKE_XONXOFF, .serial_handshake = RIG_HANDSHAKE_XONXOFF, ./aor/ar5000.c .serial_handshake = RIG_HANDSHAKE_XONXOFF,./aor/ar8600.c .serial_handshake = RIG_HANDSHAKE_XONXOFF,./aor/ar8000.c .serial_handshake = RIG_HANDSHAKE_XONXOFF,./aor/ar2700.c .serial_handshake = RIG_HANDSHAKE_XONXOFF,./barrett/barrett.c .serial_handshake = RIG_HANDSHAKE_XONXOFF,./barrett/950.c .serial_handshake = RIG_HANDSHAKE_XONXOFF,./racal/ra3702.c Mike W9MDB On Friday, October 15, 2021, 10:03:06 AM CDT, Bill Somerville via wsjt-devel wrote: On 15/10/2021 15:49, Barry Jackson via wsjt-devel wrote: On 15/10/2021 15:02, Black Michael wrote: I noticed you have serial_handshake=XONXOFF and stopbits=1 Just let those two items default to stopbits=2 and serial_handshake=Hardware which what I show is the setup for the TS-450. And you should be able to just check all the Default labels in WJST-X's rig control tab too (which, by the way, should work for all rigs) Mike W9MDB I was waiting for you to comment on that. The defaults have never worked at all for me with any versions of hamlib. I know that is what the Kenwood manual says but it does not work. Only the settings as I have them provoke any sort of response from the rig. I did contact you about 'correcting' the defaults in hamlib but you dismissed this at the time by blaming my USB interface: Bus 002 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge So I forgot about it and just continued to add the parameters that it works perfectly with. In fact I did try dropping all the -C options last night to see if anything had changed and there was no response at all. Tested again with 4.2 and my parameters missing. Log attached. Cheers, Barry G4MKT Barry, the TS-450S and TS-690S use RTS/CTS hardware handshake flow control. I have never see a rig with a serial CAT interface that uses XON/XOFF flow control, RTS/CTS is ubiquitous on Kenwood rigs with the exception of some handhelds that only have a 3-wire CAT serial connection, and more recent rigs that have a menu option to disable the default RTS/CTS hardware handshake flow control. Your interface may loop RTS and CTS at the rig end, that will provide a default RTS signal and will work with no flow control settings at the PC end. 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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
Since you're not getting any answer with hardware flow it sounds like you have a 3-wire RS232 cable. So how are your cable pinouts connected? Try this rigctld -v -Z -v -m 2003 -s 4800 -r /dev/ttyUSB0 -t 4532 --serial_handshake=None --write_delay=5 See if that write_delay helps in your situation. Mike W9MDB On Friday, October 15, 2021, 10:06:54 AM CDT, Barry Jackson wrote: On 15/10/2021 15:43, Black Michael wrote: > Now please test 4.4 without the stopbits and serial_handshake options (let > rigctld use the defaults). > The difference is the commands are now being stacked and it's possible the > lack of hardware flow control is causing this problem.Just let those two > options default please and try again. > If it still fails with stopbits=2 and serial_handshake=Hardware then I may > need to unstack the commands. > Mike > > Attached. ...or did you want me to specify data_bits, but not stop and handshake? As I recall all three are in the defaults? Cheers, Barry G4MKT ___ 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)
I noticed you have serial_handshake=XONXOFF and stopbits=1 Just let those two items default to stopbits=2 and serial_handshake=Hardware which what I show is the setup for the TS-450. And you should be able to just check all the Default labels in WJST-X's rig control tab too (which, by the way, should work for all rigs) Mike W9MDB On Friday, October 15, 2021, 05:45:01 AM CDT, Barry Jackson via wsjt-devel wrote: On 15/10/2021 00:03, Barry Jackson via wsjt-devel wrote: > > I'm guessing that hamlib logs would be more than useful but I have yet > find any, or where to enable. > > So, any ideas? > > Cheers, > Barry > G4MKT Hi Mike, After sleeping on this I ran rigctld manually (rather than via systemd) and have some output attached. This is from starting wsjtx, attempting to TUNE and then change band where it changed at the rig but only in wsjtx dialogue after about 10 seconds whereupon it stopped with the usual error message. I hope this helps. Barry G4MKT ___ 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
You can set up a crontab entry to do whatever you want...call a shell script to delete it or rename it. Mike W9MDB On Thursday, October 14, 2021, 05:06:52 PM CDT, Marco Calistri via wsjt-devel wrote: Hello, I red some articles regarding how to prevent WSJT-X to produce its larges ".WAV" samples files, but I've not been able to disable this feature and periodically some of this audio files are going to be saved in my folder. Question 1: how to disable definitely this occurrence? 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? Note: I'm using Linux version of WSJT-X. Many thanks! --- 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] Split-RIG broken with hamlib-4.3.1 with TS-450S (4.2 is fine)
That should be fixed in the master branch now.Can you please try that? Mike W9MDB On Thursday, October 14, 2021, 02:36:33 PM CDT, Barry Jackson via wsjt-devel wrote: There seems to be a regression in hamlib-4.3.x which I have been testing for our dev branch. I maintain the wsjtx package for Mageia (Linux) and do all my testing with my Kenwood TS-450S. We use the system hamlib. Fake-it works, but any attempt to use RIG for split now fails with the error in the attached image. I am using rigctld which works perfectly with hamlib-4.2. Looking at hamlib change logs it seems there were changes to split for Kenwood. Reading some other posts here I saw reference to adding --vfo to rigctld command so I did try it, however it makes no difference in this case. I did consider sending this to hamlib list but since Bill has a foot in both camps I decided that here was probably best Thanks, Barry G4MKT___ 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
[wsjt-devel] New JTSDK close to release
Steve Ireland VK3VM/VK3SIR has been busy improving JTSDK to compile multiple programs: Hamlib -- static or dllWSJT-XJTDXJS8Call And others are being planned. Here's the new site https://hamlib-sdk.sourceforge.io/ Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Windows 11 - All good?
What do you hate about the task bar? On Monday, October 4, 2021, 04:27:59 PM CDT, Randall Hansen via wsjt-devel wrote: I installed Win 11 with no problems except some adjusting of Codec levels. PS I hate what they did to the taskbar On Mon, Oct 4, 2021 at 3:54 PM August Treubig via wsjt-devel wrote: So you have a brand new PC or Laptop that is Windows 11 certified? If you don’t know the answer, then you machine most likely will not run Windows 11. Micro$oft is playing games to make money. Aug AG5AT Sent from my iPad > On Oct 4, 2021, at 2:52 PM, halsteaw--- via wsjt-devel > wrote: > > Windows 11 starts its rollout tomorrow, and I was wondering if anyone > was in the Windows Dev/Beta channel, and had tested WSJT-X on it? > > ~Warren > KN6HXP > > > ___ > 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 ___ 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] Some minor issues.
According to hamspots.net and pskreporter you are being seen. Mike W9MDB On Thursday, September 30, 2021, 10:39:29 AM CDT, Marco Calistri via wsjt-devel wrote: Il 30/09/21 10:58, Bill Somerville via wsjt-devel ha scritto: On 30/09/2021 14:36, Marco Calistri via wsjt-devel wrote: CQRLOG now has been compiled with the chkvfo feature, settings adjusted as suggested but again no AFSK going to radio rear data connector if I select mode USB in WSJT-X, in order to transmit an FT8 signal I need to select DIG mode. Then, the only possible solution IMHO should be that Hamlib being modified accordingly in order to permits AFSK being usable for rear data connector in SSB too and not just in DIG mode. Marco, DIG mode is the correct rig mode setting for AFSK digimodes when using the FT-100. There is no facility to select the Tx audio source other than the rig mode settings with the FT-100. 73 Bill G4WJS. Hey Bill! I've not doubts about what you say, but unluckily, due some reasons I'm not aware of, if I select Mode Data/Pkt in WSJT-X, it looks like nobody station being able to listen and consequently to answer to my calls. Probably when I set Data/Pkt my radio transmit on a little shifted frequency out of the center of the standard transmission FT8 frequency and this unallow my signal to be heard. --- 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] Some minor issues.
CAT can be related to audio -- front/back connectors matter for example. Mike W9MDB On Wednesday, September 29, 2021, 11:27:09 AM CDT, Claude Frantz via wsjt-devel wrote: On 9/29/21 5:58 PM, jarmo via wsjt-devel wrote: Hi Marco, Jarmo and all, > Unfortunately not working. Compiled > hamlib-4.4~git-dd1376be-20210929.tar.gz and same behaviour. > If try to use NetHamlib rictl, audio does not go into radio. CAT is not related to Audio. > Cat control works ok. This is fine. hamlib does the job. > But if chosen Kenwood ts-590SG in WSJTX radio preferences, audio works > ok... Please debug the audio matter. My suggestion, at first: aplay -l aplay -L arecord -l arecord -L pactl list Please examine the output. As mentioned previously, if the "sound card" is connected via USB, verify that gpsd (or another program) doesn't grasp the "sound card". The output of dmesg can help. Best wishes, Claude (DJ0OT) ___ 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
