Date   

Re: Help: Ubuntu 20.04 Audio settings for IC7300 and IC9700 #linux

John N9ZL <jbrooks@...>
 

Hi Bill,

Thank you very much for that link.  That's exactly what I was looking for to modify the audio device names.  I used the udev rule verbatim from that article and it worked to change my audio device names in WSJTX so I can tell which is which. 

I changed WSJTX to use the new device names, and all 3 instances are getting audio from the right radios.  2 of them are transmitting, one is transmitting silence.

I went into the audio control to adjust the hot level on one receiver, and as soon as I came out, all 3 radios were receiving duplicate audio from that one source I adjusted.  I rebooted, and things went back to 3 good receive, 2 good send audio.

So audio weirdness continues, but at least now I know I'm configured using the right devices.  One step at a time.

73, John N9ZL



On 2/21/21 3:51 PM, Bill Somerville wrote:
Hi John, Richard, and Stewart,

have any of you tried something like the answer to this question:


It seems the ID_PATH_TAG variable available to udev rules can be used to name audio devices according to the physical hub and port paths where they are plugged in.

73
Bill
G4WJS.

On 21/02/2021 02:12, John N9ZL wrote:
Hi Richard,

I run 3 radios at once, an IC-7600, an IC-7300 and an IC-9700 in 3 different instances of WSJT-X 2.4.0-rc1 with Linux Mint 20.1 (based on Ubuntu).  I use the --rig-name option on the command line as explained in the manual for running multiple instances.  The radios are all USB connected.

I have lots of problems managing the sound devices.  They change names, configs that worked fine for days suddenly stop working, sound cards disappear from the list, the 2m IC-7900 instance will suddenly start displaying the same 40m audio that the IC-7600 is displaying after having worked fine for hours.  Weirdness like that.  Sometimes they work fine all day.

Part of the config confusion is due to how linux manages USB audio devices.  The names WSJT uses for the audio devices will vary depending on the order in which the devices are discovered by the OS.  So depending on what order you plug them in, the audio names will move around between different radios.  They should always get discovered after a reboot the same order, so make sure everything is plugged in and turned on before rebooting.

I've tried using the Burr-Brown settings you listed below but I find after a while they will sometimes suddenly stop working, and then go missing in WSJT-X even after a reboot. 

I have better luck with the hw:CARD=CODEC,DEV=0 entries for both transmit and receive.  But the system volume control doesn't appear to change the levels on those devices.  That can be a problem on the IC-7600 since output USB level can't be changed on the radio so the level stays in the red, but it seems to work.   I change the USB levels in the other radios themselves where possible.  The CODEC card name changes for each radio.  CODEC for the first, CODEC_1 for the second, CODEC_2 for the third.

"head -1 /proc/asound/CODEC/stream0"  "head -1 /proc/asound/CODEC_1/stream0" and "head -1 /proc/asound/CODEC_2/stream0" is useful to me in figuring out which USB port is assigned to which sound device when using the hw:CARD=CODEC,DEV=0 device.

Also, a hint for reliable CAT control on linux Mint/Ubuntu, use the names in /dev/serial/by-id for the CAT control.  These entries have the model of the radio in the name, and they link to the correct /dev/tty devices even when they get reordered.

73, John N9ZL

On 2/20/21 2:43 PM, Pa3gcu wrote:

Hi Stewart.

I have been playing with different radios and devices on linux this week, i find that things change every time one reboots,
However i have found that my IC705 which i have to define as a IC7300 (at least with wsjtx 2.1.2 and 2.2.2) works well
with the following devices;
Input; = alsa_input.usb-Burr-Brown_from_TI_USB_AUDIO_CODEC-00.analog-sterio
Output = als_output.usb-Burr-Brown_from_TI_USB_AUDIO_CODEC-00.analog-sterio

You may well see a difference from Jim's (VE4CY) possibly because he has a IC-9700 or he uses some or other
sound configuration device.
On another note, i see you mention 2 different radio's, i wonder do you run both at the same time under 20.04??.
If so i would be very interested to hear just how you configure the system as i have enormous trouble when i try to
run my FT950 together with a Microham MKIII keyer and the IC705 using it's internal codec's.

Anyway hope this help's.
Regards Richard PA3GCU.

 

Stewart Wilkinson via groups.io schreef op 20 feb '21:

Can anyone point in me in the direction of some guidance for setting up the audio with either IC7300 or IC9700 in Ubuntu 20.04 ?

I don't seem to be able to get it behaving - I either get the Tx audio coming out the LapTop speakers or none at all.

Also Linux keeps changing the system sound to use the Radio devices each time I plug them in.







Re: Help: Ubuntu 20.04 Audio settings for IC7300 and IC9700 #linux

Bill Somerville
 

Hi John, Richard, and Stewart,

have any of you tried something like the answer to this question:


It seems the ID_PATH_TAG variable available to udev rules can be used to name audio devices according to the physical hub and port paths where they are plugged in.

73
Bill
G4WJS.

On 21/02/2021 02:12, John N9ZL wrote:
Hi Richard,

I run 3 radios at once, an IC-7600, an IC-7300 and an IC-9700 in 3 different instances of WSJT-X 2.4.0-rc1 with Linux Mint 20.1 (based on Ubuntu).  I use the --rig-name option on the command line as explained in the manual for running multiple instances.  The radios are all USB connected.

I have lots of problems managing the sound devices.  They change names, configs that worked fine for days suddenly stop working, sound cards disappear from the list, the 2m IC-7900 instance will suddenly start displaying the same 40m audio that the IC-7600 is displaying after having worked fine for hours.  Weirdness like that.  Sometimes they work fine all day.

Part of the config confusion is due to how linux manages USB audio devices.  The names WSJT uses for the audio devices will vary depending on the order in which the devices are discovered by the OS.  So depending on what order you plug them in, the audio names will move around between different radios.  They should always get discovered after a reboot the same order, so make sure everything is plugged in and turned on before rebooting.

I've tried using the Burr-Brown settings you listed below but I find after a while they will sometimes suddenly stop working, and then go missing in WSJT-X even after a reboot. 

I have better luck with the hw:CARD=CODEC,DEV=0 entries for both transmit and receive.  But the system volume control doesn't appear to change the levels on those devices.  That can be a problem on the IC-7600 since output USB level can't be changed on the radio so the level stays in the red, but it seems to work.   I change the USB levels in the other radios themselves where possible.  The CODEC card name changes for each radio.  CODEC for the first, CODEC_1 for the second, CODEC_2 for the third.

"head -1 /proc/asound/CODEC/stream0"  "head -1 /proc/asound/CODEC_1/stream0" and "head -1 /proc/asound/CODEC_2/stream0" is useful to me in figuring out which USB port is assigned to which sound device when using the hw:CARD=CODEC,DEV=0 device.

Also, a hint for reliable CAT control on linux Mint/Ubuntu, use the names in /dev/serial/by-id for the CAT control.  These entries have the model of the radio in the name, and they link to the correct /dev/tty devices even when they get reordered.

73, John N9ZL

On 2/20/21 2:43 PM, Pa3gcu wrote:

Hi Stewart.

I have been playing with different radios and devices on linux this week, i find that things change every time one reboots,
However i have found that my IC705 which i have to define as a IC7300 (at least with wsjtx 2.1.2 and 2.2.2) works well
with the following devices;
Input; = alsa_input.usb-Burr-Brown_from_TI_USB_AUDIO_CODEC-00.analog-sterio
Output = als_output.usb-Burr-Brown_from_TI_USB_AUDIO_CODEC-00.analog-sterio

You may well see a difference from Jim's (VE4CY) possibly because he has a IC-9700 or he uses some or other
sound configuration device.
On another note, i see you mention 2 different radio's, i wonder do you run both at the same time under 20.04??.
If so i would be very interested to hear just how you configure the system as i have enormous trouble when i try to
run my FT950 together with a Microham MKIII keyer and the IC705 using it's internal codec's.

Anyway hope this help's.
Regards Richard PA3GCU.

 

Stewart Wilkinson via groups.io schreef op 20 feb '21:

Can anyone point in me in the direction of some guidance for setting up the audio with either IC7300 or IC9700 in Ubuntu 20.04 ?

I don't seem to be able to get it behaving - I either get the Tx audio coming out the LapTop speakers or none at all.

Also Linux keeps changing the system sound to use the Radio devices each time I plug them in.



Re: Help: Ubuntu 20.04 Audio settings for IC7300 and IC9700 #linux

Kenneth Williams
 

Although I have not been right on other suggestions, let me give a shot at this problem.
In linux, devices, such as USB devices, can be given custom 'dev' names using udev naming rules.
I do not have a USB connected radio but I have dealt with the situation where I have had multiple instances of a USB dongle (in this case a debugger) connected to my linux machine.  In order to make sure that I am talking to the right one, and that they always came up with consistent names, I used udev rules to force the creation of a unique name based on certain attributes of the connected device.

I know that I am not explaining how to do this, and I don't think that I could do this blind, but I wanted to provide a pointer to a possible resolution to this problem.  My suggestion from this point would be to find your local linux person that is knowledgeable in this area and bring them to your place to help you with this.

Regards

Ken
KC6PUQ


[SOLVED] Re: [WSJTX] [WSJT-X] Unable to properly #install wsjt=-x auto logging to Log4OM #install

Andy_501 <andrew.webb.501.ve4per@...>
 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP
Change the value of "start" to 4, which means disabled.  Reboot PC


All the troubleshooting steps to find a process ID to end and solution was as above:

*************************************************************************
Nothing appears to be using port 80 yet:

both wampache64 service and telnet command below get same results

C:\WINDOWS\system32>telnet 127.0.0.1 80
Connecting To 127.0.0.1...Could not open connection to the host, on port 80: Connect failed

C:\WINDOWS\system32>

no servers launched and all WAMP64 services disabled cmd status requests returned:


C:\WINDOWS\system32>netstat -o -n -a | findstr 0.0:80

C:\WINDOWS\system32>netsh http show servicestate

Snapshot of HTTP service state (Server Session View):
-----------------------------------------------------

Server session ID: FF00000120000001
    Version: 2.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FE00000140000001
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 1
            Registered URLs:
                HTTP://*:5357/BBC53C66-F4F2-490C-9501-ED6AC15A2B4F/

Server session ID: FF00000320000001
    Version: 2.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FF00000040000005
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 1
            Registered URLs:
                HTTP://LOCALHOST:58941/

Request queues:
    Request queue name: Request queue is unnamed.
        Version: 2.0
        State: Active
        Request queue 503 verbosity level: Basic
        Max requests: 1000
        Number of active processes attached: 1
        Process IDs:
            3060

    Request queue name: Request queue is unnamed.
        Version: 2.0
        State: Active
        Request queue 503 verbosity level: Basic
        Max requests: 1000
        Number of active processes attached: 1
        Process IDs:
            11224




On 2021-02-21 08:44, Andy_501 via groups.io wrote:
It appears Win10 Pro's latest update has made a change to access to port 80 such that Wampache64 portion of the WAMP server bundle does not start.

Thus without apache running phpmyadmin will not give access to a MariadB or mysql Log4OM database if you chose to use that on install of Log4OM. Not sure if https default port was likewise affected. I completely lost all Log4OM db setups when I assumed it was a corrupt WAMP s/w and re-installed it before discovering the port 80 block.

I changed the port config in the wampache64 tools to 8088 and all started normally so it appears I can rebuild the lost log database. If anyone has come across this and has a fix to restore access to the standard http and https ports of 80 & 443 any info and tips would be appreciated.

Some suggested google search fixes suggest it is related to iis service having to be disabled in windows control panel Programs & Features --> turn windows features on/off disable web services but that is already OFF when I checked so that is not causing the block.

Getting WSJT-x to autolog to Log4OM for me on hold now until I can come up with a fix so that all three services apache, Maria/msql dB's and php all work properly with original default port settings so I can safely rebuild the db to work with and have WSJT-x access.


Thanks & 73

Andy ve4per





Re: 2.3.0 TX No Audio after Band Change #FT8 #AudioIssues

Robert Lorenzini
 

I can confirm the OP's report. I have exactly the same problem with CAT
keying. The rig keys up but no audio after band change tune or tx. Halt and
tx restores mostly.

Bob - wd6dod

On 2/21/2021 9:50 AM, Randy Reynard wrote:
Answers to the questions - and / or comments:

 Do you Stop monitoring and Halt Tx before a band change?
> No,  I didn't need to stop monitoring in prior versions.  I never change bands during a TX so the 2nd part of that question doesn't apply.

> The RFI question doesn't apply because I'm never transmitting when this happens.  The PTT method I use is CAT. The radio goes into TX with no issues, but there's just no audio.

R: So after changing the band you have received a full timeslot to spot somebody and double-clicked his call, I assume. And your Tx has gone to transmit at the beginning of next appropriate TX cycle, but no audio. After noting that you use “halt Tx” and “Enable Tx” and still no audio. Or did I missed something? Or do you have “Double-click on call sets Tx enable” unticked and you use “Enable Tx” to invoke transmission?
>Your assumption is correct.  I'm waiting for a callsign to show up - after a decode - than double clicking on it to initiate a response, and yes during the beginning of an appropriate TX cycle.   The second part of your question is no longer valid, as I've discovered that a "halt/enable" cycle does restore audio during TX.

Does this “no audio after band change” happen also, when you try to send a CQ in the next available Tx period after band change? I assume that there is no confusion about “Tx even/1st “ and which time-slot is used for transmission.
> I don't know, because I always listen for other stations and respond after a band change.  I understand the "TX even/1st" concept.   I've been using this program for well over a year and haven't had any issues until 2.3.0.

I have assumed that audio is sent at the same time as CAT has commanded PTT on. By the way which PTT method you are using and which rig we are talking about? We have some unknown issue in your system.
>As I have answered or provided before, I am using CAT control to command PTT.  The rig is an ICOM 7300, I now know of at least 3 other 7300 owners with the same issue, as well as Yaesu and other ICOM models.  Others i have contacted agree that nothing changed in their setup except to upgrade to 2.3.0.  They can all restore the transmitted audio by doing a "halt/enable" cycle.

I appreciate your interest and support - I hope my answers are understandable.

W0RDR






Re: 2.3.0 TX No Audio after Band Change #FT8 #AudioIssues

Reino Talarmo
 

Hi Randy.

I tested what happens with my FTdx3000 and could not repeat your non-TX after a band change at all.

Transmission started (with audio) either by double-clicking or Enable Tx immediately after a band change as long as TX-timeslot was valid. This time I did that testing using v2.4.0-rc1. I am using a single USB connection to rig and CAT PTT. Split is set to Rig. So no luck to repeat your behavior, sri.

 

By the way you should Stop monitoring before a band change as you are uploading to PSKreporter. At least in earlier versions it was possible that previous band spots were uploaded as, if they were received on the new band, hi!

 

73, Reino OH3mA

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Randy Reynard
Sent: 21. helmikuuta 2021 19:50
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] 2.3.0 TX No Audio after Band Change #FT8 #AudioIssues

 

Answers to the questions - and / or comments:

 Do you Stop monitoring and Halt Tx before a band change?
> No,  I didn't need to stop monitoring in prior versions.  I never change bands during a TX so the 2nd part of that question doesn't apply.

> The RFI question doesn't apply because I'm never transmitting when this happens.  The PTT method I use is CAT. The radio goes into TX with no issues, but there's just no audio.

R: So after changing the band you have received a full timeslot to spot somebody and double-clicked his call, I assume. And your Tx has gone to transmit at the beginning of next appropriate TX cycle, but no audio. After noting that you use “halt Tx” and “Enable Tx” and still no audio. Or did I missed something? Or do you have “Double-click on call sets Tx enable” unticked and you use “Enable Tx” to invoke transmission?
>Your assumption is correct.  I'm waiting for a callsign to show up - after a decode - than double clicking on it to initiate a response, and yes during the beginning of an appropriate TX cycle.   The second part of your question is no longer valid, as I've discovered that a "halt/enable" cycle does restore audio during TX.

Does this “no audio after band change” happen also, when you try to send a CQ in the next available Tx period after band change? I assume that there is no confusion about “Tx even/1st “ and which time-slot is used for transmission.
> I don't know, because I always listen for other stations and respond after a band change.  I understand the "TX even/1st" concept.   I've been using this program for well over a year and haven't had any issues until 2.3.0.

I have assumed that audio is sent at the same time as CAT has commanded PTT on. By the way which PTT method you are using and which rig we are talking about? We have some unknown issue in your system.
>As I have answered or provided before, I am using CAT control to command PTT.  The rig is an ICOM 7300, I now know of at least 3 other 7300 owners with the same issue, as well as Yaesu and other ICOM models.  Others i have contacted agree that nothing changed in their setup except to upgrade to 2.3.0.  They can all restore the transmitted audio by doing a "halt/enable" cycle.

I appreciate your interest and support - I hope my answers are understandable.

W0RDR


Re: #Q65 ...Using Q65 on 6m #Q65

Lance Collister, W7GJ
 

Hi Jim,

This for sure is not just a mode to be used for scatter contacts! I expect this spring, we will see Q65 being used between Region 2 and ZL/VK on either 50.285 or 50.305, and I am sure this summer Q65 will be used on 50.305 for some weak signal contacts between NA and EU! Also, I am VERY EXCITED that in a few days I have some EME skeds with a couple new countries using Q65, and I will report the results here.

GL and VY 73, Lance

On 2/21/2021 19:42:35, Jim Brown wrote:

The primary use I'm aware of for Q65 on 6M is ionospheric scatter, which maxes out in the range of 900-1100 miles, so coordination of operating frequencies with other regions may be of less importance.

73, Jim K9YC




--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB)
P.O. Box 73
Frenchtown, MT 59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME? Ask me about subscribing to the new Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!


Re: #Q65 ...Using Q65 on 6m #Q65

Jim Brown
 

On 2/21/2021 9:01 AM, KD7YZ Bob wrote:
Also wonder is there a web-based BBS where MANY ops hang out who might
notice if I relayed the fact I am on 6m Q65-30A ?
The primary hangout that I'm aware of for coordinating NA VHF activity is the VHF-Slack group. An invitation is needed to join. If you are interested, I'll ask the group's admin to send you a link. This group has been quite active with beta test of Q65, among many other activities. There are chats within it for EME, MS, E-skip, expeditions, general stuff, and even a swap.

The primary use I'm aware of for Q65 on 6M is ionospheric scatter, which maxes out in the range of 900-1100 miles, so coordination of operating frequencies with other regions may be of less importance.

73, Jim K9YC


Re: #Q65 ...Using Q65 on 6m #Q65

ve4cy
 

----- Original Message -----
From: "KD7YZ Bob" <kd7yz@denstarfarm.us>
To: main@WSJTX.groups.io
Sent: Sunday, February 21, 2021 11:01:57 AM
Subject: [WSJTX] #Q65 ...Using Q65 on 6m

Hi
I have been calling CQ on 50.313 the last couple days.
Dunno if that is the correct spot.

Also wonder is there a web-based BBS where MANY ops hang out who might
notice if I relayed the fact I am on 6m Q65-30A ? It's ahrd to find anyone using it on 6m
--
--
73
Bob KD7YZ



--------------------

Hi Bob:

Most people have "Enable PSK Reporting" set in the reporting tab. The tab is in the 'settings' function. When set, all contacts are logged on PSK reporter. (providing you have an internet connection). This makes it an excellent resource.

I use the PSK Reporter map to see who's on what frequency and what mode they are using.

https://pskreporter.info/pskmap.html

In the above link, fill in the boxes on the top of the map like this:

On [6 meters] show [signals] [sent/rcvd] by [anyone] using [Q65] over the last [choose your time].

That will show you who's talking to who. Also.. Some people leave WSJT-X running when they're away from the computer. If you call CQ and and unattended station picks you up, your station will show up as a pin on the PSK map.. even though nobody answered you.

As mentioned use 50.275 Mhz for 6m Q65

73 de Jim VE4CY


Re: 2.3.0 TX No Audio after Band Change #FT8 #AudioIssues

Randy Reynard
 

Answers to the questions - and / or comments:

 Do you Stop monitoring and Halt Tx before a band change?
> No,  I didn't need to stop monitoring in prior versions.  I never change bands during a TX so the 2nd part of that question doesn't apply.

> The RFI question doesn't apply because I'm never transmitting when this happens.  The PTT method I use is CAT. The radio goes into TX with no issues, but there's just no audio.

R: So after changing the band you have received a full timeslot to spot somebody and double-clicked his call, I assume. And your Tx has gone to transmit at the beginning of next appropriate TX cycle, but no audio. After noting that you use “halt Tx” and “Enable Tx” and still no audio. Or did I missed something? Or do you have “Double-click on call sets Tx enable” unticked and you use “Enable Tx” to invoke transmission?
>Your assumption is correct.  I'm waiting for a callsign to show up - after a decode - than double clicking on it to initiate a response, and yes during the beginning of an appropriate TX cycle.   The second part of your question is no longer valid, as I've discovered that a "halt/enable" cycle does restore audio during TX.

Does this “no audio after band change” happen also, when you try to send a CQ in the next available Tx period after band change? I assume that there is no confusion about “Tx even/1st “ and which time-slot is used for transmission.
> I don't know, because I always listen for other stations and respond after a band change.  I understand the "TX even/1st" concept.   I've been using this program for well over a year and haven't had any issues until 2.3.0.

I have assumed that audio is sent at the same time as CAT has commanded PTT on. By the way which PTT method you are using and which rig we are talking about? We have some unknown issue in your system.
>As I have answered or provided before, I am using CAT control to command PTT.  The rig is an ICOM 7300, I now know of at least 3 other 7300 owners with the same issue, as well as Yaesu and other ICOM models.  Others i have contacted agree that nothing changed in their setup except to upgrade to 2.3.0.  They can all restore the transmitted audio by doing a "halt/enable" cycle.

I appreciate your interest and support - I hope my answers are understandable.

W0RDR


Re: #FST4W no decode #FST4W

Mark ~ AE2EA
 

It looks like your software is set to decode wspr-2, not fst4w-120


Re: Mode / Submode Q65 #Q65

Dave H
 

Many Thanks... 

I have seen a post on a logbook forum on this topic of adding Q65 to logging option

best 73 Dave


Re: #Q65 ...Using Q65 on 6m #Q65

KD7YZ Bob
 

On 2/21/2021 12:26, Jim - N4ST wrote:
Still gelling, but 50.275 is the US freq
Alrighty then, 50.275 she is.

--
73
Bob KD7YZ


--
--
Bob KD7YZ in NE Kentucky


Re: #Q65 ...Using Q65 on 6m #Q65

KD7YZ Bob
 

On 2/21/2021 12:15, Lance Collister, W7GJ wrote:
Q65-30A for ionospheric propagation is most likely
taking place either on 50.305 or 50.275. GL and VY 73 Lance
Thanks Lance, I'll move there

--
73
Bob KD7YZ


--
--
Bob KD7YZ in NE Kentucky


Re: #Q65 ...Using Q65 on 6m #Q65

Jim - N4ST
 

Still gelling, but 50.275 is the US freq and 50.305 is the Euro freq for Q65A.
I've made a few contacts, including K1JT.

GL & 73
Jim - N4ST

-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of KD7YZ Bob
Sent: Sunday, February 21, 2021 12:02
To: main@WSJTX.groups.io
Subject: [WSJTX] #Q65 ...Using Q65 on 6m

Hi
I have been calling CQ on 50.313 the last couple days.
Dunno if that is the correct spot.

Also wonder is there a web-based BBS where MANY ops hang out who might
notice if I relayed the fact I am on 6m Q65-30A ? It's ahrd to find anyone using it on 6m
--
--
73
Bob KD7YZ


Re: #Q65 ...Using Q65 on 6m #Q65

Lance Collister, W7GJ
 

Hi Bob,

You can coordinate 6m activity on the ON4KST REGION 2 CHAT PAGE:

http://www.on4kst.info/chat/login.php?band=7 <http://www.on4kst.info/chat/login.php?band=7>

You probably didn't get much activity though because 50.313 is the FT8 calling frequency. Q65-30A for ionospheric propagation is most likely taking place either on 50.305 or 50.275. GL and VY 73 Lance

On 2/21/2021 17:01:57, KD7YZ Bob wrote:
Hi
I have been calling CQ on 50.313 the last couple days.
Dunno if that is the correct spot.

Also wonder is there a web-based BBS where MANY ops hang out who might
notice if I relayed the fact I am on 6m Q65-30A ? It's ahrd to find anyone using it on 6m

--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB)
P.O. Box 73
Frenchtown, MT 59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME? Ask me about subscribing to the new Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!


#Q65 ...Using Q65 on 6m #Q65

KD7YZ Bob
 

Hi
I have been calling CQ on 50.313 the last couple days.
Dunno if that is the correct spot.

Also wonder is there a web-based BBS where MANY ops hang out who might
notice if I relayed the fact I am on 6m Q65-30A ? It's ahrd to find anyone using it on 6m
--
--
73
Bob KD7YZ


Re: #FT8 Can't get my FT-991A om 60M #FT8

Cliff Fox (KU4GW)
 

Ken,
        That was also a pretty accurate description of the licensing question pool study manuals of today as compared to the ones of just 24 years ago. I think they all need to require new hams at least get a basic understanding of the theory instead of just memorizing the questions and answers. I was even more convinced of this when a new General Class operator keyed up on the 75 meter phone frequency I frequently hang out on a while back and ask us for a SWR report! 

Very 73,
Cliff, KU4GW 


Re: #Cat_RigControl no FT-2000 #Cat_RigControl

David Redman
 

Boris,
I never got wsjt-x to work on TX  with rig control on my FT2000 when using the FT2000 transverter mode.

As you say it faults on TX, I tried entering 44.xxx into wsjt-x but that didn, t work either.

The FT2000 works well with wsjt-x on HF and 6m full rig control so I think it's a strange fault when in transverter and tx mode.( I don't thing its rig control but the way the FT2000 goes into transverter mode and displays 44.xxxMHz

I could use the FT2000 with a transverter by attenuating the 100w and using a 116MHz offset in wsjt-x to get doppler correction etc ( if going to use 144MHz as an IF for 23cms and higher bands but in the end I didn't like attenuating 100w to 10mW for the transverter and I used another HF rig as prime mover.

I did ask on the wsjt reflector but it seemed some 2 years ago nobody had solved the issue... Maybe somebody has?

If you find a solution well done and I would be interested as the FT2000 would make an idea transverter source and for the higher uhf and microwave bands it will change frequency on TX which even some more modern rigs will not do

Good luck

Dave
G4IDR 




On Sun, 21 Feb 2021, 15:44 , <9a3tn@...> wrote:

[Edited Message Follows]

Problem with ver.2.3.0 on My band (2m with transverter). Display shows 44,174MHz ( i have offset -100MHz in setup) and it's OK on RX, but on TX program pop up window with message that its. not correct freq. 

Boris 9a3tn




Re: #FST4W no decode #FST4W

Corneliu
 

Yes, for sure.
73 Corneliu

7761 - 7780 of 30118