Date   
Re: ProgRock not working #progrock

w7qjq
 

for Alan de G1FXB
If you are going to quote my text, please don't edit it to make me sound like an idiot. 
What is the purpose for all the "?????" that you added? 

You said:
"I stand by a belief a OCXO reference is more preferable than applying correction to a less stable source.
 If a normal SI5351 module is used then best case construction applies, give the controller the easiest possible job.
 With thermal masses (others use the term heatsinks ;-)) & avoiding draughts....
 With GPS correction there needs to be a trade off between the choice of continuous discipline (reloading Reg2 every sec) or allowing an determinable amount of drift but maintaining a stable 50/50 duty cycle in the mean time. Ideally you don't want to have to recalculate Register 2, ever........"

I agree that stabilizing the xtal temp would allow for less frequent corrections.  But that is not the issue, the issue to me is that the controller is not making the necessary corrections.  Please look at my Photo 2.  I can  open the loop by removing the 1PPS and insert my self at the keyboard to close the loop by loading Reg 2 with whatever value is required to bring the CLK0 freq back to 10 MHz to within about 0.37 Hz.  (the Reg 2 resolution is 1 Hz at 27 MHz which is     10  / 27  =  0.37 Hz  at 10 MHz).
But I don't have the patience to have to do this every few minutes, or hours, or days depending on how well I am controlling the xtal temp (or using an OCXO or whatever).  I want to let the controller use the 1PPS to do this for me...it's called disciplining an oscillator.
You continue:
"Maybe phase disturbance caused in the discipline process has more than an influence in the counter readings than it first appears / more so if clashing with the gate period?
 (It's something that often gets omitted in many discussions.... )"

Yes, thank you, I am aware that when Reg 2 changes (either from the ATtiny84 or from the keyboard) that the current 10-sec count is to be disregarded.  Further, the visual info given by the technique of Photo 3 is as good or perhaps better than the counter value.

*******************************************************
for geoff M0ORE
you said:

"I think that it should be borne in mind that some builders are attempting to achieve stability from a unit costing a few dollars, in some cases the cost of a mug of coffee, that professionals spend thousands of dollars to achieve."

This builder was/is expecting to "...achieve stability from a unit costing a few dollars..." that was given on the web site.

and:

"The crystals supplied are standard computer grade units which are not intended to be used as a frequency standard, just to give timing signals for a micro-processor."

Nowhere in the ProgRock description does is say, nor do I expect,  that the 27 MHz xtal is a "frequency standard".  The Si5351 does not measure the xtal freq.  It wants only two numbers (aside from some house-keeping stuff) from the controller...  the desired CLK0 freq and  the measured (by using the 1PPS) xtal freq.

The "... just to give timing signals for a micro-processor." is a non sequitur, the only microprocessor involved uses its internal RC oscillator.

And finally:

"If you want to measure the stability of anything, you need to have the test equipment better than the unit you are testing to get any meaningful results. In the case of frequency, what standard are you going to use??"

I have twice given this information, but here comes number three...
"...my frequency standard is a Trimble ICM-SMT GPSDO and my ultimate 'sanity check' is the 10 MHz xmtr at WWV in Colorado."

Sid




 

 

Re: QCX capacitors

morseoneuk
 


Thanks for the suggestions... As the luck of the Irish goes.. after a thorough search through my parts drawer..
. I found one proper spec...  
best regards  Scotty Gi0bey..

On Saturday, 13 July 2019, 14:14:44 BST, Michael Babineau <mbabineau.ve3wmb@...> wrote:


Scotty : 

One option would be to install a 33 pF cap at C17 and then tack-solder a 4.7 nF across it on the bottom of the board.
That should be close enough. 

Michael VE3WMB

P.S. If you have the means to measure capacitance with some accuracy, you might even pick a 4.7 nF cap that  that read a little bit high
to get you closer to 39 pF.  

#QCX 3.3nF (332) C15/C53 needed #qcx

Dan Rahn
 

One of my kits seems to be missing (or I lost while unpacking the kit, my money is on the latter) the 3.3nF (332) capacitor. Does anyone happen to have any spares they would be willing to mail me in exchange for a couple bucks for the trouble? If not, does anyone know the specs (voltage & dielectric type) on these so I can try and source some? Thanks!

Re: QCX capacitors

 

Scotty : 

One option would be to install a 33 pF cap at C17 and then tack-solder a 4.7 nF across it on the bottom of the board.
That should be close enough. 

Michael VE3WMB

P.S. If you have the means to measure capacitance with some accuracy, you might even pick a 4.7 nF cap that  that read a little bit high
to get you closer to 39 pF.  

Re: Keyer Issue with QCX - missing or short dahs

Rex Vokey
 

Thank you all for your replies so far. 

Dropping elements is what I'd expect if the keyer didn't have dot/dash memory, but as far as I know, the keyer on the QCX was designed to have it. I use my paddle the same way on other rigs with no issues. I haven't tried another QCX yet - I'll have to see if I can get my hands on a friend's. 

73,
Rex KE6MT

Re: Keyer Issue with QCX - missing or short dahs

Bill Cromwell
 

Hi,

From days gone by...

You can't put ten pounds of balony in one pound sack.

73,

Bill KU8H

On 7/13/19 2:35 AM, Peter GM0EUL wrote:
I think that's probably completely normal.  There is no keying buffer to remember the paddle input, you have to key at the same speed as the keyer, if you get ahead of it it won't see your inputs and it'll accept the next input it's ready for.  I don't think there's anything wrong. Setting the keyer speed tells it when to expect inputs, you still have to send the input at the appropriate time to trigger the next element.
Hope this helps, sorry if I've misunderstood the issue.
73
Peter GM0EUL
--
bark less - wag more

Re: QCX capacitors

morseoneuk
 

Thanks Curt,
I have disc ceramic to that value, but would prefer to keep it to Hans original choice of component..
I will keep digging... I do have 33nf and 47nf.. Multi layer ceramic caps,.    but the 39nf  eludes me at the moment .
Best regards to the group...  Scotty

On Saturday, 13 July 2019, 12:14:36 BST, wb8yyy via Groups.Io <wb8yyy@...> wrote:


Looks to me being in the audio filter its capacitance accuracy is paramount.

Curt

Re: QCX capacitors

@CurtisM
 

Looks to me being in the audio filter its capacitance accuracy is paramount.

Curt

Re: ProgRock not working #progrock

geoff M0ORE
 

I think that it should be borne in mind that some builders are attempting to achieve stability from a unit costing a few dollars, in some cases the cost of a mug of coffee, that professionals spend thousands of dollars to achieve.

The crystals supplied are standard computer grade units which are not intended to be used as a frequency standard, just to give timing signals for a micro-processor.

If you want to measure the stability of anything, you need to have the test equipment better than the unit you are testing to get any meaningful results. In the case of frequency, what standard are you going to use??


On 13/07/2019 08:20, Alan de G1FXB via Groups.Io wrote:
Hi Sid,
Not unclear, but yes we differ in our beliefs.

I stand by a belief a OCXO reference is more preferable than applying correction to a less stable source.
If a normal SI5351 module is used then best case construction applies, give the controller the easiest possible job.
With thermal masses (others use the term heatsinks ;-)) & avoiding draughts....
With GPS correction there needs to be a trade off between the choice of continuous discipline (reloading Reg2 every sec) or allowing an determinable amount of drift but maintaining a stable 50/50 duty cycle in the mean time. Ideally you don't want to have to recalculate Register 2, ever........

I do note(!) Your observations show " Reg 2 can be seen changing the 27,004,xxx MHz as expected.?? After another few minutes the Reg 2?? value settles and the CLK0 freq will be 10MHz +/-???? 2 or 3 Hz .?? But the CLK0 freq will not remain at any freq for very long...just a degree or two temperature change will start it moving and the Reg 2 value will not change as necessary to correct the error.?? The only times that the error is zero (+/-?? 0.1Hz) is?? when the Reg 2 value and the changing temperature just by chance allow it "

In the prog rock ge mastr exec ii thread Hans promises " When all is well you should be well within 0.05ppm. "

Maybe phase disturbance caused in the discipline process has more than an influence in the counter readings than it first appears / more so if clashing with the gate period?
(It's something that often gets omitted in many discussions.... )


Hans has said there are both,? register options and potential to further improve the F/W given time.....
https://groups.io/g/QRPLabs/message/27419

?I'll take a back seat and let the others contribute to their findings.


Alan


On 13/07/2019 06:26, w7qjq wrote:
Good evening Alan,
>"It would be useful to know What settings other than the defaults have you entered?
>for instance the default settings allows for +/- 5Hz inaccuracy before discipline is applied."

I answered than in my original post ( line item 4 in "Some additional details...)

Beyond that:-
One of us is unclear as to what a disciplined oscillator is...
To me, and the reason I built this project, was I was led to believe that as the xtal drifted, the CLK2 signal (CLK0 / 8) would be compared is some manner to the 1PPS reference from the GPS and when an error was detected, the controller (ATtiny84) would load a 'better' value to Reg2 (the xtal freq) to bring the CLK0 freq back?to 10 MHz.
?This is clearly not happening.? The solution has nothing to do (or SHOULD have nothing to do) with trying to thermally stabilize the xtal.? Either the discipline scheme works and the CLK0 stays on 10 MHz or it doesn't.? If the scheme doesn't work, then why bother with the controller...get rid of it and go with an insulated box, or a temperature-controlled xtal, or picking a different xtal, or........

>Regarding your measurements,
>How does the Progrock perform when compared against WWV to produce a beat note and
>measurement using for instance ARGO Or Spectrum Lab App?

I discussed than in my original post with words and photo.? Again... my frequency standard is a Trimble ICM-SMT GPSDO and?my ultimate 'sanity check' is the 10 MHz xmtr at?WWV in Colorado.

Sid



QCX capacitors

morseoneuk
 

Hi. I'm having no joy sourcing a replacement for C17 39nf 393 capacitor.
how critical is it to use the mlcc type? can I use a disc ceramic? or what can I use?
regards Scotty gi0bey

Re: ProgRock not working #progrock

Alan de G1FXB
 

Hi Sid,
Not unclear, but yes we differ in our beliefs.

I stand by a belief a OCXO reference is more preferable than applying correction to a less stable source.
If a normal SI5351 module is used then best case construction applies, give the controller the easiest possible job.
With thermal masses (others use the term heatsinks ;-)) & avoiding draughts....
With GPS correction there needs to be a trade off between the choice of continuous discipline (reloading Reg2 every sec) or allowing an determinable amount of drift but maintaining a stable 50/50 duty cycle in the mean time. Ideally you don't want to have to recalculate Register 2, ever........

I do note(!) Your observations show " Reg 2 can be seen changing the 27,004,xxx MHz as expected.?? After another few minutes the Reg 2?? value settles and the CLK0 freq will be 10MHz +/-???? 2 or 3 Hz .?? But the CLK0 freq will not remain at any freq for very long...just a degree or two temperature change will start it moving and the Reg 2 value will not change as necessary to correct the error.?? The only times that the error is zero (+/-?? 0.1Hz) is?? when the Reg 2 value and the changing temperature just by chance allow it "

In the prog rock ge mastr exec ii thread Hans promises " When all is well you should be well within 0.05ppm. "

Maybe phase disturbance caused in the discipline process has more than an influence in the counter readings than it first appears / more so if clashing with the gate period?
(It's something that often gets omitted in many discussions.... )


Hans has said there are both,? register options and potential to further improve the F/W given time.....
https://groups.io/g/QRPLabs/message/27419

?I'll take a back seat and let the others contribute to their findings.


Alan


On 13/07/2019 06:26, w7qjq wrote:
Good evening Alan,
>"It would be useful to know What settings other than the defaults have you entered?
>for instance the default settings allows for +/- 5Hz inaccuracy before discipline is applied."

I answered than in my original post ( line item 4 in "Some additional details...)

Beyond that:-
One of us is unclear as to what a disciplined oscillator is...
To me, and the reason I built this project, was I was led to believe that as the xtal drifted, the CLK2 signal (CLK0 / 8) would be compared is some manner to the 1PPS reference from the GPS and when an error was detected, the controller (ATtiny84) would load a 'better' value to Reg2 (the xtal freq) to bring the CLK0 freq back?to 10 MHz.
?This is clearly not happening.? The solution has nothing to do (or SHOULD have nothing to do) with trying to thermally stabilize the xtal.? Either the discipline scheme works and the CLK0 stays on 10 MHz or it doesn't.? If the scheme doesn't work, then why bother with the controller...get rid of it and go with an insulated box, or a temperature-controlled xtal, or picking a different xtal, or........

>Regarding your measurements,
>How does the Progrock perform when compared against WWV to produce a beat note and
>measurement using for instance ARGO Or Spectrum Lab App?

I discussed than in my original post with words and photo.? Again... my frequency standard is a Trimble ICM-SMT GPSDO and?my ultimate 'sanity check' is the 10 MHz xmtr at?WWV in Colorado.

Sid



Re: ProgRock not working #progrock

Alan G4ZFQ
 

To me, and the reason I built this project, was I was led to believe that as the xtal drifted, the CLK2 signal (CLK0 / 8) would be compared is some manner to the 1PPS reference from the GPS and when an error was detected, the controller (ATtiny84) would load a 'better' value to Reg2 (the xtal freq) to bring the CLK0 freq back to 10 MHz.
Sid,

I've not been following too closely but this is what should happen.
I was not satisfied with my Progrock until I realised the default GPS setting was not correct for really fine adjustment. Then, I forget what frequency, (14.996MHz?) was set to within a few tenths of Hz.

Of course if the 27MHz crystal is abnormally unstable for any reason this will not happen. Too much drift will not be compensated to a fine degree. So is this stable?

73 Alan G4ZFQ

Re: Keyer Issue with QCX - missing or short dahs

Peter GM0EUL
 

I think that's probably completely normal.  There is no keying buffer to remember the paddle input, you have to key at the same speed as the keyer, if you get ahead of it it won't see your inputs and it'll accept the next input it's ready for.  I don't think there's anything wrong.  Setting the keyer speed tells it when to expect inputs, you still have to send the input at the appropriate time to trigger the next element.

Hope this helps, sorry if I've misunderstood the issue.

73
Peter GM0EUL

Re: Keyer Issue with QCX - missing or short dahs

Rex Vokey
 

I should note info I forgot to give:

No auto spacing turned on (this doesn't affect this at all either way). 

This is iambic B mode. 

Rex KE6MT

Re: Keyer Issue with QCX - missing or short dahs

Paul AI4EE
 

I don't recall whether you can turn off the auto-complete character feature, but if you can, and it's not off already, turn it off and try sending that way. If that's not it, then I dunno.

On 7/13/2019 12:59 AM, Rex Vokey wrote:
If I send a character fast than the keyer is sending it—for example, if I key "C" on the paddle at around 20-22 wpm, but have the keyer speed set to 16wpm (about what I can semi-comfortably copy), I often get shortened or completely missing "dahs."

For the longest time, I wasn't sure if was my imagination, the way I was using the paddle, or some issue with the paddle.  I eventually ruled these out through practical means (swapping out things as necessary).  But I still wanted to be able to capture this in a way I could share with people.  I'm hoping someone can maybe give some clue of where I can go with this.

This manifests both in practice mode and with actual RF going out.  So it doesn't seem to be RF-related.  I suspected maybe the firmware had some issue with its debouncing, but a firmware upgrade didn't resolve things. 

I finally got around to capturing it on an oscilloscope.  See the attached image.  Unfortunately, it's not a 4-channel scope, so I was only able to capture the "dah" side of the paddle and the RF out.  I'm keying the letter "C" here, at approximately 20-22wpm.  The keyer speed is set to 15wpm.   The top channel is RF out, the bottom is the "dah" side of the paddle. 

Any ideas?

73,
Rex KE6MT


Virus-free. www.avast.com

Re: ProgRock not working #progrock

w7qjq
 

Good evening Alan,
>"It would be useful to know What settings other than the defaults have you entered?
>for instance the default settings allows for +/- 5Hz inaccuracy before discipline is applied."

I answered than in my original post ( line item 4 in "Some additional details...)

Beyond that:-
One of us is unclear as to what a disciplined oscillator is...
To me, and the reason I built this project, was I was led to believe that as the xtal drifted, the CLK2 signal (CLK0 / 8) would be compared is some manner to the 1PPS reference from the GPS and when an error was detected, the controller (ATtiny84) would load a 'better' value to Reg2 (the xtal freq) to bring the CLK0 freq back to 10 MHz.
 This is clearly not happening.  The solution has nothing to do (or SHOULD have nothing to do) with trying to thermally stabilize the xtal.  Either the discipline scheme works and the CLK0 stays on 10 MHz or it doesn't.  If the scheme doesn't work, then why bother with the controller...get rid of it and go with an insulated box, or a temperature-controlled xtal, or picking a different xtal, or........

>Regarding your measurements,
>How does the Progrock perform when compared against WWV to produce a beat note and
>measurement using for instance ARGO Or Spectrum Lab App?

I discussed than in my original post with words and photo.  Again... my frequency standard is a Trimble ICM-SMT GPSDO and my ultimate 'sanity check' is the 10 MHz xmtr at WWV in Colorado.

Sid


Re: Keyer Issue with QCX - missing or short dahs

Jack Brabham - KZ5A
 

I must be missing something here but I would expect that if one operates the paddles at a speed higher then the keyer is set for, the keyer's output would be garbage.

73 Jack KZ5A




On 7/12/2019 10:59 PM, Rex Vokey wrote:
If I send a character fast than the keyer is sending it—for example, if I key "C" on the paddle at around 20-22 wpm, but have the keyer speed set to 16wpm (about what I can semi-comfortably copy), I often get shortened or completely missing "dahs."

For the longest time, I wasn't sure if was my imagination, the way I was using the paddle, or some issue with the paddle.  I eventually ruled these out through practical means (swapping out things as necessary).  But I still wanted to be able to capture this in a way I could share with people.  I'm hoping someone can maybe give some clue of where I can go with this.

This manifests both in practice mode and with actual RF going out.  So it doesn't seem to be RF-related.  I suspected maybe the firmware had some issue with its debouncing, but a firmware upgrade didn't resolve things. 

I finally got around to capturing it on an oscilloscope.  See the attached image.  Unfortunately, it's not a 4-channel scope, so I was only able to capture the "dah" side of the paddle and the RF out.  I'm keying the letter "C" here, at approximately 20-22wpm.  The keyer speed is set to 15wpm.   The top channel is RF out, the bottom is the "dah" side of the paddle. 

Any ideas?

73,
Rex KE6MT


Keyer Issue with QCX - missing or short dahs

Rex Vokey
 

If I send a character fast than the keyer is sending it—for example, if I key "C" on the paddle at around 20-22 wpm, but have the keyer speed set to 16wpm (about what I can semi-comfortably copy), I often get shortened or completely missing "dahs."

For the longest time, I wasn't sure if was my imagination, the way I was using the paddle, or some issue with the paddle.  I eventually ruled these out through practical means (swapping out things as necessary).  But I still wanted to be able to capture this in a way I could share with people.  I'm hoping someone can maybe give some clue of where I can go with this.

This manifests both in practice mode and with actual RF going out.  So it doesn't seem to be RF-related.  I suspected maybe the firmware had some issue with its debouncing, but a firmware upgrade didn't resolve things. 

I finally got around to capturing it on an oscilloscope.  See the attached image.  Unfortunately, it's not a 4-channel scope, so I was only able to capture the "dah" side of the paddle and the RF out.  I'm keying the letter "C" here, at approximately 20-22wpm.  The keyer speed is set to 15wpm.   The top channel is RF out, the bottom is the "dah" side of the paddle. 

Any ideas?

73,
Rex KE6MT

Re: ProgRock not working #progrock

Alan de G1FXB
 

Hi Robin,


"? It is far more stable & accurate without GPS discipline; I have the standard issue crystal, the die cast aluminum housing (Bud 234) for the project & a 5 volt TO-220 regulator thermally bonded together in close proximity. The indoor room temperature is stable within 5?F. When operated in this mode (no GPS discipline), I find the ProgRock to run within 5-10 Hz. of desired frequency. Like your set up, my power supplies are clean. "
the sweet spot for stable operation of cheap xtals tends to be around 45 DegC but needs to be found for each individual xtal by experimentation,
https://groups.io/g/QRPLabs/message/35232
https://groups.io/g/QRPLabs/message/35242
heating
the xtal to some arbitrary level above ambient using the 5V regulator perhaps yields minimal improvements especially as the xtal and improvised heater combo would also be losing heat to the thermally bonded diecast enclosure described??
It very likely could be improved by use of the dedicated OCXO type module (if for no other reason than the Discrete Colpitts Osc, Buffer stage so negating loading changes from within the Si5351
and adj temperature controlled oven.)

Please report back when you have characterised the results once your OCXO & QLG1 arrive.
(Remember you may need to revisit the PSU circuit of the progrock with the OCXO option, depending how you have the power feeds to the synth / 3.3v regulator & noise filter currently configured.)
"? Clearly, some of these boards aren't quite ripe for use under GPS discipline. "
(
There are no particularly frequency conscious components actually on the progrock PCB?
The ATtiny84 AVR uses a RC Oscilator to clock it's program cycles. with no particular requirement for it's Osc frequency accuracy.
If the progrock programs the CLK0-1 outputs correctly on yor build it is perhaps a confidence "pass" to it's functionality.
Beyond the firmware settings, (Like Sid, note that the default settings allow a measure of drift before applying correction) building your second progrock kit is unlikely to provide a cure,
As you already have it to hand and it's socketed, substitute the AVR IC and see if anything changes.)

Hans never seemingly uses any special GPS Types. Timing optimised, or other for his testing.
Just what ever the current QRP-Labs offered at that time, a
double check of your results with the Trimble against the QLG1 is good check to a known GPS RX.
(
although you really shouldn't have to if you have tried it both alone and with a pulse stretcher.....
I
n the past it sold the VK16 GPS module using the then "new kid on the block" SiRF III chipset, and perhaps one that with hindsight gained a reputation for it's rather indifferent PPS signal.
http://qrp-labs.com/ultimate3/u3info/u3hp.html
But still performed adequately with some choice firmware settings.....

Just because GPS discipline is an option, do you need to use it? perhaps that's worth a further trial.
Others have proven a free running OCXO Kit can produce 0.5Hz accuracy over many hours.
I believe the discipline operation and arithmetic accuracy are handled differently in the Progrock to that of the U3S / VFO kits. (other than the obvious different processors...
Only Hans will know the In / out's of that and which has the greatest "on paper" resolution and under what conditions )

Other builders took the commercial SMD style TCXO route seeking accurate HF QRSS or VHF WSPR operation with their U3S,
only to re-discover after a couple of different threads that a correctly set up OCXO was perhaps the best choice,
https://groups.io/g/QRPLabs/message/32058
https://groups.io/g/QRPLabs/message/32062
https://groups.io/g/QRPLabs/message/32083
https://groups.io/g/QRPLabs/message/35214
" I have recently relocate the mept into the summer house (AKA a shed) since that I have noticed a lot more thermal drift over a 24hr period, at night when its cold it drift up in freq and on a hot day it drifts down (about 25hz max over the swing so about +/-? 15 hz or so) "
https://groups.io/g/QRPLabs/message/35310
" I was getting about 15 hz drift over night when the ?summer house? (shed really)? got cool over night, it was also drifting the other way when its hot (high freq drift when cold, low freq drift when hot ) well I recalibrated the OCXO and did find it was past the flat part of the curve and the current was rather high, I reset it and found a lower current setting (about 150mA give or take a bit) which seemed to be on the flat part of the curve. Its been running in the shed since about 4pm yesterday and I have been monitoring it with Argo set to 30 sec dots slow (0.1Hz steps at that speed) .
I am pleased with its performance the worst drift was about 0.5Hz over that time and now back to the point it started
"
or
https://groups.io/g/QRPLabs/message/32396
another free running OCXO build
" On an overnight run, with typical California indoor temperature changes, I occasionally saw beat frequencies ranging from 0.014 to 0.067 Hz, which yields a peak relative drift of about 5 ppb (= 0.005 ppm). That's amazing! "
or
https://groups.io/g/QRPLabs/message/30301
https://groups.io/g/QRPLabs/message/30555


" My desire for this oscillator is a base for a set of propagation beacons, so frequency accuracy & stability are of high interest & desire. "
+/- half a hertz at say 10MHz you will be in good company,
If you are looking for your own "local" signal source with accuracy to traceable to NIST, it may require more than a progrock, even if driven with the best PPS signal.
?You may need need to visit the time nuts forum where a lucky few discuss home labs, and their primary standards and others just make do..... ? :-[

Alan

On 12/07/2019 14:45, Robin Midgett wrote:
Hello Sid & the group,
Sid, you're not alone. I can't seem to get my ProgRock to be stable with GPS discipline. It is far more stable & accurate without GPS discipline; I have the standard issue crystal, the die cast aluminum housing (Bud 234) for the project & a 5 volt TO-220 regulator thermally bonded together in close proximity. The indoor room temperature is stable within 5?F. When operated in this mode (no GPS discipline), I find the ProgRock to run within 5-10 Hz. of desired frequency. Like your set up, my power supplies are clean.

Presently, I have a solid, clean 11.7mS wide 1PPS at 4.15V going into the 1PPS input of the ProgRock. This is after having level shifted it up from the 3.3V 1PPS output of the Trimble Resolution T GPS, which is noted for it's accurate 1PPS output. The native output pulse width of the GPS is 1mS. Not being able to achieve results even close to expectations, and based on info from Hans, I stretched the 1PPS pulse width from 1mS to 11mS and shifted the level up. Perhaps worth noting is that the unloaded output voltage from the level shifter stage is a solid 5 volts, but when connected to the ProgRock it falls to 4.15V. I don't know if that is proper or not, but I noted from Sid's post that the QLG1 output is a full 5 volts, and his GPSD ProgRock isn't working as expected.

Querying the registers under GPS discipline I find Reg. 2 to be updating, but still the oscillator behaves like a wayward soul on an Australian walkabout; as much as 9kHz off frequency over 8 hours. By comparison, without GPS, the oscillator is usually less than 10 Hz. from the target over a similar time span. Clearly, some of these boards aren't quite ripe for use under GPS discipline.?
I have a second kit presently unbuilt; I'm curious to see if there will be a difference. I also have the QLG1 & OCXO on the way from QRPLabs; perhaps those changes will put this kit on the right track.
My desire for this oscillator is a base for a set of propagation beacons, so frequency accuracy & stability are of high interest & desire.

Thanks,
Robin Midgett K4IDC

Re: prog rock ge mastr exec ii

Robin Midgett
 

Hi Hans,
I've taken your very good recommendations into account & still no joy. Please see my reply in message # 36114.
Thanks,
Robin Midgett K4IDC


On Fri, Jul 5, 2019 at 6:42 AM Hans Summers <hans.summers@...> wrote:
Hi Robin

Several comments:

1. ProgRock was developed in conjunction with the QRP Labs QLG1 GPS http://qrp-labs.com/qlg1 which has 100ms (0.1ms) positive-going pulse. Though if your pulse-length is 1ms I would not expect there to be problems... but couldn't know for sure without testing it. I know something very short like a microsecond would be an issue. But a millisecond is relatively ages...

2. Watch out for voltage level problems. Most GPS chips operate at 2.8V supply, the ProgRock operates with 5V supply. The logic level threshold for a "1" is 3V if I recall correctly. Therefore with many GPS module models you need a level converter. A pull-up resistor to +5V can do the job often but you need the right resistor value. And even then, the noise immunity suffers compared to a "real" level converter. The QLG1 kit has a proper logic level converter so with its 5V logic outputs you never have an issue. 

3. A heatsink on the crystal helps with thermal stability. So does putting the project in an enclosure to avoid drafts etc. 

4. ON/OFF keying... are you aware of the frequency bank feature of ProgRock? There are three logic inputs, the permutations of high/low control signals in these allow you to choose one of three banks of output frequencies. If any frequencies are zero the output is just disabled. So it is often quite convenient to uses these logic level inputs to on/off key the output frequency you want.

5. Read the manual section about the GPS correction threshold register. For finest precision you want this to be 0Hz. The default is 5Hz which means the correction is only applied when the error if the 27MHz value exceeds 5Hz.

When all is well you should be well within 0.05ppm.

73 Hans G0UPL 


On Fri, Jul 5, 2019, 03:49 Robin Midgett <K4IDC@...> wrote:
Hi Jim,
Not a MASTR Exec, but a low band MASTR II mobile for use as a 6m beacon. I'm working on using the ProgRock in place of the crystal in the channel element. Once I get the low band beacon going in good order, I plan to expand to 2m, 1.25cm & 70 cm. I started this project over a year ago, set it aside for several months, and just today returned to it.

I plan to inject the RF from the ProgRock directly into the channel element connections on the exciter board, and key it on/off with a small memory keyer. It works just fine using a simple relay to key, but I want a solid state switch instead of a mechanical relay, so I've been working toward that.

I tried inserting the on/off keying in the bias & tripler circuits downstream of the channel element, but that didn't work well at all; the resulting RF was dirty & splattered across the narrow beacon sub-band. The original mic PTT simply turned the power to the oscillator in the channel element on/off, so that seems to be a good starting point.

Presently I have good stability using the ProgRock stand-alone (no GPS PPS discipline); it's running less than 10 Hertz off my desired frequency. I expected much better performance with GPS 1PPS discipline, but after trying 3 different GPS modules, I've not had better success than without. I'm beginning to question the 1PPS I've been giving the ProgRock relative to the ProgRock 1PPS requirement; perhaps the ProgRock needs a wider pulse width than 1mS, so I'm considering trying a pulse stretcher stage; perhaps 10mS will do the trick.

I did find a significant increase in stability by thermally bonding the 27MHz. crystal on the Si5351A Synth module to the heat sink of the 5V regulator AND the aluminum Bud box enclosure, so if you don't want to deal with the GPS discipline, by all means make the effort to thermally stabilize the 27MHz. crystal & then thermally isolate the ProgRock enclosure from the environment. By the way, it's an inverse relationship...warmer crystal shifts the frequency down. Simply holding my finger on the crystal is enough to move the oscillator. 

QRPLabs offers a OCXO module to replace the crystal on the Si5351A Synth module; you might consider using it. There's info in the archives of this email list on the various issues that may entail. I haven't tried that module so I can say anything about it's performance. 
I'm happy to share anything I learn along the way; feel free to contact me.
Thanks,
Robin Midgett K4IDC


On Tue, Jul 2, 2019 at 5:40 AM Jim via Groups.Io <gl1000gold=yahoo.com@groups.io> wrote:
anyone ever tried a prog rock as a crystal replacement in a ge mastr exec and how was it wired?