Date   

locked Re: Contest mode? #ContestMode

Dave Garber
 

read up on fox and hound mode....  usually dx stations, though


Dave Garber
VE3WEJ / VE3IE


On Mon, Jul 19, 2021 at 11:54 AM George J Molnar, KF2T <george@...> wrote:

One enhancement that might help in this situation is to build a call queue that allows multiple callers to be stacked and worked either sequentially or from a pick list by the operator. The progress of each contact could be maintained so that in QSB or scatter situations, contacts could “interleave” a little bit to improve rate.  Rare grid rovers, expeditions, and other popular stations could benefit. 


Having a blast on the radio. Thanks to all!

George/KF2T





locked Re: Clock Sync #Timesync

Robert Lorenzini
 

On 7/19/2021 5:01 PM, Tim wrote:



Anything more is running down the hole which is time nuttery :)

Tim are you one of us?
https://groups.io/g/time-nuts

Bob - wd6dod


locked Re: Operating portable #WSJTX_config #FT8

Tom Melvin
 

Karl

Please remember Amateur Radio is world wide - so FCC rules may not apply and people should be advised to check their own licence wording.

In the UK while it is not mandatory to send /P,  /A etc it is RECOMMENDED.


(d) When operating at locations other than the Main Station Address, it is recommended that the following suffixes be used:

I. If the Licensee operates the Radio Equipment at an Alternative Address, the Licensee may use the suffix “/A” with the Callsign;

II. If the Licensee operates the Radio Equipment at a Temporary Location, the Licensee may use the suffix “/P” with the Callsign;

III. If the Licensee operates the Radio Equipment from a Mobile location, the Licensee may use the suffix “/M” with theCallsign;

IV. If the Licensee operates the Radio Equipment from a Maritime Mobile location, the Licensee may use the suffix “/MM” with the Callsign.


I would much prefer to follow recommendations than risk misunderstanding.  Also WSJT-X  treat /P, /A etc as ’standard’ callsigns so no issue there.   In some contests it is mandatory to sign /P if portable.  By all means jump on stations governed by FCC rules but that is not everyone.

Regards

Tom
GM8MJV


On 19 Jul 2021, at 22:05, Karl Beckman <wa8nvw@...> wrote:

This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io




locked Re: Clock Sync #Timesync

Tim
 

Hi Jim,

The fundamental error here is using 2 clocks as reference, it doesn't matter that they are both GPS.

NTP specifically requires 3 or more to arrive at correct time. But 3 is still a "single point of failure" mode since the failure of any one clock will result in there being only 2 and then NTP doesn't know who is correct. In some circumstances NTP will mark them both "insane" and use the host computer's internal clock as the reference.

Given each GPS receiver is supplying time resulting from the aggregate of 64+ clocks ( assuming I'm seeing 16 or more satellites and I'm locked to them ), you really don't need more than one GPS receiver attached to a computer.

If your view of the sky is compromised then use a GPS receiver with good hold over performance, to provide the reference time.

If you want network redundancy then build 4 or more PIs with GPS/PPS and NTP, your client devices will then have multiple sources for the time.

NTP was originally derived to take WWV, WWVB, or GOES satellite time and redistribute the time over a network for synchronising a routing protocol.

PPS abilities appeared in NTP around 1999.

Using USB 1 or 2 as the timing source introduces significant jitter into a time stamp given its polling nature.

Proper implementations over USB 3 might change that given it can use interrupts instead of polling.

Best time keeping is by using PPS over a serial port's DCD pin, or PPS to a GPIO pin on a CPU, to drive NTP and use the NMEA statements via serial or USB to let NTP time stamp the PPS it just heard. i.e. at 1PPS, a time stamp via USB can arrive within the next 59ms to let NTP know what time the PPS it heard actually was.


All that being said... a single USB/GPS receiver, and associated software, attached to your computer is generally more than enough for WSJT-X's timing requirements of +/- 1 second.


Anything more is running down the hole which is time nuttery :)


cheers

Tim

-- 
VK2XAX : QF56if : ITU59 : CQ30 : BMARC : WIA


locked Re: Operating portable #WSJTX_config #FT8

Jim Brown
 

On 7/19/2021 2:44 PM, Bill Somerville wrote:
I would not say it is a bad idea, it is a user choice. Complaining that that you can't add a gridsquare to your CQ calls if you are using a nonstandard callsign is a bad idea, as it demonstrates a poor understanding of how weak signal digimodes work.
Yes, that too. But as I observed in my response to Dana, a grid square provides far more information to others considering whether to work you and where to point their antenna than does any of those suffixes. Consider, for example, a station in California seeing a station signing /7. The US 7th area extends from Washington to Arizona, so depending on where you are in California, the beam heading varies by as much as 90-130 degrees.

And if you're contesting or calling a DX pileup on CW, SSB, or RTTY, you're both wasting time AND making it more difficult for the other station to get your call right. Ditto for those who seek preferential treatment by signing /QRP. I work a lot of QRP (170 countries confirmed), I've never done that, and I won't work stations who do.

73, Jim K9YC


locked Re: Operating portable #WSJTX_config #FT8

Bill Somerville
 

On 19/07/2021 22:41, Jim Brown wrote:
On 7/19/2021 2:33 PM, Marion D. Kitchens wrote:
Do the rules part 97 PROHIBIT using suffix?

No. But for the reasons Bill cited, doing so is a bad idea.

73, Jim K9YC

Jim,

I would not say it is a bad idea, it is a user choice. Complaining that that you can't add a gridsquare to your CQ calls if you are using a nonstandard callsign is a bad idea, as it demonstrates a poor understanding of how weak signal digimodes work.

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Jim Brown
 

On 7/19/2021 2:33 PM, Marion D. Kitchens wrote:
Do the rules part 97 PROHIBIT using suffix?
No. But for the reasons Bill cited, doing so is a bad idea.

73, Jim K9YC


locked Re: Operating portable #WSJTX_config #FT8

Marion D. Kitchens
 


Do the rules part 97 PROHIBIT using suffix?  I kinda like seeing those suffizs because it offers addition information.
 
Just my 2 cents worth....
 
Marion,    K4GOK
 
On Mon, 19 Jul 2021 14:05:09 -0700 "Karl Beckman" <wa8nvw@...> writes:

This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io
 


locked Re: WSJT-x signal processing versus RTTY decoding in Fldigi? #decode

Bill Somerville
 

On 19/07/2021 19:26, Bruce KX4AZ wrote:
I have always been in awe over the signal processing and error correction techniques used in the assorted WSJT-x modes....and my curiosity compels me to ask...

I wonder if any of these techniques could be applied with other modes like RTTY in programs like Fldigi.  Of course, RTTY has no error correction by design, but what about the other "tricks" used by WSJT-x for weak signal decoding?  Or do programs like Fldigi already have the latest and greatest decoding algorithms built in for weaker RTTY signals?

If this query doesn't belong in this forum, would appreciate a "re-direct" sent my way.
Hi Bruce,

simple answer, if you want weak signal efficiency then don't start with something like BAUDOT using FSK at 45.5 baud.

Of course authors of soundcard RTTY decoders have explored and implemented all sorts of smart filtering and other DSP techniques to get the best decoding performance they could. There is probably very little leeway for much better performance without changing the protocol in some way.

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Bill Somerville
 

On 19/07/2021 22:05, Karl Beckman wrote:
This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io

Karl,

modes like FT8, FT4, MSK144, Q65, and FST4, which all share the same basic source encoding rules, have a great deal of flexibility for nonstandard callsigns (by non-standard I mean in terms of these modes definition of a standard callsign which is more complex than "maximum of 6 characters"). If a nonstandard callsign is used with these modes then there are restrictions on what other information can be passed in standard format messages. The main restriction is that gridsquares cannot be conveyed in CQ or QRZ messages, another secondary but important restriction is that two stations with such nonstandard callsigns cannot easily work each other, yet another is that the special contest modes do not support nonstandard callsigns.

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Karl Beckman WA8NVW - AFA5VB
 

This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io


locked Re: Clock Sync #Timesync

Alan <n5pa@...>
 

Joe:

I am completely agree with you!  And in my unscientific means, it works well enough to keep your time for WSJT-X working. It may not be as accurate as a yottasecond (Ys or 10 to the 24th), but it is accurate enough to work with WSJT-X, and as that is all that matters!

73,
Alan Clark, N5PA
Ellisville, MS
Email:  n5pa@...
URL:  http://www.n5pa.com

On Jul 19, 2021, at 11:55 AM, Joe <joe@...> wrote:

Hi Jim,

"If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter."

Let's see...  the speed of light is 3 x 10^8 m/s, so the delay in a 1 meter cable is 1.0/(0.8x3x10^8) = 4.2 x 10^-9.  I make it around 4 nanoseconds, not 250 microseconds.  But you're certainly right, the cable delay is well under a millisecond.  :-)

  -- 73, Joe, K1JT



locked WSJT-x signal processing versus RTTY decoding in Fldigi? #decode

Bruce KX4AZ
 

I have always been in awe over the signal processing and error correction techniques used in the assorted WSJT-x modes....and my curiosity compels me to ask...

I wonder if any of these techniques could be applied with other modes like RTTY in programs like Fldigi.  Of course, RTTY has no error correction by design, but what about the other "tricks" used by WSJT-x for weak signal decoding?  Or do programs like Fldigi already have the latest and greatest decoding algorithms built in for weaker RTTY signals?

If this query doesn't belong in this forum, would appreciate a "re-direct" sent my way.


locked Re: Clock Sync #Timesync

Jim Pennino
 

Yeah, sometimes there is a disconnect between the brain and the fingers...

What it should have said is the propagation VELOCITY is about 250 meters per microsecond or 4 nanoseconds per meter.

For those interested, the device I ordered is: https://www.ebay.com/itm/174136333219

Note that one needs to specify which GNSS system(s) (max of two) you want to use. As I am in the US, I chose GPS+GLONASS.

Re the Adafruit GPS HAT: I recently upgraded my old GPS HAT to the current GNSS HAT. It is too soon to have precise numbers, but it appears that the accuracy of this HAT, to a 95% confidence level, is a bit under 200 microseconds.

Jim WB6DKH


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Pietro Molina
 

It's a simple text file (XML formatted), so notepad is good to edit.
My suggest is to use notepad+ with XML plugin, It helps to show a friendly view.

Pietro

Pietro (mobile)


Il lun 19 lug 2021, 15:45 Bob Wolters <bobw5xc@...> ha scritto:

I have not tried to edit an .ADI file, can someone tell me what additional software to use to edit one ?

 

Thanks again,

 

Bob                    W5XC

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Pietro Molina
Sent: Monday, July 19, 2021 6:42 AM
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

 

Well, the solution by Reino is more elegant.. you won't loose the qso, but only restore the grid as unworked.

 

73

 

I2OIM

Pietro (via Tablet)

 

Il lun 19 lug 2021, 13:10 Reino Talarmo <reino.talarmo@...> ha scritto:

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA



 

Virus-free. www.avg.com

 





locked Re: Clock Sync #Timesync

Joe
 

Hi Jim,

"If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter."

Let's see...  the speed of light is 3 x 10^8 m/s, so the delay in a 1 meter cable is 1.0/(0.8x3x10^8) = 4.2 x 10^-9.  I make it around 4 nanoseconds, not 250 microseconds.  But you're certainly right, the cable delay is well under a millisecond.  :-)

  -- 73, Joe, K1JT


locked Re: Clock Sync #Timesync

 

Thanks Jim.  As I suspected, there was much I didn’t understand.  One good point is that the new USB3 cable is much better quality than the old one.

 

As part of my military service I was a calibration team chief.  Our time/frequency reference was via a VLF time signal supplied by NBS and broadcast courtesy of the Navy.  That was 1975 time frame.  How far have we come.

 

I will remove the older GPS puck.  It has been concerning me anyway. 

 

I am in the middle of a rebuilding a Raspberry Pi 2 and I have the Adafruit GPS hat.  If I can get that working, I will discontinue using the pucks.  Prices do change and the Adafruit hat ran $62 with shipping, but it will be an interesting project.  Thankfully there is an abundance of help from those who have already accomplished this project to guide me.

 

__________

Dan – K4SHQ

CFI/II

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Jim Pennino via groups.io
Sent: Monday, July 19, 2021 10:55 AM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Clock Sync #Timesync

 

In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.

Jim WB6DKH


locked Re: Clock Sync #Timesync

Robert Lorenzini
 

Which GPSDO did you settle on Jim? I have a BG9 clone and a Bodnar. The BG9 osc has drifted
beyond where it can be corrected but I'm still using the NMEA for position only.

Bob - wd6dod

On 7/19/2021 8:55 AM, Jim Pennino via groups.io wrote:
In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.

Jim WB6DKH




locked Re: Clock Sync #Timesync

Jim Pennino
 

In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.

Jim WB6DKH


locked Re: Contest mode? #ContestMode

George J Molnar, KF2T
 

One enhancement that might help in this situation is to build a call queue that allows multiple callers to be stacked and worked either sequentially or from a pick list by the operator. The progress of each contact could be maintained so that in QSB or scatter situations, contacts could “interleave” a little bit to improve rate.  Rare grid rovers, expeditions, and other popular stations could benefit. 


Having a blast on the radio. Thanks to all!

George/KF2T

7401 - 7420 of 34101