Date   

Welcome 2811

Jim K5SP
 

Please join me in welcoming new member:

2811 Terry KZ4KX

Terry's Membership data is 12/12/20, which means those contacts he has had since the contest started count as a member. 

Welcome to the club Terry!

Jim K5SP
Executive Director
--
Jim,  K5SP #483
Executive Director/Member Services Director


Re: RC3 Standings

Stephen Melachrinos
 

Steve -

I'm pretty sure we've identified both callsigns as belonging to you. I was really posting that about RC3, and that's an annual thing. During this year, we've had two callsign changes we know about, but I was afraid there might be more.

If you've been uploading under one callsign, then all your awards are intact. 

Thanks for checking.

73,
Steve
W3HF



-----Original Message-----
From: Steve R via groups.io <oldjavadrinker@...>
To: main@070Club.groups.io
Sent: Sun, Dec 13, 2020 2:36 am
Subject: Re: [070Club] RC3 Standings

 Steve.

Not sure how I missed this. I operated KM4FLF/VE3 from 2016 to May 2017 until I got Canada ticket. Every time I upload for awards I always just merge that old adif into the new one since it was same QTH. I found that easier than all of us tracking two calls.

Steve
VA3FLF
2301


Re: RC3 Standings

Steve VA3FLF/KM4FLF
 

 Steve.

Not sure how I missed this. I operated KM4FLF/VE3 from 2016 to May 2017 until I got Canada ticket. Every time I upload for awards I always just merge that old adif into the new one since it was same QTH. I found that easier than all of us tracking two calls.

Steve
VA3FLF
2301


Re: Doubleheader contest

Josef 'Jeff' Sipek
 

On Sat, Dec 12, 2020 at 23:28:49 +0000, Stephen Melachrinos via groups.io wrote:
John -
Exactly correct. You never really know what the other station is going to
do, and since the exchange is so quick, I just run with it. Besides, it's
the courteous approach.
I also like to throw in that it is a dup. On several occasions that has
revealed an error in logging.

Jeff.

I usually average two or three dupes on this type of contest.
SteveW3HF


-----Original Message-----
From: John - KC3FL via groups.io <kc3fl=aol.com@groups.io>
To: main@070Club.groups.io
Sent: Sat, Dec 12, 2020 11:13 pm
Subject: Re: [070Club] Doubleheader contest


So if you make a contact with a station that shows up as a dupe there is the possibility that the station decided to start a different block.  With that being the case it is easier and quicker to just go ahead and log the contact just in case they changed their block.  It would take longer trying to explain they were a dupe.

John
KC3FL






Re: Doubleheader contest

Stephen Melachrinos
 

John -

Exactly correct. You never really know what the other station is going to do, and since the exchange is so quick, I just run with it. Besides, it's the courteous approach.

I usually average two or three dupes on this type of contest.

Steve
W3HF


-----Original Message-----
From: John - KC3FL via groups.io <kc3fl@...>
To: main@070Club.groups.io
Sent: Sat, Dec 12, 2020 11:13 pm
Subject: Re: [070Club] Doubleheader contest

So if you make a contact with a station that shows up as a dupe there is the possibility that the station decided to start a different block.  With that being the case it is easier and quicker to just go ahead and log the contact just in case they changed their block.  It would take longer trying to explain they were a dupe.

John
KC3FL


Re: Doubleheader contest

 

So if you make a contact with a station that shows up as a dupe there is the possibility that the station decided to start a different block.  With that being the case it is easier and quicker to just go ahead and log the contact just in case they changed their block.  It would take longer trying to explain they were a dupe.

John
KC3FL


Re: Doubleheader contest

Randy True
 

Yeah, I'm one of the still confused. Just make it any 6 hours in a 24hr block.

Randy W4RTT


From: main@070Club.groups.io <main@070Club.groups.io> on behalf of Stephen Melachrinos via groups.io <melachri@...>
Sent: Saturday, December 12, 2020 11:31 AM
To: main@070club.groups.io <main@070club.groups.io>
Subject: [070Club] Doubleheader contest
 
I hope everyone is enjoying the contest. I've seen a lot of stations on the air, and that's great. But I've also seen some signals on the air this morning that cause me to question whether everyone understands the rules. So here are some thoughts about parts of the rules that may not be obvious.

1. This is a low-band sprint, limited to 40, 80, and 160 meter bands. So QSOs on any other bands won't count. (They may be really great rag-chews, or good DX, or even LONP points, though!)

2. The contest timing is based on UTC days, and you are allowed a single six-hour block of time on each of those days. So if you operated last night from 0000z to 0600z (as I did), which was the start of UTC 12 December, then any contacts until 0000z of 13 December would constitute a different six-hour block and you'd have to choose one or the other to count in your score. This will repeat into the 14 of December. I've made two 40m contacts this morning that won't count for me, but they will count for the "other guy" if he chooses that block.

3. That said, recognize that people will be operating at different times during the days, and it's possible that those "other guys" might be on the air again tonight, during my chosen block of time for 13 December. And I hope they'll realize that although another QSO with me will be a dupe for them, it won't be for me. So I'd appreciate that QSO for my purposes.

73,
Steve
W3HF





Doubleheader contest

Stephen Melachrinos
 

I hope everyone is enjoying the contest. I've seen a lot of stations on the air, and that's great. But I've also seen some signals on the air this morning that cause me to question whether everyone understands the rules. So here are some thoughts about parts of the rules that may not be obvious.

1. This is a low-band sprint, limited to 40, 80, and 160 meter bands. So QSOs on any other bands won't count. (They may be really great rag-chews, or good DX, or even LONP points, though!)

2. The contest timing is based on UTC days, and you are allowed a single six-hour block of time on each of those days. So if you operated last night from 0000z to 0600z (as I did), which was the start of UTC 12 December, then any contacts until 0000z of 13 December would constitute a different six-hour block and you'd have to choose one or the other to count in your score. This will repeat into the 14 of December. I've made two 40m contacts this morning that won't count for me, but they will count for the "other guy" if he chooses that block.

3. That said, recognize that people will be operating at different times during the days, and it's possible that those "other guys" might be on the air again tonight, during my chosen block of time for 13 December. And I hope they'll realize that although another QSO with me will be a dupe for them, it won't be for me. So I'd appreciate that QSO for my purposes.

73,
Steve
W3HF





Re: Zulu time, GMT & UTC

Don - KM4UDX
 

Wait, Iceland time always = UTC?
Why am I just hearing this now? 
This is great.
--
Don, km4udx, uBITX, and other obscure acronyms go here...


Re: HRD Logbook to LoTW with Other Grids

Eric KG6MZS
 

Thanks for the reply Darin.

I did that and then when I imported an ADI file it didn't take the "My Station" data from the new Location.  I think you might have to make an entree in the new Database with the "Add" button first to make sure the import takes the new Location.

Thanks again,

Eric


On 12/11/20 2:03 PM, Darin - KO4EJD wrote:
Eric,
You can go to my station and set that up.  I have 3 locations configured.
Before operating just select the one you want.

From logbook go to configure, my station and you'll see the option.

From DM780 go to program options and select calling.  This ties back to my station in logbook.

Good luck
Darin 

On Fri, Dec 11, 2020, 2:38 PM Eric KG6MZS <contact@...> wrote:
Hello All,

While restricted by the pandemic, I'm getting ready to activate other grids and I've pretty much got it all worked out except for one hitch.

I see in HRD Logbook you can define different Locations and you can create different Databases for different logs.  What I can't seem to figure out is how to assign those Locations to the different Databases.

I have set up different locations in LoTW but when I try and sign and upload the logs from HRD, LoTW tells me that the grids don't match.  LoTW thinks the logs have my home grid, not the new grid from elsewhere.

So how do I tell HRD to assign the grid from the activating location to the new database?

TIA
Eric, KG6MZS


Re: Zulu time, GMT & UTC

Jerry N9AVY
 

Yup, most software will convert local time from computer to UTC/GMT/Zulu.  If your software doesn't do that, you were ripped off !

Emoji

Jerry



On Friday, December 11, 2020, 04:35:32 PM CST, Barry VA7GEM via groups.io <boat.anchor@...> wrote:


I keep m computer on local time and my software (HRD)
on UTC. No question about what time it is.


Re: Zulu time, GMT & UTC

Leland Sly
 

👍

On Fri, Dec 11, 2020 at 4:35 PM Barry VA7GEM via groups.io <boat.anchor=yahoo.ca@groups.io> wrote:
I keep m computer on local time and my software (HRD)
on UTC. No question about what time it is.


Re: Zulu time, GMT & UTC

Barry VA7GEM
 

I keep m computer on local time and my software (HRD)
on UTC. No question about what time it is.


Re: HRD Logbook to LoTW with Other Grids

Darin - KO4EJD
 

Eric,
You can go to my station and set that up.  I have 3 locations configured.
Before operating just select the one you want.

From logbook go to configure, my station and you'll see the option.

From DM780 go to program options and select calling.  This ties back to my station in logbook.

Good luck
Darin 

On Fri, Dec 11, 2020, 2:38 PM Eric KG6MZS <contact@...> wrote:
Hello All,

While restricted by the pandemic, I'm getting ready to activate other grids and I've pretty much got it all worked out except for one hitch.

I see in HRD Logbook you can define different Locations and you can create different Databases for different logs.  What I can't seem to figure out is how to assign those Locations to the different Databases.

I have set up different locations in LoTW but when I try and sign and upload the logs from HRD, LoTW tells me that the grids don't match.  LoTW thinks the logs have my home grid, not the new grid from elsewhere.

So how do I tell HRD to assign the grid from the activating location to the new database?

TIA
Eric, KG6MZS


HRD Logbook to LoTW with Other Grids

Eric KG6MZS
 

Hello All,

While restricted by the pandemic, I'm getting ready to activate other grids and I've pretty much got it all worked out except for one hitch.

I see in HRD Logbook you can define different Locations and you can create different Databases for different logs.  What I can't seem to figure out is how to assign those Locations to the different Databases.

I have set up different locations in LoTW but when I try and sign and upload the logs from HRD, LoTW tells me that the grids don't match.  LoTW thinks the logs have my home grid, not the new grid from elsewhere.

So how do I tell HRD to assign the grid from the activating location to the new database?

TIA
Eric, KG6MZS


Re: Zulu time, GMT & UTC

Paula K7PAX #1739
 

Good to know about Iceland time. That could be very useful!

Paula K7PAX

On Dec 10, 2020, at 10:50 AM, Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:

On Thu, Dec 10, 2020 at 18:07:46 +0000, Jerry N9AVY wrote:
This may clear up some confusion about time ...
Jerry n9avy

"Zulu" time, more commonly know as "GMT" ( Greenwich Mean Time )
is time at the Zero Meridian. ... Due to various scientific reasons and
increased accuracy in measuring the earth's rotation, a new timescale,
called Universal Time Coordinated or Coordinated Universal Time (UTC), has
been adopted and replaced the term GMT.
This is true. Additionally, using "GMT" can get *really* confusing, and
that's why I avoid it.

There is a subtle difference between the three quantities.

During the winter, UTC = GMT = "time in the UK" (well, +-1 second).

During the summer, things get more complicated. While UTC just continues on
without interruption, the "time in the UK" is BST (British Summer Time)
which equals UTC+1 hour. GMT is the confusing one. Some say that it is
equal to UTC, some say that it is equal to "time in the UK". (Obviously, it
cannot be both.)

It's very annoying to deal with, and that's why I strongly suggest everyone
avoids saying "GMT" - especially during the summer.

In short:

* if you mean "zulu" time, write "UTC"
* if you mean "time in the UK", just write it out. (E.g., "let's meet at
noon London-time" or if it is clear from the context: "noon local time")

Tip for scheduling cross-timezone meetings:

Make sure you agree on both the time and the timezone. Then, enter the
event into your calendar as that - even if it isn't your timezone. Any
calendaring program worth using will correctly deal with changes to DST. If
you try to be clever, you might end up showing up at the wrong time.

For example, say I living in Massachusetts want to schedule a QSO with
someone in Frankfurt, Germany. If we agree to 12:30 local time in
Frankfurt, I'll enter it into my calendar just like that: 12:30 in
Frankfurt. Then, it doesn't matter if it is DST here, summer time in EU, or
the weird in-between few weeks where the US is on DST but EU is still on
winter time.

If I try to be clever, and instead of 12:30 in Frankfurt I put 06:30 in
Massachusetts it may work most of the time (namely when US and EU are both
using winter/summer time). But during the spring and fall, when the local
time difference between MA and Germany is only 5 hours, I'll have to be on
the radio at 07:30. Had I entered it as 12:30 Frankfurt, the calendar would
have automatically figured it out. But if I enter it as 06:30 MA, the
calendar doesn't know it should adjust it by an hour.

Oh, and if you want to schedule something for a UTC time and your calendar
doesn't let you enter "zulu" time, pick Iceland as the timezone location.
Iceland uses UTC year-round as their local time.

Huh... this turned out longer than I anticipated. Anyway, calendaring is
hard, timezones are hard, and it is a minor miracle civilization hasn't
collapsed because of the two :)

Jeff.






Re: Zulu time, GMT & UTC

Josef 'Jeff' Sipek
 

On Thu, Dec 10, 2020 at 13:58:41 -0500, Josef 'Jeff' Sipek wrote:
On Thu, Dec 10, 2020 at 18:38:28 +0000, Jerry N9AVY wrote:
...
Once you know your time zone is it get easier.  For example:  CST is
GMT/UTC plus 5 hours and CDST is plus 6 hours.  Simple, yes ?
Assuming CST is Central Standard Time, I have two things to point out:

(1)

CST is UTC *minus* 6 hours
CDT is UTC *minus* 5 hours

(2) The official abbreviations for the timezones in the lower 48 states are:
EST/CST/MST/PST (winter/non-DST) and EDT/CDT/MDT/PDT (winter/DST)
Err, copy & paste error - that should read:

(2) The official abbreviations for the timezones in the lower 48 states are:
EST/CST/MST/PST (winter/non-DST) and EDT/CDT/MDT/PDT (summer/DST)


Sorry,

Jeff.



Jeff.


Jerry  n9avy
On Thursday, December 10, 2020, 12:31:23 PM CST, Rick - N7WE <n7we1980@gmail.com> wrote:

I find the attached chart helpful.
--
Rick - N7WE
070 - #1602










Re: Zulu time, GMT & UTC

Josef 'Jeff' Sipek
 

On Thu, Dec 10, 2020 at 18:38:28 +0000, Jerry N9AVY wrote:
...
Once you know your time zone is it get easier.  For example:  CST is
GMT/UTC plus 5 hours and CDST is plus 6 hours.  Simple, yes ?
Assuming CST is Central Standard Time, I have two things to point out:

(1)

CST is UTC *minus* 6 hours
CDT is UTC *minus* 5 hours

(2) The official abbreviations for the timezones in the lower 48 states are:
EST/CST/MST/PST (winter/non-DST) and EDT/CDT/MDT/PDT (winter/DST)

Jeff.


Jerry  n9avy
On Thursday, December 10, 2020, 12:31:23 PM CST, Rick - N7WE <n7we1980@gmail.com> wrote:

I find the attached chart helpful.
--
Rick - N7WE
070 - #1602





Re: Zulu time, GMT & UTC

Josef 'Jeff' Sipek
 

On Thu, Dec 10, 2020 at 18:07:46 +0000, Jerry N9AVY wrote:
This may clear up some confusion about time ...
Jerry  n9avy

"Zulu" time, more commonly know as "GMT" ( Greenwich Mean Time )
is time at the Zero Meridian. ... Due to various scientific reasons and
increased accuracy in measuring the earth's rotation, a new timescale,
called Universal Time Coordinated or Coordinated Universal Time (UTC), has
been adopted and replaced the term GMT.
This is true. Additionally, using "GMT" can get *really* confusing, and
that's why I avoid it.

There is a subtle difference between the three quantities.

During the winter, UTC = GMT = "time in the UK" (well, +-1 second).

During the summer, things get more complicated. While UTC just continues on
without interruption, the "time in the UK" is BST (British Summer Time)
which equals UTC+1 hour. GMT is the confusing one. Some say that it is
equal to UTC, some say that it is equal to "time in the UK". (Obviously, it
cannot be both.)

It's very annoying to deal with, and that's why I strongly suggest everyone
avoids saying "GMT" - especially during the summer.

In short:

* if you mean "zulu" time, write "UTC"
* if you mean "time in the UK", just write it out. (E.g., "let's meet at
noon London-time" or if it is clear from the context: "noon local time")

Tip for scheduling cross-timezone meetings:

Make sure you agree on both the time and the timezone. Then, enter the
event into your calendar as that - even if it isn't your timezone. Any
calendaring program worth using will correctly deal with changes to DST. If
you try to be clever, you might end up showing up at the wrong time.

For example, say I living in Massachusetts want to schedule a QSO with
someone in Frankfurt, Germany. If we agree to 12:30 local time in
Frankfurt, I'll enter it into my calendar just like that: 12:30 in
Frankfurt. Then, it doesn't matter if it is DST here, summer time in EU, or
the weird in-between few weeks where the US is on DST but EU is still on
winter time.

If I try to be clever, and instead of 12:30 in Frankfurt I put 06:30 in
Massachusetts it may work most of the time (namely when US and EU are both
using winter/summer time). But during the spring and fall, when the local
time difference between MA and Germany is only 5 hours, I'll have to be on
the radio at 07:30. Had I entered it as 12:30 Frankfurt, the calendar would
have automatically figured it out. But if I enter it as 06:30 MA, the
calendar doesn't know it should adjust it by an hour.

Oh, and if you want to schedule something for a UTC time and your calendar
doesn't let you enter "zulu" time, pick Iceland as the timezone location.
Iceland uses UTC year-round as their local time.

Huh... this turned out longer than I anticipated. Anyway, calendaring is
hard, timezones are hard, and it is a minor miracle civilization hasn't
collapsed because of the two :)

Jeff.


Re: Zulu time, GMT & UTC

Jerry N9AVY
 

It's a helpful chart, but it's easier to hand the GMT/UTC/Zulu time at 0000 hours in one's mind and start from there rather than having to refer to a chart.  Am sure chart will be helpful to many, but I wouldn't rely on it too heavily.

Once you know your time zone is it get easier.  For example:  CST is GMT/UTC plus 5 hours and CDST is plus 6 hours.  Simple, yes ?

Jerry  n9avy

On Thursday, December 10, 2020, 12:31:23 PM CST, Rick - N7WE <n7we1980@...> wrote:


I find the attached chart helpful.
--
Rick - N7WE
070 - #1602

3281 - 3300 of 68043