Date   

Auto-update v4.0.279 is now on-line ...

Bob
 

In this version, there is a change to the way Country/call alerts are processed. As an example, I will use the recent 3DA0 operations. Assume I do not like FT4/8, and I have blocked all DX Spots on FT4/8. I need 3DA0 for a new Country, and would even try an FT8 contact with them. If I turn off DX Spot blocking I will be buried in an avalanche of FT4/8 DX Spots that I don't need/want to see. Here is the solution to the problem - Leave FT4/8 blocking in place. Add 3DA0 to the list of Country/call alerts. Now, if there is a DX Spot, even an FT8 DX Spot, for 3DA0 it will show in the DX Spot Window and on the BandMaps is the high priority highlight color you have chosen. 73.


Re: Problem with a log with a large number of QSOs ?

Bob
 

Try the 'Quick QSL' window. That way you can change any/all QSL Sent/Rcvd flags in a single edit. Or, if you right click on the QSO in the Logbook pagr window, then click the Edit QSL info menu, there is another window that allows you to edit many fields in a single edit. SeventyThree(s).

On 10/18/2021 7:58 AM Aleksander Žagar <s57s@...> wrote:
 
 
Alain F5LMJ via groups.io je 18.10.2021 ob 10:58 napisal:
Hi to the group, 

Using Logger32 v4.0.278, my log contains almost 200,000 QSOs and I have a problem when I manually update the log to add some infos to a QSO.
After entering the 1st field to update, I can go to the next field to enter another info, but even if I can start entering text on the keyboard, the first 2 or 3 characters are not taken into account ( as if the update of the 1st field was not finished and did not take into account the next entry until ending ).
The computer has enough memory (16 Gb) and the log is on an SSD disk so I don't think it comes from my computer setup
For those who have a log with a large number of QSO, do you also have this issue ?

73's Alain F5LMJ

Yes Alain, the same here. It takes sometimes nearly 40 sec or so to jump from QSL send Y  to QSL received Y.

I have 195625 QSOs large logbook. It is a little better on another brend-new comp but still slow.

73, Aleksander, S57S




Avast logo

Ta e-pošta je bila pregledana z Avast protivirusnim programom.
www.avast.com


Re: Problem with a log with a large number of QSOs ?

Aleksander Žagar
 

Alain F5LMJ via groups.io je 18.10.2021 ob 10:58 napisal:
Hi to the group, 

Using Logger32 v4.0.278, my log contains almost 200,000 QSOs and I have a problem when I manually update the log to add some infos to a QSO.
After entering the 1st field to update, I can go to the next field to enter another info, but even if I can start entering text on the keyboard, the first 2 or 3 characters are not taken into account ( as if the update of the 1st field was not finished and did not take into account the next entry until ending ).
The computer has enough memory (16 Gb) and the log is on an SSD disk so I don't think it comes from my computer setup
For those who have a log with a large number of QSO, do you also have this issue ?

73's Alain F5LMJ

Yes Alain, the same here. It takes sometimes nearly 40 sec or so to jump from QSL send Y  to QSL received Y.

I have 195625 QSOs large logbook. It is a little better on another brend-new comp but still slow.

73, Aleksander, S57S




Avast logo

Ta e-pošta je bila pregledana z Avast protivirusnim programom.
www.avast.com



Problem with a log with a large number of QSOs ?

Alain F5LMJ
 

Hi to the group, 

Using Logger32 v4.0.278, my log contains almost 200,000 QSOs and I have a problem when I manually update the log to add some infos to a QSO.
After entering the 1st field to update, I can go to the next field to enter another info, but even if I can start entering text on the keyboard, the first 2 or 3 characters are not taken into account ( as if the update of the 1st field was not finished and did not take into account the next entry until ending ).
The computer has enough memory (16 Gb) and the log is on an SSD disk so I don't think it comes from my computer setup
For those who have a log with a large number of QSO, do you also have this issue ?

73's Alain F5LMJ


Σχετ: Re: [hamlogger] connect logger32 to yaesu g1000

Kostas
 

Hi Rodrigo 
Thaks for answer but after a log search we found the problem, I had to choose mode 
And now it's OK 

Tnx 
Sv2hjw

Στις Δευ, 18 Οκτ, 2021 στις 0:59, ο χρήστηςRodrigo
<ct1bxt@...> έγραψε:
Hi Kostas,

I have a g-2800xc working with logger32 and also pstrotator.
What kind of assistance do you need ?

73´s
Rodrigo
ct1bxt


Re: RTTY

Jan
 

Well said Tom.
I still remember the old days when there were no computers and we had to do RTTY contests on the Creed or Siemens machines using the punched paper tapes as what now is called macro's. 😁

73
Jan
PA4JJ

Op 18-10-2021 om 00:13 schreef Tom Wylie:
I agree about the rtty exchanges Mike, and I think protocols are getting worse.  I spent a few hours yesterday and today in the JARTS they and I sensed an OH station was irritated at me.  He sent GM4FDM (559) 599 (339) then his number ONCE which just faded into the noise.   It took me about five AGN AGN NR NR before the qsb allowed me to get it.  If he was hoping to shave a few milliseconds off our qso he was mistaken and it probably took three times as long as it should have.  Such is life. We all seem to have to go faster, harder, quicker, sooner, most of the time just to stand still......

73
Tom
GM4FDM

On 17 October 2021, at 23:00, "Michael Harris via groups.io" <mike.harris@...> wrote:

Never noticed any delay. However, I only S&P to hand out points/mults 
and maybe fill a "slot" or two that I need.

I haven't noticed any delay when running a pile and that must be pretty 
close to contest working.

The biggest issue I have with RTTY contests are the many variations of 
an exchange. It can be a problem to determine who is calling who. That 
is why my macros include the call of the station I'm calling/working.

Whatever, that is all the skin I'm offering.

Regards,

Mike VP8NO


On 17/10/2021 18:33, Tom Wylie wrote:
It might change to receive immediately mike, but it takes logger longer than a contest logger, to log the contact and clear the fields for the next qso, it's too slow......


Tom

On 17 October 2021, at 22:18, "Michael Harris via groups.io" <mike.harris@...> wrote:

Hi,

For what its worth. I have just tried a contest exchange macro in MMVARI:

$transmit$ $starttime$
DE $mycall$ 599 $serialnum$ $serialnum$ TU
$receive$ $endtime$ $log$

The K3 changes to RX immediately. An oddity I notice with MMVARI is at
the start of a transmission there is about a seconds worth of diddles
before the "message" is transmitted.

I normally use MMTTY along with 2Tone and GRITTY as additional decoders.

$transmit$ $starttime$
$call$ 599 13 13 $mycall$ $receive$ $endtime$ $log$

Changes to receive immediately.

If I call CQ it normally grows into a pileup and I use the following:

$transmit$ $starttime$
$call$ $call$ 599 $mycall$
$receive$

$transmit$
$call$ tu $mycall$ $endtime$ $log$  up 1-3
$receive$

What happens if you use a macro that doesn't log i.e. a previous serial
number?

$transmit$
599 $serialnum-1$ $serialnum-1$ $receive$

Again these change to RX immediately. I backup the log every five contacts.

Regards,

Mike VP8NO










-- 
____________________________________________________
my dxspider clusters running on a raspberry pi zero:  
pa4jj-2 83.162.186.242 port 7300
pa4jj-3 83.162.186.242 port 7388


Re: RTTY

Tom Wylie
 

I agree about the rtty exchanges Mike, and I think protocols are getting worse. I spent a few hours yesterday and today in the JARTS they and I sensed an OH station was irritated at me. He sent GM4FDM (559) 599 (339) then his number ONCE which just faded into the noise. It took me about five AGN AGN NR NR before the qsb allowed me to get it. If he was hoping to shave a few milliseconds off our qso he was mistaken and it probably took three times as long as it should have. Such is life. We all seem to have to go faster, harder, quicker, sooner, most of the time just to stand still......

73
Tom
GM4FDM

On 17 October 2021, at 23:00, "Michael Harris via groups.io" <mike.harris=horizon.co.fk@groups.io> wrote:

Never noticed any delay. However, I only S&P to hand out points/mults
and maybe fill a "slot" or two that I need.

I haven't noticed any delay when running a pile and that must be pretty
close to contest working.

The biggest issue I have with RTTY contests are the many variations of
an exchange. It can be a problem to determine who is calling who. That
is why my macros include the call of the station I'm calling/working.

Whatever, that is all the skin I'm offering.

Regards,

Mike VP8NO


On 17/10/2021 18:33, Tom Wylie wrote:
It might change to receive immediately mike, but it takes logger longer than a contest logger, to log the contact and clear the fields for the next qso, it's too slow......


Tom

On 17 October 2021, at 22:18, "Michael Harris via groups.io" <mike.harris=horizon.co.fk@groups.io> wrote:

Hi,

For what its worth. I have just tried a contest exchange macro in MMVARI:

$transmit$ $starttime$
DE $mycall$ 599 $serialnum$ $serialnum$ TU
$receive$ $endtime$ $log$

The K3 changes to RX immediately. An oddity I notice with MMVARI is at
the start of a transmission there is about a seconds worth of diddles
before the "message" is transmitted.

I normally use MMTTY along with 2Tone and GRITTY as additional decoders.

$transmit$ $starttime$
$call$ 599 13 13 $mycall$ $receive$ $endtime$ $log$

Changes to receive immediately.

If I call CQ it normally grows into a pileup and I use the following:

$transmit$ $starttime$
$call$ $call$ 599 $mycall$
$receive$

$transmit$
$call$ tu $mycall$ $endtime$ $log$ up 1-3
$receive$

What happens if you use a macro that doesn't log i.e. a previous serial
number?

$transmit$
599 $serialnum-1$ $serialnum-1$ $receive$

Again these change to RX immediately. I backup the log every five contacts.

Regards,

Mike VP8NO


Re: RTTY

Michael Harris
 

Never noticed any delay. However, I only S&P to hand out points/mults and maybe fill a "slot" or two that I need.

I haven't noticed any delay when running a pile and that must be pretty close to contest working.

The biggest issue I have with RTTY contests are the many variations of an exchange. It can be a problem to determine who is calling who. That is why my macros include the call of the station I'm calling/working.

Whatever, that is all the skin I'm offering.

Regards,

Mike VP8NO

On 17/10/2021 18:33, Tom Wylie wrote:
It might change to receive immediately mike, but it takes logger longer than a contest logger, to log the contact and clear the fields for the next qso, it's too slow......
Tom
On 17 October 2021, at 22:18, "Michael Harris via groups.io" <mike.harris=horizon.co.fk@groups.io> wrote:
Hi,
For what its worth. I have just tried a contest exchange macro in MMVARI:
$transmit$ $starttime$
DE $mycall$ 599 $serialnum$ $serialnum$ TU
$receive$ $endtime$ $log$
The K3 changes to RX immediately. An oddity I notice with MMVARI is at
the start of a transmission there is about a seconds worth of diddles
before the "message" is transmitted.
I normally use MMTTY along with 2Tone and GRITTY as additional decoders.
$transmit$ $starttime$
$call$ 599 13 13 $mycall$ $receive$ $endtime$ $log$
Changes to receive immediately.
If I call CQ it normally grows into a pileup and I use the following:
$transmit$ $starttime$
$call$ $call$ 599 $mycall$
$receive$
$transmit$
$call$ tu $mycall$ $endtime$ $log$ up 1-3
$receive$
What happens if you use a macro that doesn't log i.e. a previous serial
number?
$transmit$
599 $serialnum-1$ $serialnum-1$ $receive$
Again these change to RX immediately. I backup the log every five contacts.
Regards,
Mike VP8NO


Re: connect logger32 to yaesu g1000

Rodrigo
 

Hi Kostas,

I have a g-2800xc working with logger32 and also pstrotator.
What kind of assistance do you need ?

73´s
Rodrigo
ct1bxt


Re: RTTY

Tom Wylie
 

It might change to receive immediately mike, but it takes logger longer than a contest logger, to log the contact and clear the fields for the next qso, it's too slow......


Tom

On 17 October 2021, at 22:18, "Michael Harris via groups.io" <mike.harris=horizon.co.fk@groups.io> wrote:

Hi,

For what its worth. I have just tried a contest exchange macro in MMVARI:

$transmit$ $starttime$
DE $mycall$ 599 $serialnum$ $serialnum$ TU
$receive$ $endtime$ $log$

The K3 changes to RX immediately. An oddity I notice with MMVARI is at
the start of a transmission there is about a seconds worth of diddles
before the "message" is transmitted.

I normally use MMTTY along with 2Tone and GRITTY as additional decoders.

$transmit$ $starttime$
$call$ 599 13 13 $mycall$ $receive$ $endtime$ $log$

Changes to receive immediately.

If I call CQ it normally grows into a pileup and I use the following:

$transmit$ $starttime$
$call$ $call$ 599 $mycall$
$receive$

$transmit$
$call$ tu $mycall$ $endtime$ $log$ up 1-3
$receive$

What happens if you use a macro that doesn't log i.e. a previous serial
number?

$transmit$
599 $serialnum-1$ $serialnum-1$ $receive$

Again these change to RX immediately. I backup the log every five contacts.

Regards,

Mike VP8NO


Re: RTTY

Tom Wylie
 

Guess you must still be chopping down trees with an axe Dave, gets the job done, but a chainsaw is faster.

Tom
GM4FDM



On 17 October 2021, at 22:16, Dave Colliau <n8dc-8@...> wrote:


Duh :)
Dave N8DC
On 10/17/2021 5:00 PM Tom Wylie <thomasgwylie@...> wrote:
 
 
Logger is not a contest programme, if you want something faster use wintest or N1MM which are dedicated contest programmes, then you can import your log directly into logger.   No point in trying to re-invent the wheel. Horses for courses.
 
Tom
GM4FDM 

On Sun, 17 Oct 2021, 21:57 g4girhb0 via groups.io, <ian.frith= ntlworld.com@groups.io> wrote:
Tried this suggestion Bob, but still getting the delay when the tones/tx have stopped.
 
73
 
Ian
 
----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
Sent: 17/10/2021 20:16:14
Subject: Re: [hamlogger] RTTY

Try:
 
$log$$call$ CFM $srx$ TU QRZ? de $mycall$$receive$
$call$ CFM $srx$ TU QRZ? de $mycall$$receive$$log$
 
In both cases I have removed an unwanted space from being transmitted before switching to receive. Other than that, the macros are correct, and the QSO is actually logged after the radio command to switch to receive is sent. If you are using PTT by radio command the faster the radio polling is the quicker it'll switch. SeventyThree(s).
On 10/17/2021 2:58 PM Fabio IZ8MBW via groups.io <iz8mbw= yahoo.it@groups.io> wrote:
 
 
These are two examples of Macros:
 
$log$$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$
 
 
 
$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$$log$
 
 
I don't think the problem is specific on the macros (I have tried various combinations), I think the problem is Logger32/MMVARI that during the time spent to put the QSO in the Logbook is "not able" to speedily stop the transmission.
As you can see from the video ( https://www.iz8mbw.net/mmvari.mp4) until the QSO is not in log, there is not any switch to RX (and the radio is still transmitting no text because there is no more text to send).
 
 
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 08:41:03 PM GMT+2, Bob < k4cy@...> wrote:
 
 
Please share with us the macro you use that makes it impossible to use in a contest. SeventyThree(s).
On 10/17/2021 2:27 PM Fabio IZ8MBW via groups.io <iz8mbw= yahoo.it@groups.io> wrote:
 
 
This is an old story.
When uses the macro to put a QSO in log, it spent times to return the radio to receive.
In a contest scenario is impossible to use.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 20:23, G4GIR via groups.io
<i.frith= ntlworld.com@groups.io> ha scritto:
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>











 

 

 


Re: RTTY

Michael Harris
 

Hi,

For what its worth. I have just tried a contest exchange macro in MMVARI:

$transmit$ $starttime$
DE $mycall$ 599 $serialnum$ $serialnum$ TU
$receive$ $endtime$ $log$

The K3 changes to RX immediately. An oddity I notice with MMVARI is at the start of a transmission there is about a seconds worth of diddles before the "message" is transmitted.

I normally use MMTTY along with 2Tone and GRITTY as additional decoders.

$transmit$ $starttime$
$call$ 599 13 13 $mycall$ $receive$ $endtime$ $log$

Changes to receive immediately.

If I call CQ it normally grows into a pileup and I use the following:

$transmit$ $starttime$
$call$ $call$ 599 $mycall$
$receive$

$transmit$
$call$ tu $mycall$ $endtime$ $log$ up 1-3
$receive$

What happens if you use a macro that doesn't log i.e. a previous serial number?

$transmit$
599 $serialnum-1$ $serialnum-1$ $receive$

Again these change to RX immediately. I backup the log every five contacts.

Regards,

Mike VP8NO


Re: RTTY

Dave Colliau
 

Duh :)
Dave N8DC

On 10/17/2021 5:00 PM Tom Wylie <thomasgwylie@...> wrote:
 
 
Logger is not a contest programme, if you want something faster use wintest or N1MM which are dedicated contest programmes, then you can import your log directly into logger.   No point in trying to re-invent the wheel. Horses for courses.
 
Tom
GM4FDM 

On Sun, 17 Oct 2021, 21:57 g4girhb0 via groups.io, <ian.frith= ntlworld.com@groups.io> wrote:
Tried this suggestion Bob, but still getting the delay when the tones/tx have stopped.
 
73
 
Ian
 
----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
Sent: 17/10/2021 20:16:14
Subject: Re: [hamlogger] RTTY

Try:
 
$log$$call$ CFM $srx$ TU QRZ? de $mycall$$receive$
$call$ CFM $srx$ TU QRZ? de $mycall$$receive$$log$
 
In both cases I have removed an unwanted space from being transmitted before switching to receive. Other than that, the macros are correct, and the QSO is actually logged after the radio command to switch to receive is sent. If you are using PTT by radio command the faster the radio polling is the quicker it'll switch. SeventyThree(s).
On 10/17/2021 2:58 PM Fabio IZ8MBW via groups.io <iz8mbw= yahoo.it@groups.io> wrote:
 
 
These are two examples of Macros:
 
$log$$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$
 
 
 
$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$$log$
 
 
I don't think the problem is specific on the macros (I have tried various combinations), I think the problem is Logger32/MMVARI that during the time spent to put the QSO in the Logbook is "not able" to speedily stop the transmission.
As you can see from the video ( https://www.iz8mbw.net/mmvari.mp4) until the QSO is not in log, there is not any switch to RX (and the radio is still transmitting no text because there is no more text to send).
 
 
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 08:41:03 PM GMT+2, Bob < k4cy@...> wrote:
 
 
Please share with us the macro you use that makes it impossible to use in a contest. SeventyThree(s).
On 10/17/2021 2:27 PM Fabio IZ8MBW via groups.io <iz8mbw= yahoo.it@groups.io> wrote:
 
 
This is an old story.
When uses the macro to put a QSO in log, it spent times to return the radio to receive.
In a contest scenario is impossible to use.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 20:23, G4GIR via groups.io
<i.frith= ntlworld.com@groups.io> ha scritto:
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>











 

 

 


Re: RTTY

Tom Wylie
 

Logger is not a contest programme, if you want something faster use wintest or N1MM which are dedicated contest programmes, then you can import your log directly into logger.   No point in trying to re-invent the wheel. Horses for courses.

Tom
GM4FDM 

On Sun, 17 Oct 2021, 21:57 g4girhb0 via groups.io, <ian.frith=ntlworld.com@groups.io> wrote:
Tried this suggestion Bob, but still getting the delay when the tones/tx have stopped.
 
73
 
Ian
 
----- Original Message -----
From: Bob <k4cy@...>
Sent: 17/10/2021 20:16:14
Subject: Re: [hamlogger] RTTY

Try:
$log$$call$ CFM $srx$ TU QRZ? de $mycall$$receive$
$call$ CFM $srx$ TU QRZ? de $mycall$$receive$$log$
In both cases I have removed an unwanted space from being transmitted before switching to receive. Other than that, the macros are correct, and the QSO is actually logged after the radio command to switch to receive is sent. If you are using PTT by radio command the faster the radio polling is the quicker it'll switch. SeventyThree(s).
On 10/17/2021 2:58 PM Fabio IZ8MBW via groups.io <iz8mbw=yahoo.it@groups.io> wrote:
These are two examples of Macros:
$log$$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$
$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$$log$
I don't think the problem is specific on the macros (I have tried various combinations), I think the problem is Logger32/MMVARI that during the time spent to put the QSO in the Logbook is "not able" to speedily stop the transmission.
As you can see from the video ( https://www.iz8mbw.net/mmvari.mp4) until the QSO is not in log, there is not any switch to RX (and the radio is still transmitting no text because there is no more text to send).
73
Fabio, IZ8MBW
On Sunday, October 17, 2021, 08:41:03 PM GMT+2, Bob <k4cy@...> wrote:
Please share with us the macro you use that makes it impossible to use in a contest. SeventyThree(s).
On 10/17/2021 2:27 PM Fabio IZ8MBW via groups.io <iz8mbw=yahoo.it@groups.io> wrote:
This is an old story.
When uses the macro to put a QSO in log, it spent times to return the radio to receive.
In a contest scenario is impossible to use.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 20:23, G4GIR via groups.io
<i.frith=ntlworld.com@groups.io> ha scritto:
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>












Re: RTTY

g4girhb0 <ian.frith@...>
 

Tried this suggestion Bob, but still getting the delay when the tones/tx have stopped.
 
73
 
Ian
 

----- Original Message -----
From: Bob <k4cy@...>
Sent: 17/10/2021 20:16:14
Subject: Re: [hamlogger] RTTY

Try:
$log$$call$ CFM $srx$ TU QRZ? de $mycall$$receive$
$call$ CFM $srx$ TU QRZ? de $mycall$$receive$$log$
In both cases I have removed an unwanted space from being transmitted before switching to receive. Other than that, the macros are correct, and the QSO is actually logged after the radio command to switch to receive is sent. If you are using PTT by radio command the faster the radio polling is the quicker it'll switch. SeventyThree(s).
On 10/17/2021 2:58 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
These are two examples of Macros:
$log$$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$
$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$$log$
I don't think the problem is specific on the macros (I have tried various combinations), I think the problem is Logger32/MMVARI that during the time spent to put the QSO in the Logbook is "not able" to speedily stop the transmission.
As you can see from the video ( https://www.iz8mbw.net/mmvari.mp4) until the QSO is not in log, there is not any switch to RX (and the radio is still transmitting no text because there is no more text to send).
73
Fabio, IZ8MBW
On Sunday, October 17, 2021, 08:41:03 PM GMT+2, Bob <k4cy@...> wrote:
Please share with us the macro you use that makes it impossible to use in a contest. SeventyThree(s).
On 10/17/2021 2:27 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
This is an old story.
When uses the macro to put a QSO in log, it spent times to return the radio to receive.
In a contest scenario is impossible to use.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 20:23, G4GIR via groups.io
<i.frith@...> ha scritto:
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>












Re: RTTY

Fabio IZ8MBW
 

If this is the sequence, why the radio switch to RX and MMVARI window starts to decode again after the QSO is putted in the log?
If you see the video, you will see that behaviour.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 21:55, Bob
<k4cy@...> ha scritto:
Looking at the video, I see that Logger32 switched to receive at about 9.5 seconds (you can see 'Transmitting' change to 'Receiving'). Receive signals start appearing on the display at about 12 seconds. 
 
When switching to receive, the sequence of events is as follows:
 
a) Queue the radio command to switch to transmit
b) Change the text from Transmitting or receiving
c) Log the QSO if necessary.
 
So, it appears it is taking your setup 2.5 seconds for the time Logger32 queues the switch to receive radio command until it is executed by the radio. Siesta time? SeventyThree(s).
 
 
 
On 10/17/2021 2:34 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
In this video you can see the delay I have using both $logimmediate$ or $log$ macros in MMVARI:
 
 
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 08:23:41 PM GMT+2, G4GIR via groups.io <i.frith@...> wrote:
 
 
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>












Re: RTTY

Fabio IZ8MBW
 

My PC for sure doesn't have a recent processor, it is a first generation intel i3 processor.
When I use L32Sync the delay is bigger, but anyway also without using L32Sync I have the delay.

Also consider that if I/we use the the Qrz lookup the data to put in log are bigger.

So probably putting more data into the logbook increase the delay.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 22:04, Bob
<k4cy@...> ha scritto:
But why the dleay? Are you using L32Sync to LoTW? 73.
On 10/17/2021 3:55 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
Hi Bob.
carriage return and space apart, the radio doesn't stop to transmit until the QSO is putted in the LOG (it looks like Logger32 is "busy" to put the QSO in the Logbook and the rest come after).
In my case I use a dedicated Serial Port for the TX command (so not using CAT).
For the TX command I have also tried to switch from  dedicated Serial Port to CAT and probaily I have gained some milliseconds of less delay.
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 09:16:31 PM GMT+2, Bob <k4cy@...> wrote:
 
 
Try:
 
$log$$call$ CFM $srx$ TU QRZ? de $mycall$$receive$
$call$ CFM $srx$ TU QRZ? de $mycall$$receive$$log$
 
In both cases I have removed an unwanted space from being transmitted before switching to receive. Other than that, the macros are correct, and the QSO is actually logged after the radio command to switch to receive is sent. If you are using PTT by radio command the faster the radio polling is the quicker it'll switch. SeventyThree(s).
On 10/17/2021 2:58 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
These are two examples of Macros:
 
$log$$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$
 
 
 
$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$$log$
 
 
I don't think the problem is specific on the macros (I have tried various combinations), I think the problem is Logger32/MMVARI that during the time spent to put the QSO in the Logbook is "not able" to speedily stop the transmission.
As you can see from the video ( https://www.iz8mbw.net/mmvari.mp4) until the QSO is not in log, there is not any switch to RX (and the radio is still transmitting no text because there is no more text to send).
 
 
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 08:41:03 PM GMT+2, Bob <k4cy@...> wrote:
 
 
Please share with us the macro you use that makes it impossible to use in a contest. SeventyThree(s).
On 10/17/2021 2:27 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
This is an old story.
When uses the macro to put a QSO in log, it spent times to return the radio to receive.
In a contest scenario is impossible to use.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 20:23, G4GIR via groups.io
<i.frith@...> ha scritto:
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>











 
 


Re: RTTY

Bob
 

But why the dleay? Are you using L32Sync to LoTW? 73.

On 10/17/2021 3:55 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
Hi Bob.
carriage return and space apart, the radio doesn't stop to transmit until the QSO is putted in the LOG (it looks like Logger32 is "busy" to put the QSO in the Logbook and the rest come after).
In my case I use a dedicated Serial Port for the TX command (so not using CAT).
For the TX command I have also tried to switch from  dedicated Serial Port to CAT and probaily I have gained some milliseconds of less delay.
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 09:16:31 PM GMT+2, Bob <k4cy@...> wrote:
 
 
Try:
 
$log$$call$ CFM $srx$ TU QRZ? de $mycall$$receive$
$call$ CFM $srx$ TU QRZ? de $mycall$$receive$$log$
 
In both cases I have removed an unwanted space from being transmitted before switching to receive. Other than that, the macros are correct, and the QSO is actually logged after the radio command to switch to receive is sent. If you are using PTT by radio command the faster the radio polling is the quicker it'll switch. SeventyThree(s).
On 10/17/2021 2:58 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
These are two examples of Macros:
 
$log$$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$
 
 
 
$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$$log$
 
 
I don't think the problem is specific on the macros (I have tried various combinations), I think the problem is Logger32/MMVARI that during the time spent to put the QSO in the Logbook is "not able" to speedily stop the transmission.
As you can see from the video ( https://www.iz8mbw.net/mmvari.mp4) until the QSO is not in log, there is not any switch to RX (and the radio is still transmitting no text because there is no more text to send).
 
 
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 08:41:03 PM GMT+2, Bob <k4cy@...> wrote:
 
 
Please share with us the macro you use that makes it impossible to use in a contest. SeventyThree(s).
On 10/17/2021 2:27 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
This is an old story.
When uses the macro to put a QSO in log, it spent times to return the radio to receive.
In a contest scenario is impossible to use.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 20:23, G4GIR via groups.io
<i.frith@...> ha scritto:
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>











 
 


Re: RTTY

Fabio IZ8MBW
 

Hi Bob.
carriage return and space apart, the radio doesn't stop to transmit until the QSO is putted in the LOG (it looks like Logger32 is "busy" to put the QSO in the Logbook and the rest come after).
In my case I use a dedicated Serial Port for the TX command (so not using CAT).
For the TX command I have also tried to switch from dedicated Serial Port to CAT and probaily I have gained some milliseconds of less delay.


73
Fabio, IZ8MBW



On Sunday, October 17, 2021, 09:16:31 PM GMT+2, Bob <k4cy@...> wrote:


Try:
 
$log$$call$ CFM $srx$ TU QRZ? de $mycall$$receive$
$call$ CFM $srx$ TU QRZ? de $mycall$$receive$$log$
 
In both cases I have removed an unwanted space from being transmitted before switching to receive. Other than that, the macros are correct, and the QSO is actually logged after the radio command to switch to receive is sent. If you are using PTT by radio command the faster the radio polling is the quicker it'll switch. SeventyThree(s).
On 10/17/2021 2:58 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
These are two examples of Macros:
 
$log$$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$
 
 
 
$call$ CFM $srx$ TU
QRZ? de $mycall$ $receive$$log$
 
 
I don't think the problem is specific on the macros (I have tried various combinations), I think the problem is Logger32/MMVARI that during the time spent to put the QSO in the Logbook is "not able" to speedily stop the transmission.
As you can see from the video ( https://www.iz8mbw.net/mmvari.mp4) until the QSO is not in log, there is not any switch to RX (and the radio is still transmitting no text because there is no more text to send).
 
 
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 08:41:03 PM GMT+2, Bob <k4cy@...> wrote:
 
 
Please share with us the macro you use that makes it impossible to use in a contest. SeventyThree(s).
On 10/17/2021 2:27 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
This is an old story.
When uses the macro to put a QSO in log, it spent times to return the radio to receive.
In a contest scenario is impossible to use.

73s
Fabio, IZ8MBW

Il dom, 17 ott, 2021 alle 20:23, G4GIR via groups.io
<i.frith@...> ha scritto:
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>











 


Re: RTTY

Bob
 

Looking at the video, I see that Logger32 switched to receive at about 9.5 seconds (you can see 'Transmitting' change to 'Receiving'). Receive signals start appearing on the display at about 12 seconds. 
 
When switching to receive, the sequence of events is as follows:
 
a) Queue the radio command to switch to transmit
b) Change the text from Transmitting or receiving
c) Log the QSO if necessary.
 
So, it appears it is taking your setup 2.5 seconds for the time Logger32 queues the switch to receive radio command until it is executed by the radio. Siesta time? SeventyThree(s).
 
 
 

On 10/17/2021 2:34 PM Fabio IZ8MBW via groups.io <iz8mbw@...> wrote:
 
 
In this video you can see the delay I have using both $logimmediate$ or $log$ macros in MMVARI:
 
 
 
 
73
Fabio, IZ8MBW
 
 
 
On Sunday, October 17, 2021, 08:23:41 PM GMT+2, G4GIR via groups.io <i.frith@...> wrote:
 
 
Thanks' Bob

That's working Ok now.

I have yet another problem.

After sending any of the Macros, there is about a 2 second delay before the rig goes back to receive, most annoying.

Any clues?

73

Ian

----- Original Message -----
From: g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:22:15
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


Roger, that sounds good..

73

Ian

----- Original Message -----
From: Bob < k4cy@...>
Reply-To: < hamlogger@groups.io>
To: < hamlogger@groups.io>
Sent: 17/10/2021 17:18:13
Subject: Re: [hamlogger] RTTY
________________________________________________________________________________


I'd guess you could program a macro button to $logimmediate$, or append a $log$ to the end of your standard 'sign-off' message. SeventyThree(s).

> On 10/17/2021 12:04 PM g4girhb0 via groups.io <ian.frith= ntlworld.com@groups.io> wrote:
>

> Thanks' Bob/Fabio
>
> No Fabio even with 0 RF still fails.
>
> Yes Bob twa's the PTT Set up had Shared Radio Port selected in stead of Radio Command.
>
> Whilst on RTTY, once the Logging widow is populated is there a command from the RTTY window to save the QSO?
>
> 73
>
> iAN g4gir
>
> ----- Original Message -----
> From: Bob < k4cy@...>
> Reply-To: < hamlogger@groups.io>
> To: < hamlogger@groups.io>
> Sent: 17/10/2021 16:36:51
> Subject: Re: [hamlogger] RTTY
> ________________________________________________________________________________
>
>
> How have you configured the MMVARI PTT? What does the radio debug reveal? Does polling stop, or does polling continue and the radio stops replying? SeventyThree(s).
>
> > On 10/17/2021 11:24 AM G4GIR via groups.io <i.frith= ntlworld.com@groups.io> wrote:
> >
> > 
> > Thought I would play with the sound card today. With the RTTY contest in swing.
> >
> > Problem.
> >
> > Running MMVARI, Receives and Transmits OK.
> > Click on Call in Receive Window, L32 Logging window populates
> > Transmit to station, Station answers, Cat Control of Radio is Lost i.e Frequency in logging widow goes to .00 and no mode is shown.
> >
> > Any help to solve please.
> >
> > 73
> >
> > Ian G4GIR
> >
> >
> >
>
>
>
>
>
>











1321 - 1340 of 87443