Date   

locked Re: #raspberryPi #WSJTX_config #raspberryPi #WSJTX_config

Bill Somerville
 

On 13/02/2021 22:28, David 2E0HIL wrote:

Bill

I am using the 6 pin mini din for the data connection not the cat Din and I am having to use a USB adapter for the pi to connect the 3.5mm. The cat din is connected to my Atu and it does have an option to fit rig control in but I don’t use that.


thanks
David
David,

how are you expecting CAT control to work if you have no connection to the rig's CAT control port?

73
Bill
G4WJS.


locked Re: #raspberryPi #WSJTX_config #raspberryPi #WSJTX_config

David 2E0HIL <dstgold2@...>
 

Bill 

I am using the 6 pin mini din for the data connection not the cat Din and I am having to use a USB adapter for the pi to connect the 3.5mm. The cat din is connected to my Atu and it does have an option to fit rig control in but I don’t use that. 


thanks 
David 


locked Re: #raspberryPi #WSJTX_config #raspberryPi #WSJTX_config

Bill Somerville
 

On 13/02/2021 22:15, David 2E0HIL wrote:
Bill

I am using the current version 2.3.0
David,

I need some clarification, the FT-897 has two mini-DIN sockets, one for audio in/out and one for CAT, does your interface connect to both of those sockets? The Pi 400 has no audio in connection, where are the 3.5 mm plugs you mention going?

73
Bill
G4WJS.


locked Re: #raspberryPi #WSJTX_config #raspberryPi #WSJTX_config

David 2E0HIL <dstgold2@...>
 

Bill 

I am using the current version 2.3.0


locked Re: #raspberryPi #WSJTX_config #raspberryPi #WSJTX_config

Bill Somerville
 

On 13/02/2021 22:10, David 2E0HIL wrote:
Hi Bill,

The rig is connected using a xggcomms sound card that connects from the 6 pin data plug and then plugs into the pi with a USB and two 3.5mm audio jacks.
David,

which version of WSJT-X are you using?

73
Bill
G4WJS.


locked Re: #raspberryPi #WSJTX_config #raspberryPi #WSJTX_config

David 2E0HIL <dstgold2@...>
 

Hi Bill, 

The rig is connected using a xggcomms sound card that connects from the 6 pin data plug and then plugs into the pi with a USB and two 3.5mm audio jacks. 


locked Re: #raspberryPi #WSJTX_config #raspberryPi #WSJTX_config

Bill Somerville
 

On 13/02/2021 21:00, dstgold2@... wrote:

Hi all hopefully someone can give me tips to go in the right direction.

My issue is that I can’t get my radio to communicate with wsjt-x. When I press test cat it just keeps bringing up errors, the main error is “rig get vfo return while testing current vfo”. My set up is a Yaesu ft897d with a xggcomms sound card to a raspberry pi 400.

I had an issue when I originally set up using windows 10 but that was due to the issues with the 817/897s and I fixed that by selecting a different radio name in settings but that isn’t working this time.


TIA 2E0HIL
David
David,

you have not told us anything about how your rig is connected to you Pi fro CAT control.

73
Bill
G4WJS.


locked Re: #install #install

Bill Somerville
 

On 13/02/2021 18:04, deni wrote:
Having a problem with 2.3.0.  When I attempt to change from FT4 to FT8 the frequency refuses to change.  Even if I change it manually it does not decode.  Note in the attached photo that FT4 is shown, but the correct frequency is not available.  Additionally, the waterfall shows nothing.   Back to 2.2.2 for me.  2.3.0 worked well for about 10 hours before this problem arose.  Seeking advice

73 - deni
WBØTAX
Hi Deni,

whenever new modes are added you must reset the working frequencies table to pick up any changes, "Settings->Frequencies" then right-click the Working Frequencies table body and select "Reset...".

From WSJT v2.3.0 you are no longer able to select the default audio device names, try going to "Settings->Audio" and selecting the actual audio devices that are connected to your rig. It doesn't matter if those devices are set as the default, you can still select them although you should be sure to disable all system sounds and not use other applications that generate sounds while operating WSJT-X.

73
Bill
G4WJS.


locked #raspberryPi #WSJTX_config #raspberryPi #WSJTX_config

dstgold2@...
 

Hi all hopefully someone can give me tips to go in the right direction. 

My issue is that I can’t get my radio to communicate with wsjt-x. When I press test cat it just keeps bringing up errors, the main error is “rig get vfo return while testing current vfo”. My set up is a Yaesu ft897d with a xggcomms sound card to a raspberry pi 400. 

I had an issue when I originally set up using windows 10 but that was due to the issues with the 817/897s and I fixed that by selecting a different radio name in settings but that isn’t working this time. 


TIA 2E0HIL 
David 


locked Re: #Q65 Managing Expectations #Q65

Hasan Schiers N0AN
 

I agree, Chris, it's way too early to button down anything. (and we may end up with different freq for intercontinental DX and the typical random qso water holes) What we have done here, as part of the testing group on 6 meters,  is cluster around 275 for Q65-30a and 235 for 120E. Everything else is by 'arrangement between specific parties.

We chose 275 because the original suggestion of 270 was terribly gobbled up by LAN and Router/WiFi spikes.
There is actually quite a bit of Q65-30A activity every morning, perhaps 7 to 10 stations show up randomly calling CQ, and since we are sitting there, we see the sparkles and the rest ifs history.

We chose 235 because several of us with SDRs could see the entire passband between 225 and 350, noting man-made interference. 235 was in the valley of man-made qrm. We have been running all our 120E tests there, with crazy good results, for the people who have the patience and equipment to use 2 minute T/R sequences.

Have fun testing and as we learn more, will post here.
73, N0AN
Hasan


On Sat, Feb 13, 2021 at 10:50 AM Chris G4IFX <g4ifx@...> wrote:

Hi Hasan, that’s a great summary of the capabilities and potential of Q65, thank you. It’s an exciting mode.

 

Hi Joe, 50.275 is currently in use for Q65 in NA but it’s not such a great choice in Europe because of other activity below 50.300, especially SSB in contests but also with MSK144 around 50.280. In Europe we’re currently using 50.305 for troposcatter and ionoscatter using Q65-30A, but it’s early days and everyone’s still experimenting. There is quite a lot of random 30A activity in EU during the daylight hours, although most of us use the ON4KST chat for talkback so we do tend to know who’s around.

 

As a general point, although it might be a bit too early to button such things down, I think we need to be working towards one or more global frequencies for Q65 in the same way as we have for FT8. The potential is significant for intercontinental contacts with weak scattery signals, outside or on the edges of Es openings or (if we’re lucky enough) by F2/TEP.

 

73

Chris

G4IFX

 

www.uksmg.org

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Joe Dz
Sent: 13 February 2021 15:05
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] #Q65 Managing Expectations

 

Hasan,

 

Excellent summary.  Well written.  As you know from my QST and CQ HamSCI articles, I have used JT65 and then FT8 on 6m to investigate how weather, storms, jet streams and magnetic fields affect transatlantic summer and winter 6m Es-like communications.  Now one of the very nice things about the JT modes are the preselected frequencies, so we have watering holes to meet at, without having to always make schedules ahead of time.  This works very well for FT8 and modes like MSK144 for meteor scatter (although Ping Jockey is a great help there).

 

I seem to me that the new Q65 mode is ideal for doing some HamSCI oriented research on how magnetic fields and solar activity affect ionospheric scatter.  Thus my interest.  Now, just from my experience here in North America, I have the following frequencies/modes for non-EME contacts:

 

50.275  Q65-30A  There is where I find most of the activity.

50.235  Q65-120A

50.305  I have seen this freq on DX Maps.  Are folks here using 30A or something else?

 

Per other emails:

144.170 and 144.120  What are folks using on 2m?  Like 30A on 6m or 60C per the suggestions in the K1JT Q65 getting started notes?

 

I also operate Olivia on the HF bands, and watering holes are pretty critical there, because like some Q65 QSOs, there can be good signal copy using Olivia when nothing shows on the waterfall.

 

If we can establish watering hole frequencies and mode, then I think Q65 can be used for some good ionosphere research like FT8 was and is being used.

 

Joe, K1YOW

 


From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Hasan Schiers N0AN
Sent: Saturday, February 13, 2021 9:22 AM
To: main@WSJTX.groups.io Notification
Subject: Re: [WSJTX] #Q65 Managing Expectations

 

Managing Expectations is a very good title!

 

 

1. Q65-15A is not FT8. If you are in a hurry Q65 modes are not for you, unless there is significant enhancement of band conditions. Then Q65-15A is fast and works very well, but not in crowded band conditions

 

2. Q65-30A is NOT MSK144. If there is a plenitude of meteors, MSK144 is MUCH faster to complete a QSO

 

3. On 6 meters, if there are a lot of meteors , FT8 is not a good mode, as they kill FT8 decodes.

 

On 6m, what is Q65 good for and why would anyone want to run it?

 

a. Q65-30A and other Q65 modes are FAR more sensitive  than MSK144 and other digital modes.

 

b. They do not not require meteors for 24x7, but  can take advantage of them, if they are present.

 

In its present form, Q65 is not Plug and Play. It requires some learning and some fine tuning to get peak performance out of it.

 

Months of experimenting with early versions of the Q65 series has demonstrated the following:

 

Without band enhancement like sporadic E, meteor trails or Tropo Ducting, it is NOT typically a Random Mode. Getting on and calling CQ hoping for a QSO will not yield the same results as MSK144, until and unless operator density increases dramatically. The high performance levels listed below are based on scheduling a qso with a partner.

 

1. Well equipped stations running 100W to yagis with low local ambient noise can work consistently 1000 miles at the best time of day. Further, with 700w  or more, they can consistently work 1000 miles at ANY time of day. (Using 6m mode Q65-30A)

 

2. Well equipped stations running < 100w to yagis, with low local ambient noise can EASILY work 1100 miles using mode 120E on 6 meters.

 

Using a 5 EL LFA @ 60' fed with 1/2" hardline:

 

I  work K1JT nearly every morning at 1000 miles, running 600W out using Q65-30A.

Not just worked, but decoded 90% of available sequences for 15 to 30 minutes at a time. (and I have considerable noise in that direction)

 

I also have worked, day after day after day, W7OUU at a distance of 1070 miles, running less than 20w output on 6 meters , over a 15 to 30 minute period of running Mode 120E (two minute transmit / receive time)

 

We would simply disable autoseq and transmit the same thing over and over again. (Count how many decodes were successful vs how many transmissions were made.)

 

If you are not able to get the results documented and replicated as noted above, it is not the fault of the mode. Something else is wrong.

 

Causes include: (but are  not limited to)

 

1. High local ambient noise. Many people I talk to and work have no idea how bad their local noise level is on 6 meters, because they have never measured it. I consistently see certain stations 8 to 15 dB down on their receive side, who originally said, 'my noise is low' . Measurements show just the opposite.

 

2. Not using the right power level, Q65 mode and mode settings for the path in question.

 

Setting realistic expectations for the Q65 suite of modes involves study, practice and patience. 

 

It is not JT65, it is not QRA64, it is not FT8 , it is not MSK144. It is not point and shoot. It typically requires scheduling, and it always requires patience. 

 

If you are looking for instant gratification, the Q65 suite of modes is not for you.

 

It is new. It is quite different in how it works and how it needs to be set up.

 

Properly configured it is amazing, assuming your station is up to it, including noise levels at both ends of the path.

 

FT8 is largely dependent on Sporadic E, which is often super efficient and acts like a mirror. Making reliable contacts when Es is booming is very easy and quite fast. Q65 was not designed to take the place of FT8 in these conditions, although Q65-15A would be very good.

 

The q65 modes were designed for Ionoscatter and EME. Ionoscatter occurs 24 hours per day, 7 days per week. I call them the 'no waiting' modes on 6 meters.

 

While Q65 can take advantage of all these other propagation modes, (Es, Troposcatter, Tropo-ducting, Meteor Trails, etc)  it is certainly not necessarily better at  decoding signals on those  other modes than software specifically designed to take advantage of a specific mode of propagation (like MSK144 for meteor scatter)

 

Used in the proper way, and set up properly, Q65 is borderline magic. As a drop-in replacement for the commonly used modes of the present, it is bound to disappoint.

 

Manage expectations accordingly.

 

73, N0AN

Hasan

 

 

On Sat, Feb 13, 2021 at 6:56 AM Christoph Petermann <mail01@...> wrote:

Good morning,
I must admit, for the very first "shot" of Q65 it works great. Can't wait for improvements...
Its" lockdown-time" and what else can you do : This week I ran my "personal testseries" with some stations on 6m and 2m and compared it with the "known modes" My first impression is, that under marginal conditions, where the signal was barely visible in the waterfall, I got lot better results than with FT8. But there are not yet so many stations being QRV in Q65 at the same time. It is early in the year and the season yet to come.
The mode Q65_60C outperformed JT65A each time of my 7 tests. Next week I will have the chance to try it on 23cm EME.
So, keep up the fine work.
73 de Christoph (DF9CY)





locked Re: #Cat_RigControl #mac #Cat_RigControl #macOS

smith.rip@...
 

Hello Kell,

The only thing I see in your setting is the Transmit Audio Source. I have always set it on Rear/Data. This makes sense because your transmit data is being generated by the computer and sent to the readio via the USB cable. At least that is the way I understand it.

Hope this helps ...

Other than that your settings are the same as mine (except, of course, a different radio and driver) and I keep getting the error message. Even letting it sit ovenight didn't fix the problem. :-{

--
73, Rip K3XO


locked Re: #Cat_RigControl #mac #Cat_RigControl #macOS

Jim Bennett <w6jhb@...>
 

Here is what works fine for me:



Jim Bennett
Folsom, CA

K7TXA (ex W6JHB as of 1/22/2021)

Being retired doesn't mean I'm not part of the work force - just that I'm not forced to work!



On Feb 13, 2021, at 7:42 AM, Kell / KI7UXT <Kbodholt@...> wrote:

[Edited Message Follows]

I'm a complete newbie to WSJT-X and just installed it recently and thought I would share my settings.  On the radio tab, CAT Control/Serial Port, I had to use the /dev/tty.usbmodem1421201 from the drop down.  I was not able to get the "Test Cat" button to turn green with the /dev/cu options from the drop down.  I do not know what the difference b/w tty and cu.  I am using a 2019 MacBook Pro, macOS Big Sur v11.2.1. Everything appears to be working as far as I can tell, except for Tx'ing, I am not getting much power out per the 705's power meter screen.  I suspect that the USB cable I am using could be the problem and likely is not shielded very well.  I've gone through the process of setting the USB sound card input/output settings, but still not getting the full 5w out of the 705.  I have some ferrites on order for the USB cable to see if that makes any difference.

Does anyone have a link to a good quality, shielded USB cable they can share?

Also, if anyone sees any settings in my WSJT-X that should be changed, please comment:

<Screen Shot 2021-02-13 at 7.25.52 AM.png>

<Screen Shot 2021-02-13 at 7.26.06 AM.png><Screen Shot 2021-02-13 at 7.26.16 AM.png> <Screen Shot 2021-02-13 at 7.26.16 AM.png><Screen Shot 2021-02-13 at 7.26.06 AM.png><Screen Shot 2021-02-13 at 7.25.52 AM.png>




locked Re: #Q65 Managing Expectations #Q65

Brian Bowers G0VAX
 

50.305.... I’ll give that a go

Brian Bowers. VR AweldI

From: main@WSJTX.groups.io <main@WSJTX.groups.io> on behalf of David Ackrill <david.ackrill@...>
Sent: Saturday, February 13, 2021 4:59:56 PM
To: main@WSJTX.groups.io <main@WSJTX.groups.io>
Subject: Re: [WSJTX] #Q65 Managing Expectations
 
On Sat, Feb 13, 2021 at 08:03 AM, Joe Dz wrote:
50.305  I have seen this freq on DX Maps.  Are folks here using 30A or something else?
In Europe 50.275MHz is not ideal as it is in the section marked in the Region 1 Bandplan as
50.200-50.300 2.7 kHz SSB/Telegraphy - General Usage


50.305MHz is marked as "50.305 MHz   PSK Centre of Activity" in the MGM/Narrowband/Telegraphy section for the 6M band, but there isn't much PSK being used on 50MHz, it seems, these days.

Eventually, I guess there will be an agreed Q65 area or maybe people will decide that another frequency should be used but, for now, people are trying out Q65 (mainly 30A) on 50.305MHz in Europe.

Cheers - Dave (G0DJA)


locked Re: #Cat_RigControl #Cat_RigControl

RVnRadio <k7txoradio@...>
 

I will add to the response "It sounds like more than one program is trying to access the same port", except my suffix will be "for sure" instead of maybe.  At least that is my assessment. here is what I do, which I think is just a bigger version of what your trying to accomplish.

I run WSJT-X, DXLab Commander (multi-rig CAT controller program and use a RIGblaster Advantage for sound, and for CW/FSK PTT control with my TS-590SG, all through one USB physical port.  I setup VSPE Serial port emulator (freeware but 64 bit version is reasonable price) running to provide a port Splitter device configured to take the COM port my radio claims in Device Manager, and splits it to add a virtual COM port. My WSJT-X program is configured to use this particular virtual COM port number.  As for PTT control, I have WSKJT-X set to use VOX, with my RB Advantage switch-selected to VOX, TX control.  Works like a peach.

Besides WSJT-X, I use a number of other ham software programs.  I also have  DXLab Commander multirig CAT control for two radios.  I chose to use one of these two radios with all of my software programs.  The Multirig tab in Commander needed that radio to also change from the physical COM port number, to the same Virtual COM port number.  Some of these programs needed some additional control signals like FSK for RTTY as well as PTT control needed by WSJT-X.  For that, I have another serial port utility provided by WEST MOUNTAIN with the RB Advantage with it's "Port Split",that provides that PTT control, or I can use VOX control. Yeah, it gets a bit deep in my case.

Not that its important to this thread but I also have an IC-7300 tied into DXLab Commander as a secondary radio.  Everything the TS-590SG does for Band, Freq and Mode changes, the 7300 follows which is of course connected to the PC with its own physical USB cable and COM port.   If I change Band, Freq and Mode on the 7300, even using the touch screen on its band scope, the 590SG follows those commands.  The Commander program ties these radios together for Band, Freq and Mode interaction while at the same time, VSPE and WM Port Split provide the other software programs the ability to work with the 590SG which is my choice to use as the tranciever.  7300 doesn't meet my demands for a transceiver.  I instead use it mostly as a sound-muted secondary receiver, either in sync with, or separated from the 590. With some mechanical switching and RF isolation, this secondary receiver meets my needs for having a band scope for the 590SG that is either totally in sync, and using the same antenna.  Or I can put the 7300 on a different antenna for diversity reception.  Or I can stop CAT program interaction so that I can roam bands, modes and frequencies independently.  In other words, my TS-590SG effectively has a built in 2nd receiver and a band scope via software control and some switching. All of this while multiple software programs co-exist to allow me to log, operate digital modes including AFSK or FSK (the  latter because of the RB Advantage), use the 7300's TTY decoder, use the band scope for the 590 or independent of the 590. Just about anything a dual receiver built into one more expensive rig can do, or a TS-890S linked to a TS-590SG.

The point here is while my setup is a more complex version of what your presently trying to do. Same thing though;
This is just like two, or more cars traveling in the same lane in the same direction, and never colliding with each other.
And then another lane in the opposite direction with cars also not wrecking.   

I will admit it was a brain twister for me to get all of the software programs configured to play nice on the inbound and outbound freeway lanes.  I humbly approached WEST MOUNTAIN support for some help because a lot of this involved their RB device.  A particular support guy with WM was incredibly helpful for me.  I imagine MICROHAM can lend a hand if you purchased your micro KEYER III new from then.  I think your interface needs are fundamentally similar to my RB even though my RB is phsyically connected to my PC on a separate physical USB cable & port, but yours has lot more functions and features. Ask their support about what your trying to do with one program on the same USB physical port line as your micro KEYER III & radio are connected via "passthru", or daisy chained cabling.  

Meanwhile, you have command and data whizzing duplex between the radio and the computer and then when a program is launched its like stacking two cars in the same spot in one direction and two more cars on top of each other in the other direction.  You just need to space the cars in these two lanes so that the data/commands come and go to their destinations without running into each other.

I would suggest copy/pasting this reply text into Word or other document to have on the table.  maybe underline or highlight somethings unless this info just doesn't fit your issue at all.

Gene / K7TXO


locked #install #install

deni
 

Having a problem with 2.3.0.  When I attempt to change from FT4 to FT8 the frequency refuses to change.  Even if I change it manually it does not decode.  Note in the attached photo that FT4 is shown, but the correct frequency is not available.  Additionally, the waterfall shows nothing.   Back to 2.2.2 for me.  2.3.0 worked well for about 10 hours before this problem arose.  Seeking advice

73 - deni
WBØTAX


locked Re: V 2.3.0 - Empty Band Activity #FT8

TrueDeviL (G7WFC) <realtruedevil@...>
 

I do have that option checked, as I said in the video, I don't remember having this issue in 2.2.2, maybe I was just lucky.. I'll un-check it and see how it goes..

Thanks for the suggestion :)
__________
TrueDeviL - Richard - G7WFC
YouTube - Twitch


locked Re: #Q65 Managing Expectations #Q65

David Ackrill
 

On Sat, Feb 13, 2021 at 08:03 AM, Joe Dz wrote:
50.305  I have seen this freq on DX Maps.  Are folks here using 30A or something else?
In Europe 50.275MHz is not ideal as it is in the section marked in the Region 1 Bandplan as
50.200-50.300 2.7 kHz SSB/Telegraphy - General Usage


50.305MHz is marked as "50.305 MHz   PSK Centre of Activity" in the MGM/Narrowband/Telegraphy section for the 6M band, but there isn't much PSK being used on 50MHz, it seems, these days.

Eventually, I guess there will be an agreed Q65 area or maybe people will decide that another frequency should be used but, for now, people are trying out Q65 (mainly 30A) on 50.305MHz in Europe.

Cheers - Dave (G0DJA)


locked Re: V 2.3.0 - Empty Band Activity #FT8

Bill Somerville
 

On 10/02/2021 16:16, TrueDeviL via groups.io wrote:
Hi, Upgraded to 2.3.0 last night, which I had a nightmare to get working, as the instructions for a 'straight upgrade' didn't work..

Had 2.2.2 installed, installed 2.3.0 as per instructions, It then just failed to connect to Omnirig, un-installed, put 2.2.2 back, now that had the same issue (it was all working beforehand)..

After uninstalling again, then doing a registry clean, and 5+ more re-installs, finally it's working... to a point...

My Band Activity, goes completely blank on an update.. it scrolls up too far, like it's adding blank lines or something.. It's not got to the point, it practically un-usable, as it's blank the 100% of the time..

I scroll up to the last data that came in, and the second something new comes in, it goes blank again (scrolls up too far..)

Suggestions? or is it a bug?
Hi Rich,

do you have the "Settings->General->Start new period decodes at top" option checked? If you do then you should be aware that there is a long standing known issue, after many decodes have been printed the "Band Activity" window fails to scroll correctly and new decodes are scrolled off the top. They are still available, you would have to scroll down the window to see them. To avoid the issue you can either uncheck that option, or you can periodically erase the Band Activity periodically before the issue arises.

73
Bill
G4WJS.


locked Re: #Q65 Managing Expectations #Q65

Chris G4IFX
 

Hi Hasan, that’s a great summary of the capabilities and potential of Q65, thank you. It’s an exciting mode.

 

Hi Joe, 50.275 is currently in use for Q65 in NA but it’s not such a great choice in Europe because of other activity below 50.300, especially SSB in contests but also with MSK144 around 50.280. In Europe we’re currently using 50.305 for troposcatter and ionoscatter using Q65-30A, but it’s early days and everyone’s still experimenting. There is quite a lot of random 30A activity in EU during the daylight hours, although most of us use the ON4KST chat for talkback so we do tend to know who’s around.

 

As a general point, although it might be a bit too early to button such things down, I think we need to be working towards one or more global frequencies for Q65 in the same way as we have for FT8. The potential is significant for intercontinental contacts with weak scattery signals, outside or on the edges of Es openings or (if we’re lucky enough) by F2/TEP.

 

73

Chris

G4IFX

 

www.uksmg.org

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Joe Dz
Sent: 13 February 2021 15:05
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] #Q65 Managing Expectations

 

Hasan,

 

Excellent summary.  Well written.  As you know from my QST and CQ HamSCI articles, I have used JT65 and then FT8 on 6m to investigate how weather, storms, jet streams and magnetic fields affect transatlantic summer and winter 6m Es-like communications.  Now one of the very nice things about the JT modes are the preselected frequencies, so we have watering holes to meet at, without having to always make schedules ahead of time.  This works very well for FT8 and modes like MSK144 for meteor scatter (although Ping Jockey is a great help there).

 

I seem to me that the new Q65 mode is ideal for doing some HamSCI oriented research on how magnetic fields and solar activity affect ionospheric scatter.  Thus my interest.  Now, just from my experience here in North America, I have the following frequencies/modes for non-EME contacts:

 

50.275  Q65-30A  There is where I find most of the activity.

50.235  Q65-120A

50.305  I have seen this freq on DX Maps.  Are folks here using 30A or something else?

 

Per other emails:

144.170 and 144.120  What are folks using on 2m?  Like 30A on 6m or 60C per the suggestions in the K1JT Q65 getting started notes?

 

I also operate Olivia on the HF bands, and watering holes are pretty critical there, because like some Q65 QSOs, there can be good signal copy using Olivia when nothing shows on the waterfall.

 

If we can establish watering hole frequencies and mode, then I think Q65 can be used for some good ionosphere research like FT8 was and is being used.

 

Joe, K1YOW

 


From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Hasan Schiers N0AN
Sent: Saturday, February 13, 2021 9:22 AM
To: main@WSJTX.groups.io Notification
Subject: Re: [WSJTX] #Q65 Managing Expectations

 

Managing Expectations is a very good title!

 

 

1. Q65-15A is not FT8. If you are in a hurry Q65 modes are not for you, unless there is significant enhancement of band conditions. Then Q65-15A is fast and works very well, but not in crowded band conditions

 

2. Q65-30A is NOT MSK144. If there is a plenitude of meteors, MSK144 is MUCH faster to complete a QSO

 

3. On 6 meters, if there are a lot of meteors , FT8 is not a good mode, as they kill FT8 decodes.

 

On 6m, what is Q65 good for and why would anyone want to run it?

 

a. Q65-30A and other Q65 modes are FAR more sensitive  than MSK144 and other digital modes.

 

b. They do not not require meteors for 24x7, but  can take advantage of them, if they are present.

 

In its present form, Q65 is not Plug and Play. It requires some learning and some fine tuning to get peak performance out of it.

 

Months of experimenting with early versions of the Q65 series has demonstrated the following:

 

Without band enhancement like sporadic E, meteor trails or Tropo Ducting, it is NOT typically a Random Mode. Getting on and calling CQ hoping for a QSO will not yield the same results as MSK144, until and unless operator density increases dramatically. The high performance levels listed below are based on scheduling a qso with a partner.

 

1. Well equipped stations running 100W to yagis with low local ambient noise can work consistently 1000 miles at the best time of day. Further, with 700w  or more, they can consistently work 1000 miles at ANY time of day. (Using 6m mode Q65-30A)

 

2. Well equipped stations running < 100w to yagis, with low local ambient noise can EASILY work 1100 miles using mode 120E on 6 meters.

 

Using a 5 EL LFA @ 60' fed with 1/2" hardline:

 

I  work K1JT nearly every morning at 1000 miles, running 600W out using Q65-30A.

Not just worked, but decoded 90% of available sequences for 15 to 30 minutes at a time. (and I have considerable noise in that direction)

 

I also have worked, day after day after day, W7OUU at a distance of 1070 miles, running less than 20w output on 6 meters , over a 15 to 30 minute period of running Mode 120E (two minute transmit / receive time)

 

We would simply disable autoseq and transmit the same thing over and over again. (Count how many decodes were successful vs how many transmissions were made.)

 

If you are not able to get the results documented and replicated as noted above, it is not the fault of the mode. Something else is wrong.

 

Causes include: (but are  not limited to)

 

1. High local ambient noise. Many people I talk to and work have no idea how bad their local noise level is on 6 meters, because they have never measured it. I consistently see certain stations 8 to 15 dB down on their receive side, who originally said, 'my noise is low' . Measurements show just the opposite.

 

2. Not using the right power level, Q65 mode and mode settings for the path in question.

 

Setting realistic expectations for the Q65 suite of modes involves study, practice and patience. 

 

It is not JT65, it is not QRA64, it is not FT8 , it is not MSK144. It is not point and shoot. It typically requires scheduling, and it always requires patience. 

 

If you are looking for instant gratification, the Q65 suite of modes is not for you.

 

It is new. It is quite different in how it works and how it needs to be set up.

 

Properly configured it is amazing, assuming your station is up to it, including noise levels at both ends of the path.

 

FT8 is largely dependent on Sporadic E, which is often super efficient and acts like a mirror. Making reliable contacts when Es is booming is very easy and quite fast. Q65 was not designed to take the place of FT8 in these conditions, although Q65-15A would be very good.

 

The q65 modes were designed for Ionoscatter and EME. Ionoscatter occurs 24 hours per day, 7 days per week. I call them the 'no waiting' modes on 6 meters.

 

While Q65 can take advantage of all these other propagation modes, (Es, Troposcatter, Tropo-ducting, Meteor Trails, etc)  it is certainly not necessarily better at  decoding signals on those  other modes than software specifically designed to take advantage of a specific mode of propagation (like MSK144 for meteor scatter)

 

Used in the proper way, and set up properly, Q65 is borderline magic. As a drop-in replacement for the commonly used modes of the present, it is bound to disappoint.

 

Manage expectations accordingly.

 

73, N0AN

Hasan

 

 

On Sat, Feb 13, 2021 at 6:56 AM Christoph Petermann <mail01@...> wrote:

Good morning,
I must admit, for the very first "shot" of Q65 it works great. Can't wait for improvements...
Its" lockdown-time" and what else can you do : This week I ran my "personal testseries" with some stations on 6m and 2m and compared it with the "known modes" My first impression is, that under marginal conditions, where the signal was barely visible in the waterfall, I got lot better results than with FT8. But there are not yet so many stations being QRV in Q65 at the same time. It is early in the year and the season yet to come.
The mode Q65_60C outperformed JT65A each time of my 7 tests. Next week I will have the chance to try it on 23cm EME.
So, keep up the fine work.
73 de Christoph (DF9CY)


locked Re: Lost audio #AudioIssues

Dave Garber
 

Check their website.   They may have support


On Fri., Feb. 12, 2021, 5:34 p.m. Dennis Jacobson, <n6ngdennis@...> wrote:
I looked and looked but I can't seem to find a RigBlaster forum.. Does anyone know where that one is?
Thanks all Dennis N6NG


17761 - 17780 of 39792