Re: [wsjt-devel] Hamlib testing
Will do it Mike, I will do it when radio is still cold, in order to avoid to have the thermal drift as a possible cause, since I think the reason is another. Regards, --- *73 de Marco, PY1ZRJ (former IK5BCU)* ** Il 12/06/23 17:27, Black Michael ha scritto: 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 For MacOS put it in /Users/[username]/Library/Preferences Restart WSJT-X and duplicate the problem. Shut down WSJT-X Then send me the WSJT-X_RigControl.log file Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Black Michael wrote: > Need people to test the latest Hamlib please it works fine for me with an FT-991 on Debian 12 -- 73 de IU5HKX Daniele ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
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 For MacOS put it in /Users/[username]/Library/Preferences Restart WSJT-X and duplicate the problem. Shut down WSJT-X Then send me the WSJT-X_RigControl.log file Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Tested new version compiled from git repository and on my old YAESU FT-100 I see same behavior I saw with previous Hamlib versions. I use WSJT-X 2.7.0 RC1 with settings Split=RIG and Mode= Data Packet and at the very beginning of the operation, the VFO A (Transmitter) and VFO B (Receiver) behave in this way: I make the first CQ, VFO A transmit 1 KHz below, so VFO B then moves 1 KHz below its original frequency, at second CQ VFO B is then 2 KHz below the starting frequency. I have to correct manually this behavior by clicking again on the band frequency I was using and have to do it two or three times, until the radio finally stabilize and then the shift keeps constant among VFO A and B of the value which depends by the TX audio I selected, I.E. if I use 777 Hz, the SPLIT shift between VFO's is 1 KHz and it remains stable. This is not a major issue for me but I would like to report it here. Best regards, --- *73 de Marco, PY1ZRJ (former IK5BCU)* ** Il 11/06/23 00:18, Black Michael via wsjt-devel ha scritto: Need people to test the latest Hamlib please https://n0nb.users.sourceforge.net/ #1 Backwards compatibility with WSJT-X has been fixed. #2 Notable speedups for Windows operations Here's an FT-991 comparison Old: 1:rig_get_freq: elapsed=16ms 1:rig_get_freq: elapsed=17ms 1:rig_get_split_vfo: elapsed=30ms 1:rig_get_mode: elapsed=47ms 1:rig_get_ptt: elapsed=17ms New: 1:rig_get_freq: elapsed=6ms 1:rig_get_freq: elapsed=6ms 1:rig_get_split_vfo: elapsed=14ms 1:rig_get_mode: elapsed=13ms 1:rig_get_ptt: elapsed=4ms 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 -Testing IC-7300/IC-705, IC-7610 Results
Both were connected to dummy loads, not antenna. I just repeated now with Multi- Control knob setting power to zero watts output on both the IC-7300 and the IC-705 radios with same results. Question for you, was I to use the WSJT-X v2.7.0-rc1 as originally released or was there another version of it that we should have installed? The testing I did was with the originally released candidate WSJT-X but with your updated libhamlib-4.dll installed per your email. Gene > On Jun 11, 2023, at 10:11 AM, Black Michael via wsjt-devel > wrote: > > Sounds like RFI Problems due to noise on the USB cable > > > Tests > If problems are occurring only during transmit: > #1 Reduce power to zero and see if the problem stops -- if it does stop > than it is definitely RFI. You will see certain higher power levels on > certain bands that cause problems. > Then, if problems are occurring during non-transmit periods it indicates a > system problem with USB devices so... > #1 Check USB Power Management option is turned off on all USB devices > Device Manager for Windows. > For Linux set autosuspend=-1 > https://docs.kernel.org/driver-api/usb/power-management.html > > > RFI Fixes: > #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. > Common grounding mistakes, sources, and solutions: > A. Ground rod outside the shack that is not bonded to the main house > ground. > B. Shack equipment bonded incorrectly (e.g. daisy chained instead of > common ground point) > C. Desktop computer grounded to the house ground and not the shack > ground. Run a separate RF ground from the computer chassis to your station > RF ground. >For a laptop use the retaining screw of a DB9 or DB25 connector > shell, if your device still has them. > D. Ethernet cables that bring RFI into the computer...which then ends > up going to the rig too since the ethernet shield is tied to the case which > is tied to USB shield which is tied to pin 4 on the USB cable (a very common > problem on most all USB devices -- see my QRZ page). >Ethernet patch cables up through CAT6 are UTP, which stands for > UNSHIELDED Twisted Pairs, four to be specific. There is NO separate shield > conductor in the jacket, nor a metallic shield around the RJ45 connector > itself. >Just use a ferrite toroid at each end. > E. Wall warts -- 24VAC supplies in sprinkler and alarm systems are > notorious for picking up RFI into your electrical system. >24 VAC transformers can be RF-bypassed using .005 ufd caps from > each output lead to safety ground. You can often use the cover plate mounting > screw as your ground connection. > F. Speaker wires The same approach as E also works for external > speaker audio leads. > G. Lamps (yes...lamps around the house have unshielded wires as do > many other appliances). > H. Washer/Dryers are notorious for generating and picking up RFI. In > general, newer high-efficiency models have more RF problems. >Ferrite toroids INSIDE the appliance housing can work wonders if > the wiring harness has connectors in the AC line input, OR an external noise > filter for the AC line cord of a washing machine can reduce RF spurs by 25 dB > or more. > I. HVAC systems with variable speed blower control systems both cause > RF noise and react badly to RF fields -- we believe adding torroids inside > the unit on the power lines will work. > J. If you use a powered USB expansion hub, add a ferrite toroid on > the cable coming from the USB power supply. > K. SignaLink -- You can ground the metal box shell by simply wrapping > an 18ga wire (or use a small crimped ring or spade terminal) under the head > of any of the screws holding the rear panel, then connect to your station RF > ground. >The case is isolated from both USB and analog audio signal > grounds, so this does not affect use of the USB shield isolators. > L. DC power supply -- both linear and switching -- READ THE PS MANUAL > FIRST! This step may void some manufacturers' warranty and UL/CSA approvals. >Remove any jumpers between the DC negative output lead and PS > chassis or line cord ground Add a .005 ufd cap from each DC output lead to > chassis ground if not already there. >NOTE: Samlex DC outputs are already isolated and bypassed, but > many others, including Astron, may randomly have the negative side grounded > and no RF bypassing. > B through L may all need chokes. > http://www.k9yc.com/GroundingAndAudio.pdf > #3 Free -- start unplugging devices around the house and see if there's > one device that is acting as a bad
Re: [wsjt-devel] Hamlib testing -Testing IC-7300/IC-705, IC-7610 Results
Sounds like RFI Problems due to noise on the USB cable Tests If problems are occurring only during transmit: #1 Reduce power to zero and see if the problem stops -- if it does stop than it is definitely RFI. You will see certain higher power levels on certain bands that cause problems. Then, if problems are occurring during non-transmit periods it indicates a system problem with USB devices so... #1 Check USB Power Management option is turned off on all USB devices Device Manager for Windows. For Linux set autosuspend=-1 https://docs.kernel.org/driver-api/usb/power-management.html RFI Fixes: #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. Common grounding mistakes, sources, and solutions: A. Ground rod outside the shack that is not bonded to the main house ground. B. Shack equipment bonded incorrectly (e.g. daisy chained instead of common ground point) C. Desktop computer grounded to the house ground and not the shack ground. Run a separate RF ground from the computer chassis to your station RF ground. For a laptop use the retaining screw of a DB9 or DB25 connector shell, if your device still has them. D. Ethernet cables that bring RFI into the computer...which then ends up going to the rig too since the ethernet shield is tied to the case which is tied to USB shield which is tied to pin 4 on the USB cable (a very common problem on most all USB devices -- see my QRZ page). Ethernet patch cables up through CAT6 are UTP, which stands for UNSHIELDED Twisted Pairs, four to be specific. There is NO separate shield conductor in the jacket, nor a metallic shield around the RJ45 connector itself. Just use a ferrite toroid at each end. E. Wall warts -- 24VAC supplies in sprinkler and alarm systems are notorious for picking up RFI into your electrical system. 24 VAC transformers can be RF-bypassed using .005 ufd caps from each output lead to safety ground. You can often use the cover plate mounting screw as your ground connection. F. Speaker wires The same approach as E also works for external speaker audio leads. G. Lamps (yes...lamps around the house have unshielded wires as do many other appliances). H. Washer/Dryers are notorious for generating and picking up RFI. In general, newer high-efficiency models have more RF problems. Ferrite toroids INSIDE the appliance housing can work wonders if the wiring harness has connectors in the AC line input, OR an external noise filter for the AC line cord of a washing machine can reduce RF spurs by 25 dB or more. I. HVAC systems with variable speed blower control systems both cause RF noise and react badly to RF fields -- we believe adding torroids inside the unit on the power lines will work. J. If you use a powered USB expansion hub, add a ferrite toroid on the cable coming from the USB power supply. K. SignaLink -- You can ground the metal box shell by simply wrapping an 18ga wire (or use a small crimped ring or spade terminal) under the head of any of the screws holding the rear panel, then connect to your station RF ground. The case is isolated from both USB and analog audio signal grounds, so this does not affect use of the USB shield isolators. L. DC power supply -- both linear and switching -- READ THE PS MANUAL FIRST! This step may void some manufacturers' warranty and UL/CSA approvals. Remove any jumpers between the DC negative output lead and PS chassis or line cord ground Add a .005 ufd cap from each DC output lead to chassis ground if not already there. NOTE: Samlex DC outputs are already isolated and bypassed, but many others, including Astron, may randomly have the negative side grounded and no RF bypassing. B through L may all need chokes. http://www.k9yc.com/GroundingAndAudio.pdf #3 Free -- start unplugging devices around the house and see if there's one device that is acting as a bad source of RFI. This presupposes you can easily repeat the problem on your rig setup. #4 Cheap -- Add some USB shield isolators (see my QRZ page). I use one on my SignaLink for example. #5 Minimal $$ -- Good USB cables like this https://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 #6 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 --
Re: [wsjt-devel] Hamlib testing -Testing IC-7300/IC-705, IC-7610 Results
*_Testing IC-7300/IC-705, IC-7610 Results_* Mike, on the IC-7610 so far the new *libhamlib-4.dll* seems to work. On the IC-705 and the IC-7300 however: The WSJT-X program /*crashes */if I start either radio from 7.074 MHz or higher and THEN change the band setting drop down to 80m e.g., 3.573 MHz or lower and do a TUNE transmit. It works OK at on 7.074 MHz and above frequencies but when I then drop to 3.573 MHz or the 1.840 MHz band and TUNE for Transmit it will crash and I have to then restart the program which then immediately crashes and a second restart operates correctly works unless I repeat the sequence I state above. I should note that in both radio test cases, they are being operated from different computers, in fact all radios have their own computers. I will be out most of the morning to church but back in the afternoon CDST. 73, Gene, K5PA On 6/10/2023 10:18 PM, Black Michael via wsjt-devel wrote: Need people to test the latest Hamlib please https://n0nb.users.sourceforge.net/ #1 Backwards compatibility with WSJT-X has been fixed. #2 Notable speedups for Windows operations Here's an FT-991 comparison Old: 1:rig_get_freq: elapsed=16ms 1:rig_get_freq: elapsed=17ms 1:rig_get_split_vfo: elapsed=30ms 1:rig_get_mode: elapsed=47ms 1:rig_get_ptt: elapsed=17ms New: 1:rig_get_freq: elapsed=6ms 1:rig_get_freq: elapsed=6ms 1:rig_get_split_vfo: elapsed=14ms 1:rig_get_mode: elapsed=13ms 1:rig_get_ptt: elapsed=4ms Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- -- Gene ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Hamlib testing
Need people to test the latest Hamlib please https://n0nb.users.sourceforge.net/ #1 Backwards compatibility with WSJT-X has been fixed. #2 Notable speedups for Windows operations Here's an FT-991 comparison Old: 1:rig_get_freq: elapsed=16ms 1:rig_get_freq: elapsed=17ms 1:rig_get_split_vfo: elapsed=30ms 1:rig_get_mode: elapsed=47ms 1:rig_get_ptt: elapsed=17ms New: 1:rig_get_freq: elapsed=6ms 1:rig_get_freq: elapsed=6ms 1:rig_get_split_vfo: elapsed=14ms 1:rig_get_mode: elapsed=13ms 1:rig_get_ptt: elapsed=4ms Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing #Hamlib
I am using a TS-2000X. Since I updated hamlib, I lost my transmit audio. When I click Tune, I get no power output. If I select None as Rig, I get power output. Sent from Mail for Windows From: Black Michael via wsjt-devel Sent: Thursday, July 7, 2022 9:54 AM To: WSJT Software Development; WSJTX Group Cc: Black Michael Subject: [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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing #Hamlib
Hello Mike, I have installed the latest 64 bit version here and tested using my Yaesu FTDX-101MP. No problems noted using WSJT-X v2.6.0-rc1 in both Fake It and Split. 73, Dennis NE6I -Original Message- From: Black Michael via wsjt-devel Sent: Thursday, July 7, 2022 6:51 AM To: WSJT Software Development ; WSJTX Group Cc: Black Michael Subject: [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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing #Hamlib
Thu, 7 Jul 2022 13:51:03 + (UTC) Black Michael via wsjt-devel kirjoitti: > 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. With TS-890S and TS-590SG with rigctld, up as a service, fake it works... Split as "rig" not tested, no need, when this works :) With FT-857, very quick test, rigctld no audio out... Radio chosen as FT-857 PTT as "vox" not working. PTT as "rts" works also with "fake it" OS, Fedora 36 wsjtx 2.5.4 As said this was very short test, and my time is now quite limited to test... Maybe someone test also FT-857 Jarmo, oh1mrr ___ 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] 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
No... It does not work. Pulled a few moments ago: [saku@hamtpad ~]$ rigctld --version rigctl Hamlib 4.5~git ma kesä 06 15:16:37 2022 + SHA=037384 Here you see what happens: "split - rig", "Allow frequency changes while transmitting" checked. Icom 7300 https://drive.google.com/file/d/1UnAzY5DiJAs53iko-xRWERWm0pk7Njw9/view?usp=sharing Starting with TX around 500 makes rig freq 50.311,5. Then moving TX to 2800 that moves WSJTX display to 50.314.0 but rig freq stays 50.311,5 After TX period ends WSJX shows 50.313.0 as should, but rig jumps now to 50.314.0 that it should have done when audio moved 500->2800 while TX, not now when RX period is started. This is worse now as before rig did move while transmitting, but return to RX went to wrong frequency. (1 bug) Now rig does not move while transmitting and return to RX goes still wrong. (2 bugs) -- Saku via wsjt-devel kirjoitti 4.6.2022 klo 9.17: Yep! I have it. I will make pull after weekend and see what that brings. Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 19.50: You can get the absolute latest with git clone git clone https://github.com/Hamlib/Hamlib.git Mike W9MDB -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Yep! I have it. I will make pull after weekend and see what that brings. Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 19.50: You can get the absolute latest with git clone git clone https://github.com/Hamlib/Hamlib.git Mike W9MDB -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
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
No can do... :-D Fedora 35, no Windozes in this house. Last tested version was: hamlib-4.5~git-a468f0de-20220603.tar.gz Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 16.39: In that case please use this DLL and send me the debug log as described below. https://www.dropbox.com/s/7aejdv74nfjxr0q/libhamlib-4.dll?dl=0 Please place this file as described below https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0 C:\Users\[username]\AppData\Local\WSJT-X The WSJT-X_Rigcontrol.log file will be in the same location For Linux put it in ~/.config The WSJT-X_Rigcontrol.log file will be here: ~/.local/share/WSJT-X Restart WSJT-X and duplicate the problem. Shut down WSJT-X Then send me the WSJT-X_RigControl.log file Mike W9MDB On Friday, June 3, 2022, 08:33:18 AM CDT, Saku via wsjt-devel wrote: Sorry but it does not work. It is even worse. Interesting side effect was that after installing new Hamlib ic7300 lost output power when rigctld was started from scirpt before wsjtx. Even rebooting pc did not restore power. When killed rigctld from script and set wsjtx to use icom7300 serial USB instead of Net Hamlib rigctld I got output power back. After that changed wsjtx back to Hamlib rigctld and started rigctld from script output power was normal. Perhaps resetting ic7300 would do the same (?) (I have feeling this has happened sometimes before and fixed in same way) But to the point. Now when moving TX Hz from waterfall from edge to another while transmit is ON the wsjtx frequency display changes but rig's display does not change. And when RX period starts rig stays on TX frequency that was at the beginning of TX period, not the one it was moved during TX. Before: Rig TX frequency changed, but RX was at last TX frequency (at the end on TX period) Now: Rig TX frequency does not change, while wsjtx frequency display changes, and RX is at first TX frequency (at the start of TX period) Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 15.09: It has been fixed. http://n0nb.users.sourceforge.net/ <http://n0nb.users.sourceforge.net/> Mike W9MDB On Friday, June 3, 2022, 05:03:29 AM CDT, Kari Sillanmäki via wsjt-devel <mailto:wsjt-devel@lists.sourceforge.net> wrote: Hi Saku, Michael, Mike et al I can duplicate this behaviour reported by Saku on my 7300. I'm using the rigctld-wsjtx bundled with WSJT-X 2.5.4 source tarball on Ubuntu 18.04.6 LTS. This seems to be a defect in hamlib; RX-frequency should always stay put. 73's de Kari, oh2gqc On 3.6.2022 10.58, Saku via wsjt-devel wrote: Subject: Re: [wsjt-devel] Hamlib testing From: Saku via wsjt-devel <mailto:wsjt-devel@lists.sourceforge.net> Date: 3.6.2022 klo 10.58 To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> CC: Saku <mailto:oh...@sral.fi> Hi Michael ! Could you test with your IC-7300 this way: set "split rig" and check "Allow TX frequency changes while transmitting" in settings/general tab Set your TX around 300Hz by shift+left click on waterfall. Start TX period and while your TX is on move your TX around 2800Hz by shift+left click on waterfall. When TX period is over does your RX return to selected (from band selector) frequency? Mine does not, it gets the TX (vfoB) frequency that must then be corrected with band selector back to right RX frequency. This happens if I have settings/Radio configured as ICOM 7300, or if I have started rigctld with script before starting wsjtx and then using Hamlib Net rigctld/localhost:4532 in settings/Radio. Both ways same result. OS is Fedora 35 linux. -- Saku OH1KH 5p1kzx Michael via wsjt-devel kirjoitti 2.6.2022 klo 18.32: Hi Everyone I have tested new the Hamlib with WSJT-X and JTDX in RIG and Fake It. I tested it with IC-7300, IC-7000 and IC-706Mk2g - behaviour as expected and no problems so far. 73 de Michael 5p1kzx ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
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
Sorry but it does not work. It is even worse. Interesting side effect was that after installing new Hamlib ic7300 lost output power when rigctld was started from scirpt before wsjtx. Even rebooting pc did not restore power. When killed rigctld from script and set wsjtx to use icom7300 serial USB instead of Net Hamlib rigctld I got output power back. After that changed wsjtx back to Hamlib rigctld and started rigctld from script output power was normal. Perhaps resetting ic7300 would do the same (?) (I have feeling this has happened sometimes before and fixed in same way) But to the point. Now when moving TX Hz from waterfall from edge to another while transmit is ON the wsjtx frequency display changes but rig's display does not change. And when RX period starts rig stays on TX frequency that was at the beginning of TX period, not the one it was moved during TX. Before: Rig TX frequency changed, but RX was at last TX frequency (at the end on TX period) Now: Rig TX frequency does not change, while wsjtx frequency display changes, and RX is at first TX frequency (at the start of TX period) Black Michael via wsjt-devel kirjoitti 3.6.2022 klo 15.09: It has been fixed. http://n0nb.users.sourceforge.net/ Mike W9MDB On Friday, June 3, 2022, 05:03:29 AM CDT, Kari Sillanmäki via wsjt-devel wrote: Hi Saku, Michael, Mike et al I can duplicate this behaviour reported by Saku on my 7300. I'm using the rigctld-wsjtx bundled with WSJT-X 2.5.4 source tarball on Ubuntu 18.04.6 LTS. This seems to be a defect in hamlib; RX-frequency should always stay put. 73's de Kari, oh2gqc On 3.6.2022 10.58, Saku via wsjt-devel wrote: Subject: Re: [wsjt-devel] Hamlib testing From: Saku via wsjt-devel <mailto:wsjt-devel@lists.sourceforge.net> Date: 3.6.2022 klo 10.58 To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> CC: Saku <mailto:oh...@sral.fi> Hi Michael ! Could you test with your IC-7300 this way: set "split rig" and check "Allow TX frequency changes while transmitting" in settings/general tab Set your TX around 300Hz by shift+left click on waterfall. Start TX period and while your TX is on move your TX around 2800Hz by shift+left click on waterfall. When TX period is over does your RX return to selected (from band selector) frequency? Mine does not, it gets the TX (vfoB) frequency that must then be corrected with band selector back to right RX frequency. This happens if I have settings/Radio configured as ICOM 7300, or if I have started rigctld with script before starting wsjtx and then using Hamlib Net rigctld/localhost:4532 in settings/Radio. Both ways same result. OS is Fedora 35 linux. -- Saku OH1KH 5p1kzx Michael via wsjt-devel kirjoitti 2.6.2022 klo 18.32: Hi Everyone I have tested new the Hamlib with WSJT-X and JTDX in RIG and Fake It. I tested it with IC-7300, IC-7000 and IC-706Mk2g - behaviour as expected and no problems so far. 73 de Michael 5p1kzx ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
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
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
Re: [wsjt-devel] Hamlib testing
Hi Michael ! Could you test with your IC-7300 this way: set "split rig" and check "Allow TX frequency changes while transmitting" in settings/general tab Set your TX around 300Hz by shift+left click on waterfall. Start TX period and while your TX is on move your TX around 2800Hz by shift+left click on waterfall. When TX period is over does your RX return to selected (from band selector) frequency? Mine does not, it gets the TX (vfoB) frequency that must then be corrected with band selector back to right RX frequency. This happens if I have settings/Radio configured as ICOM 7300, or if I have started rigctld with script before starting wsjtx and then using Hamlib Net rigctld/localhost:4532 in settings/Radio. Both ways same result. OS is Fedora 35 linux. -- Saku OH1KH 5p1kzx Michael via wsjt-devel kirjoitti 2.6.2022 klo 18.32: Hi Everyone I have tested new the Hamlib with WSJT-X and JTDX in RIG and Fake It. I tested it with IC-7300, IC-7000 and IC-706Mk2g - behaviour as expected and no problems so far. 73 de Michael 5p1kzx ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Too bad WSJTx does not have even more tx adjustment steps, say related to whatever the needed tx BW of the mode is - maybe 100HZ for FT8. Then, operators with standard style adjustable tx BW in their rigs could limit their tx to just a bit more than the tx adjustment step to make a maximally-tight BW tx signal. An example: I run Thetis SDR on an ANAN radio which allow both adjustable tx BW and tx profiles. On FT8, I use a tx profile with the tx BW set for 600Hz - 1050Hz to 1550Hz. According to the tx monitor display, there are some very small FT8 tx sidebands, just visible below -100dB, even without over modulating. The Thetis tx BW filter will cut one side of these to below visibility when my tx center is near one edge of the WSJTx step. With 100Hz adjustment steps, I could cut both sidebands down (to 100Hz +/- a bit) no matter what my tx center frequency was. Though the sidebands are (probably) so low as to be insignificant, it would be nice and might be more valuable in different WSJTx modes. K6AVP - Los Osos, CA USA > On Jun 1, 2022, at 21:19, wsjt-devel-requ...@lists.sourceforge.net wrote: > > From: Black Michael mailto:mdblac...@yahoo.com>> > To: WSJT software development <mailto:wsjt-devel@lists.sourceforge.net>> > Subject: Re: [wsjt-devel] Hamlib testing > Message-ID: <1207100384.3374203.1654143570...@mail.yahoo.com > <mailto:1207100384.3374203.1654143570...@mail.yahoo.com>> > Content-Type: text/plain; charset=UTF-8 > > It's also to avoid the edges of your bandpass which can affect your > transmitted power. > > Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
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 Den 31-05-2022 kl. 18:04 skrev Black Michael via wsjt-devel: 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
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
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
Thu, 2 Jun 2022 13:37:07 +0930 Peter Sumner via wsjt-devel kirjoitti: > 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 Hi Peter Yes I understand that, because I have always used "fakeit". I don't want to mix my system, which is, VFO-A CW/SSB, VFO-B DIGI... As an age of 70, does not want complicated systems :) Jarmo, oh1mrr ___ 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
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 < wsjt-devel@lists.sourceforge.net> 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
Re: [wsjt-devel] Hamlib testing
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
Re: [wsjt-devel] Hamlib testing
Il 31/05/22 13:04, Black Michael via wsjt-devel ha scritto: 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 Hi Mike! Regarding Linux, after the testing stage passed, the new Hamlib version will be available on github as usual? Thanks! --- 73 de Marco, PY1ZRJ (former IK5BCU) ___ 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
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
Re: [wsjt-devel] Hamlib testing
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. 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 Mike, I tested using both Rig and Fake It with no problems. My interface is: WSJT-X - Win4Yaesu - Miocroham MicroKeyer - Yaesu FTDX 5000 73, Jim N6VH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Mike, I have some troubles with my FT-991 when using libhamlib-4.dll 20220601. Fake it worked well, but with Split Operation = Rig I noticed the following abnormal behavior: - When first switched to Rig, the VFO was switched twice and my FT-991 automatically switched from 50.313 MHz to 51.580 MHz and from WIDE 3 kHz to NAR 500 Hz. - When using Tune a couple of times, I got one case where my VFO stayed at 50.314 MHz. - When switching from Mode = Data/Pkt to USB or back to Data/Pkt, Display at FT-991 “blinks” time when pushing the “Tune” button and the displayed frequency for VFO B is “0 Hz” for about half a second. Then the correct frequency is set. These abnormalities were not there a few weeks ago. Anyone else of the FT-991 / FT-991a users observing the same? 73 de DG2YCB, Uwe German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: <mailto:dg2...@gmx.de> dg2...@gmx.de Info: <http://www.qrz.com/db/DG2YCB> www.qrz.com/db/DG2YCB Von: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] Gesendet: Dienstag, 31. Mai 2022 18:05 An: WSJTX Group; WSJT Software Development Cc: Black Michael Betreff: [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] Hamlib testing
Mike, Works fine on my TS590SG here in both Fakeit and Rig. Using Windows 10 and V2.5.4. Bobby/N4AU On 5/31/2022 11: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. 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 -- n...@outlook.com n...@arrl.net ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib testing
Limited testing using split and fake it seems to work fine. I only performed test cat and test ptt. OS - Kubuntu 20.04 WSJTX 2.5.4 Rig - TS-590SG I also have an IC-7300. If needed I can perform the same test with it. 73 Stan KM4HQE On 5/31/22 11:04, 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
Re: [wsjt-devel] Hamlib testing
Works FB in Fake It and Split here. Running WSJT-X v2.5.4 to a Yaesu FTDX-101MP. --Dennis NE6I From: Black Michael via wsjt-devel Sent: Tuesday, May 31, 2022 9:05 AM To: WSJTX Group ; WSJT Software Development Cc: Black Michael Subject: [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] 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
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 mailto:mdblac...@yahoo.com>> > To: WSJTX Group mailto:m...@wsjtx.groups.io>>, WSJT > Software Development ><mailto:wsjt-devel@lists.sourceforge.net>> > Subject: [wsjt-devel] Hamlib testing > Message-ID: <721045236.2890952.1654013085...@mail.yahoo.com > <mailto: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
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
Re: [wsjt-devel] Hamlib testing
Hi Mike! I have been using version that I have downloaded from Git on 2022-03-18 It has a problem that seems to be also in this latest version. Fedora 35 linux Wsjt-x v2.5.4 d28164-dirty Icom Ic 7300 I am starting rigctld from script with: mypath=/usr/local/bin/ myrigctld=rigctld myvfo='--vfo' start_rig (){ start_rig1 start_rig2 } start_rig1 (){ echo -n "IC7300 start " >> /tmp/start.log /usr/bin/date >> /tmp/start.log $mypath$myrigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0 $myvfo & Then at WSTX settings I use rig Net Hamlib rigctld localhost:4532, split rig. Everything seems to work ok (as earlier version) except that if wsjtx has started TX period and then I move tx frequency with Shift+left mouse it moves ok but when RX period comes back rig's vfoA stays on TX frequency and does not come back to RX frequency. This happens only if you are a bit too late moving TX frequency I.E. TX period has already started. If you do it before TX period starts it moves ok and RX vfoA stays on rx frequency as should. I have not bothered to report that because it is a marginal bug and can be avoided by not moving TX when transmit is on, or return right RX frequency right after TX period ends (if TX frequency was moved) using band selector. This is only "split rig" problem, and there only then when TX frequency differs from RX (I.E. on both ends of band slot) Black Michael via wsjt-devel kirjoitti 31.5.2022 klo 19.04: I need everyone to test the latest Hamlib Testing in Rig Split and Fake It would be appreciated. Successes/Failures please report. New hamlib for installation directions #1 Shut down WSJTX/JTDX #2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of WSJTX/JTDX -- hopefully your browser doesn't block it but may warn you multiple times. If you can do a "Save As" you can save it directly in \WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there. http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll Linux/Unix/Mac users need to compile the latest tar file from http://n0nb.users.sourceforge.net/ #3 If you don't save directly you need to open a file browser and move the file that way. If you're not familiar with that here's a video on the file browser - https://www.youtube.com/watch?v=AyVqCJrs9dk Mike W9MDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] 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