|
locked
Re: Using radios for wajtx and remote
#Cat_RigControl
Gerald Klotz
I do have power out now both locally on the server and remotely. I am not sure but I believe the problem was with the com ports. I ended up installing a few things then reinstalling it and then renamed the cöm ports for the radio. Windows update is not your friend as far as com ports are involved.
toggle quoted messageShow quoted text
Gerry Klotz
On Apr 19, 2021, at 7:46 PM, Joel <styx@...> wrote:
|
|
|
|
locked
IC-7300 sudden CAT issue
#AudioIssues
#bluetooth
#IssueReport
#Cat_RigControl
Mike Cummings
I'm stumped and can't find anything about this issue after a lot of googling.
I'm on Windows 10 on an ASUS laptop and my rig is an IC-7300. Suddenly, when I attempt to transmit (FT8) with my IC-7300, I get transmission, but at the end of the cycle, it just keeps transmitting. The only way to stop it is with the TRANSMIT button on the front panel. But after that, PTT control seems to be locked. Then the Test PTT button in Settings is grayed out. If I try exiting WSJT-X and relaunch, I get a message that another instance is running and it asks me if I want to remove the stale lock file. No answer works, and I can't kill it in Task Manager. All I can do is reboot, but then after launching WSJT-X, I just have the same problem. I've been running FT8 every day for a week without problem. The only thing that's different is that I installed Gridtracker. The problem occurs whether Gridtracker is running or not. My station isn't permanent. I live in a small rental house with no room for a shack, so I set up outside. I don't have a proper ground, because I can't here. I'm not allowed to drive a ground rod. I'm using an end-fed with my internal tuner. I know it's a compromise antenna. It's what I have for now. It's hard to get my ideal antenna due to rental restrictions and the fact that I'm disabled. I'm just using a USB cable without an intervening interface. What gets me is that I've made 150 or so QSOs the past few days without problems and I haven't changed anything. I've reinstalled the USB driver, rearranged my USB cable, which had ferrite beads on both ends, and I don't know what else to do. Any ideas would be welcome. Thanks. Mike NX7E
|
|
|
|
locked
Re: Using radios for wajtx and remote
#Cat_RigControl
Gerry Do you now have power out on transmit - it appeared that was the original problem that you were concerned about? Joel AC8WS
On Apr 19, 2021, at 8:19 PM, Gerald Klotz <KB9PKI@...> wrote:
|
|
|
|
locked
Re: #bugreport ALL.TXT
#IssueReport
Sam Birnbaum
Hi Bill,
Yes, it is a bug. I would suggest you test the RC release of ver 2.4 and see if it is in there as well.
I had to make special provisions in my Alltext.exe program to accommodate that bug.
73,
Sam W2JDB
-----Original Message-----
From: Bill Lederer <w8lvn.9@...> To: main@wsjtx.groups.io Sent: Mon, Apr 19, 2021 8:11 pm Subject: Re: [WSJTX] #bugreport ALL.TXT So if adding the date to the beginning of a log file takes more than a handful of microseconds, I would be surprised. The bulk of time would be actually taking the underlying unix time (in seconds) and converting it to a string. This is already done for the display of the signal on the left panel.
Secondly, the date is not changing on either the 1.840 lines, nor on the 18.100 or the 10.136 FT8 lines, but the time is put on those lines. Clearly the time changes, however.
Further, for the MSK144 lines, they occupy the clock time between 210419_140330 and 240419_070515, which is on the order of 7 hours. At what time does the line Z4VUR/R RH0BDY/R R DH26 occur? There is no way to tell from ALL.TXT.
Finally, why would it behave differently on FT8 as opposed to MSK144?
With respect to the release notes, for RC3 it says:
- Repair regression with missing time-stamps in the ALL.TXT journal. It would appear from my RC3 use and now RC4, that there are situations still exhibiting the behavior.
I am thinking this is a bug.
On Mon, Apr 19, 2021 at 6:18 PM Dave Garber <ve3wej@...> wrote:
--w8lvn--
|
|
|
|
locked
Re: Using radios for wajtx and remote
#Cat_RigControl
Gerald Klotz
Yes the settings are separate. I have the radios working locally with wsjtx and through rsbs1 locally. The radios now work remotely but I am trying to get FLdigi and flrig set up.
toggle quoted messageShow quoted text
I have flrig and Fldigi working locally on the 7300 but not on the 9700. I haven’t gotten Fldigi or flrig working remotely yet. Gerry Klotz Kb9pki
On Apr 19, 2021, at 6:25 PM, Dave Garber <ve3wej@...> wrote:
|
|
|
|
locked
Re: #bugreport ALL.TXT
#IssueReport
Bill Lederer
So if adding the date to the beginning of a log file takes more than a handful of microseconds, I would be surprised. The bulk of time would be actually taking the underlying unix time (in seconds) and converting it to a string. This is already done for the display of the signal on the left panel. Secondly, the date is not changing on either the 1.840 lines, nor on the 18.100 or the 10.136 FT8 lines, but the time is put on those lines. Clearly the time changes, however. Further, for the MSK144 lines, they occupy the clock time between 210419_140330 and 240419_070515, which is on the order of 7 hours. At what time does the line Z4VUR/R RH0BDY/R R DH26 occur? There is no way to tell from ALL.TXT. Finally, why would it behave differently on FT8 as opposed to MSK144? With respect to the release notes, for RC3 it says: - Repair regression with missing time-stamps in the ALL.TXT journal. It would appear from my RC3 use and now RC4, that there are situations still exhibiting the behavior. I am thinking this is a bug.
On Mon, Apr 19, 2021 at 6:18 PM Dave Garber <ve3wej@...> wrote:
--
--w8lvn--
|
|
|
|
locked
Re: Using radios for wajtx and remote
#Cat_RigControl
Dave Garber
are you settings things separate under the configurations tab?? Dave Garber VE3WEJ / VE3IE
On Tue, Apr 13, 2021 at 4:02 PM Gerald Klotz <KB9PKI@...> wrote:
|
|
|
|
locked
Re: #bugreport ALL.TXT
#IssueReport
Sam Birnbaum
I has not been this way for a long time. It was a bug that was corrected but seems to be still in the version that bill is using.
I was running the Windows version and it was corrected in a later RC release.
If appending the date and time slows the process on your PC, then you have a problem with your hardware.
73, Sam W2JDB
-----Original Message-----
From: Dave Garber <ve3wej@...> To: WSJT-x group <main@wsjtx.groups.io> Sent: Mon, Apr 19, 2021 7:17 pm Subject: Re: [WSJTX] #bugreport ALL.TXT this has been this way for quite a while, I would have to look at release notes. but sounds normal. if the date does not change why append with it and slow the process..
Dave Garber
VE3WEJ / VE3IE
On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer <w8lvn.9@...> wrote:
|
|
|
|
locked
Re: #bugreport ALL.TXT
#IssueReport
Dave Garber
this has been this way for quite a while, I would have to look at release notes. but sounds normal. if the date does not change why append with it and slow the process.. Dave Garber VE3WEJ / VE3IE
On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer <w8lvn.9@...> wrote:
|
|
|
|
locked
Re: #bugreport ALL.TXT
#IssueReport
Bill Lederer
This issue still exists for Rc4, but apparently only for MSK144. Looks fine for FT8, but not MSK144 210419_070415 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62 210419_070445 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62 210419_070515 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62 50.260 Rx MSK144 -6 7.0 1440 VE9GJ K2DRH EN41 50.260 Rx MSK144 -5 11.3 1440 VE9GJ K2DRH EN41 50.260 Rx MSK144 -6 9.8 1440 VE9GJ K2DRH EN41 50.260 Rx MSK144 -5 13.7 1440 VE9GJ K2DRH EN41 50.260 Rx MSK144 -2 1.1 1440 VE9GJ K2DRH EN41 50.260 Rx MSK144 -1 2.5 1440 VE9GJ K2DRH EN41 50.260 Rx MSK144 -2 0.7 1440 VE9GJ K2DRH EN41 50.260 Rx MSK144 -7 13.3 1440 VE9GJ K2DRH RRR 50.260 Rx MSK144 -1 26.4 1475 N0AN K1RZ +02 50.260 Rx MSK144 0 23.0 1472 N0AN N1KWF FN32 50.260 Rx MSK144 -1 22.6 1460 N0AN N1KWF FN32 50.260 Rx MSK144 1 28.9 1464 N0AN N1KWF FN32 50.260 Rx MSK144 -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26 50.260 Rx MSK144 8 22.6 1462 VE4CY W9DR EM78 50.260 Rx MSK144 11 22.9 1462 VE4CY W9DR EM78 50.260 Rx MSK144 12 27.0 1462 VE4CY W9DR EM78 50.260 Rx MSK144 15 27.3 1460 VE4CY W9DR EM78 50.260 Rx MSK144 13 15.5 1460 VE4CY W9DR EM78 50.260 Rx MSK144 14 26.1 1462 VE4CY W9DR EM78 50.260 Rx MSK144 3 16.0 1462 VE4CY W9DR EM78 50.260 Rx MSK144 4 16.0 1463 VE4CY W9DR EM78 50.260 Rx MSK144 6 16.6 1461 VE4CY W9DR EM78 50.260 Rx MSK144 7 16.7 1461 VE4CY W9DR EM78 50.260 Rx MSK144 13 18.4 1463 VE4CY W9DR EM78 50.260 Rx MSK144 14 18.4 1463 VE4CY W9DR EM78 50.260 Rx MSK144 -3 15.5 1463 VE4CY W9DR EM78 50.260 Rx MSK144 5 20.8 1462 VE4CY W9DR RRR 50.260 Rx MSK144 6 29.2 1462 VE4CY W9DR RRR 50.260 Rx MSK144 7 29.3 1460 VE4CY W9DR RRR 210419_140330 18.100 Rx FT8 -6 0.2 780 N5HHS N3GX R+05 210419_140330 18.100 Rx FT8 -11 0.2 1591 KB2M KI4KDR EM45 210419_140330 18.100 Rx FT8 -12 0.1 1261 CQ N3NVA FN20 210419_140400 10.136 Rx FT8 14 0.1 1328 CQ VA3MJR FN03 210419_140400 10.136 Rx FT8 1 0.1 607 KG0TR VE3RXO R-13 Thanks, w8lvn
--
--w8lvn--
|
|
|
|
locked
Re: #bugreport ALL.TXT
#IssueReport
Bill Lederer
Well, my issue was in the RC3 release. I'm now running with RC4, and will see if it iis still there. w8lvn
--
--w8lvn--
|
|
|
Hi Jim and all, Probably it will not surprise you that we've done some of this, especially with respect to time of day. It's very easy to show that ionoscatter conditions are best around mid-day and worst around 7 or 8 PM local time.Scatter signals are so highly variable that the only way to makeVery interesting. Given the highly variable nature of propagation and But we decided not to spend time on more extensive tests with respect to time of year, but rather to spend some time in a good research library. Steve and I have access to excellent ones at the University of Illinois and Princeton University, respectively. D-Region ionospheric scattering at VHF was studied exhaustively in the late 1950s. An excellent summary of such studies carried out by the Central Radio Propagation Laboratory of the US National Bureau of Standards was published in 1961, and I've posted a copy here: https://physics.princeton.edu/pulsar/k1jt/NBS_D-region_scatter.pdf. For a summary of diurnal, seasonal, and frequency dependence of signal strengths see their Figure 6. -- 73, Joe, K1JT
|
|
|
|
Andy Talbot
A brief update on progress. PIC code for the later generation enhanced device, the 16F1827, now exists that will turn 13 characters of Plain text, or 17.75 Hex characters into a set of symbols ready to go for transmission. So the encoding stage is complete. I have no interest in compressing any other types of message, just plain text and Telemetry (raw data). At the moment the Plain Text is retrieved from the EEProm memory space. or Telemetry format data entered as a hex string into the assembly file. The whole encoding routine takes up a bit less than 2K words of programme memory. Of that 1112 (14 bit) words are for the parity matrix, and 768 words of executable code Now that is done and tested, I want to take a break for a bit before combining it with the beacon source - not least as there are still things to learn about the 16F1827 PIC device. I used this FST4 encoding exercise as a way to break into using that more advanced chip. The code won't be made public just yet, but if anyone does want a copy of what is written so far, please contact me off-Group. Note that this is for FST4, not FST4W. The latter wouldn't need too many changes; source encoding, parity matrix and various pointer and constant values. Andy
|
|
|
|
Phil Moore
Hi Mark
I also have a 6400 and have had similar - mine changes to LSB on 40m downwards - I think due to the turf file on the 6400 assuming that those bands are normally LSB. All other bands work fine. I get around it by using FR Stacks most recently used memories to change to the affected bands which remembers that I want USB. It also has some other natty features such as when I select 60m, it changes the profile being used, changes to ANT2 and alters the TX upper filter appropriately. Hope that helps. It's a useful add on for Flex users. 73 Phil M0TZZ
|
|
|
|
On 19/04/2021 02:22, Mark Gottlieb wrote:
Good Evening All,Hi Mark, this is due to a regression in the TS-200 driver in hamlib, which I assume you are using. It is fixed for the next release, you can either change to "Settings->Radio->None" in WSJT-X and set the mode manually, or use the Flex 6xxx network driver in WSJT-X to communicate directly with SmartSDR, which does not have this fault. 73 Bill G4WJS.
|
|
|
|
locked
Re: #bugreport ALL.TXT
#IssueReport
Sam Birnbaum
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
73, Sam W2JDB
-----Original Message-----
From: Bill Lederer <w8lvn.9@...> To: WSJTX@groups.io Sent: Sun, Apr 18, 2021 9:54 pm Subject: [WSJTX] #bugreport ALL.TXT Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
|
|
|
|
Dave Garber
on the radio settings tab, see if mode is set to data/pkt, your radio may be trying to use bandplan as its setting, this should override it, i think Dave Garber VE3WEJ / VE3IE
On Sun, Apr 18, 2021 at 10:03 PM Mark Gottlieb <kk2l@...> wrote: Good Evening All,
|
|
|
|
locked
#bugreport ALL.TXT
#IssueReport
Bill Lederer
Team: I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make. What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144. Is this a known issue? I have just downloaded and installed the rc4 version in case the issue is resolved. (I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.) --w8lvn--
|
|
|
|
Good Evening All,
I have been operating WSJT-x for years and have not had this problem before. My FLEX 6400 just started defaulting to LSB on TX on all bands. I am not having the same problem with FLDIGI. I have been using FLEX equipment for the last 5 years. Can't figure out the cause. Any suggestions? 73 Mark KK2L
|
|
|
|
Joe Dz
Thank you Joe for the data and Jim also makes a very good comment. When I
toggle quoted messageShow quoted text
was looking at how weather storm systems affect transatlantic 6m communications, and also during the winter months when we have the second Es season, Es formed over storm systems and fast moving jet stream fronts. However, a geomagnetic storm (G1 or K5 or better) would negate the effect. It would be very interesting to see as people collect data, that they also record what the geomagnetic field was doing at the time. The question being: does an unsettled or stormy geomagnetic field also negate the ionosphere scatter like it negates the weather effects that would normally cause Es over storm systems or fronts? If folks also record the K value as well on multiple day tests, that data would be very interesting. Joe, K1YOW
-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Jim Brown Sent: Sunday, April 18, 2021 3:24 PM To: main@WSJTX.groups.io Subject: Re: [WSJTX] Q65 in less favourable condx? #Q65 On 4/18/2021 9:08 AM, Joe wrote: Scatter signals are so highly variable that the only way to makeVery interesting. Given the highly variable nature of propagation and the different modes of which we try to take advantage, it would be interesting to see this sort of work repeated on multiple days and at different times of day. 73, Jim K9YC
|
|
|