Re: ProgRock not working #progrock

Robin Midgett
 

Hans & the group,
An update: Exchanging the RC values on the 555 has shown that the 555 latency isn't causing the frequency error I'm experiencing. I'm now in the region of 400nS latency at the 555 stage with a 33mS long output pulse (2.75nF cap & 10MOhm resistor), and I still have a 18-19 Hz. discrepancy (low) in the output frequency. The output frequency is very stable, just low. This is with reg. 3 set to 0, and reg. 2 is recorded at 27,003,057, which is bogus. I say it's bogus because if I take the GPS correction out of the picture by setting reg. 3=50, which gives me time to experimentally find the correct value for reg. 2, then the ProgRock will run spot on frequency, temperature changes not withstanding. That value is 2=27003024 for my ProgRock. 

Whenever I put the GPS back into the scheme (reg. 3=0) regardless of the pulse width above 11mS going into the ProgRock, it drives reg 2 to 27,003,057, and the result is a very stable 18-19 Hz. low 15 MHz output.

To be clear without a schematic, the wire up is:
Trimble Resolution T GPS 1PPS output (positive going 2.8V logic 1mS wide) driving the base of a 2N3904 for an inverted output at 5v logic level;
Inverted 5v logic into 555 monostable pulse stretcher giving 33mS high output for every 1mS pulse from the GPS; this output drives the 1PPS input of the ProgRock.
Using a modern oscilloscope I measure a 400nS latency in the 555, which would be irrelevant in the ProgRock output based on 1 Hz.error/µS latency.
I then decided it'd be better to measure the overall latency from the GPS pulse to the 555 output; ~750nS, so not even 1 Hz. output error, based on 1 Hz./µS. In the photo below, the yellow trace is GPS output, blue trace is 555 output going into ProgRock.

It'll be interesting to see if the QLG1 solves the 18 Hz. discrepancy I'm measuring repeatedly. 
If only my rifle marksmanship was as repeatable as this....

And just to reiterate...I can live with the error for my application. I'll either make the adjustment in the frequency programming or leave it as is. I just really wonder what's going on...curious, ya' know.

TEK00001.PNG
 

Robin Midgett K4IDC


On Fri, Jul 19, 2019 at 9:28 AM Robin Midgett <K4IDC@...> wrote:
Hi Hans,
The inverter & level shifter are the same stage..a simple 2N3904. The shifter is needed to bring the 2.8V logic 1PPS from the GPS to 5V logic level, and the coincidence is that it's inverted logic is needed by the input to the 555. Propagation delay for a 2n3904 is specified in the 40nS range. There are no caps on this stage.

There is a latency associated with the 555 and that's the time shown in the oscilloscope photograph in my previous post. That latency scales with the chosen RC value for the 555 one shot. In that photo I was using 10uF & 10K which gave a ~110mS pulse width.

You'd indicated in an earlier email exchange that the minimum acceptable pulse width of the 1PPS ProgRock input is unknown. I'm experimenting with different RC values on the 555 & can report that, latency issues notwithstanding, 14mS seems to work well thus far, using 1uF & 10k on the 555.

Yes, I suspect the QLG1 will make my ProgRock work properly.
Thanks,
Robin Midgett K4IDC


On Fri, Jul 19, 2019 at 1:37 AM Hans Summers <hans.summers@...> wrote:
Hi Robin

If you have an inverter in there as well... then that's also a problem :-/     The leading edge of the 1pps from the GPS is the one that is considered accurate. There's no guarantee about the trailing edge. 

If there was a latency that was fixed precisely, then all would be well. But if you have Resistors and Capacitors in there that are generating the stretching, and triggering off the wrong edges... then all bets are off.... 

I suspect that when you get your QLG1 you will find all works as expected. 

73 Hans G0UPL

On Thu, Jul 18, 2019 at 6:24 PM Robin Midgett <K4IDC@...> wrote:
Hi Hans,
Do you mean like this? :>)
This morning the error at 16.686600 MHz was 14 Hz. In other words, I set register 8 to 16,686,614 to obtain a measured output of 16,686,600. Doubling that output frequency resulted in a doubling of the error, doubling again, same error factor. Then I set about measuring the latency...probe 1 is the output of the level shifter/inverter stage that is connected to the input of the 555. Probe 2 is the 555 output.

TEK00000.PNG

Now....what to do about it? Perhaps a pulse stretcher with a Schmitt trigger input? 
I'm more of an analog guy, so this experience is really helping me learn. This is fun!
Thank you, Hans! 
Thanks,
Robin Midgett K4IDC


On Wed, Jul 17, 2019 at 10:40 PM Hans Summers <hans.summers@...> wrote:
Hi Robin

Is there a possibility your 555 pulse extender circuit could also be adding variable latency to the pulse? It would not take very much error... bear in mind, every 1us is 1 part-per-million error at the output. 

Anyway it will be interesting to see how things go once you get your QLG1

73 Hans G0UPL

On Thu, Jul 18, 2019 at 12:44 AM Robin Midgett <K4IDC@...> wrote:
Hi Hans,
Thanks for the response.
I'd really like to understand what's causing this issue & what to do about it.
Presently I have the Trimble GPS 1PPS 2.8V logic 1mS pulse driving a level shifter to a 5V logic level and also providing the needed inversion for driving a non-retriggerable 555 one shot. The 555 is giving a 112mS long positive going 5volt pulse for every 1PPS from the Trimble GPS. I'm applying the 112mS pulse to the GPS input on the ProgRock. In this configuration, register 2 is being updated to a value that causes the output frequency to run low of the desired by ~18 Hz.
If I remove the 1PPS, ground the 1PPS input on the ProgRock & reboot the ProgRock, then manually dial in register 2 to give the proper output frequency, it'll stay there within a couple of Hz. over a period of many hours if not days, thermal effects not withstanding.
It seems to me that under GPS discipline the frequency of the crystal is being mis-read, or there's some magic in register 28 that needs to be adjusted; these are my guesses at this point.

My primary reason for the 555 is to allow me the opportunity to experiment with different pulse widths. Since the QLG1 gives 100ms, I started with a value near that. I can trim it to be spot on later, but 112mS is where my particular RC value came to land late last night. I know from experience that 1mS doesn't work, nor does 11mS, at least not as my ProgRock sits currently.

My QLG1 and the OCXO from QRPLabs are in the mail. Once I have those we can see if anything changes. If you have any further suggestions, I'm all ears.

Thanks,
Robin Midgett K4IDC


On Mon, Jul 15, 2019 at 3:33 PM Hans Summers <hans.summers@...> wrote:
Hi Robin, Graham, Sid, all

There have been a lot of posts on this topic and being on vacation at the moment I kind of lost track of where this got to.

ProgRock should work as advertised on the web page and documentation. If it doesn't, something is wrong. 

A GPS disciplined ProgRock should be accurate well within 0.05ppm (note that this parts-per-million specification means that the absolute precision in Hz, scales with frequency). This is what I have seen in all my tests and has been verified by other constructors too. To get the system working does require:

1. GPS correction threshold register must he understood properly. To get maximum precision requires setting the GPS correction threshold register to zero (default is 5Hz). 

2. The 1pps signal needs to be at 5V logic level. Many GPS units have 2.8V logic level outputs and need level conversion. This can be done with pull-up resistors with some care and some inevitable degradation in noise immunity. Or with proper level conversion.

3. The GPS pulse needs to be long enough for the processor to handle it properly. I'm not actually sure what the minimum is. Many common modern GPS modules have 0.1 second positive pulses, these work fine. Some modules with very short pulses e.g. 1 microsecond wouldn't work.

Note that the QRP Labs QLG1 GPS kit http://qrp-labs.com/qlg1 was used in all my testing and works very well. It has 0.1 second positive pulse and it has proper logic level conversion. The QLG1 has a very accurate 1pps specified with max 11 nanosecond r.m.s error.

If the ProgRock isn't performing as expected then something is wrong. That could be an electrical problem (soldering problem, dead component etc); or some issue with the characteristics of the 1 pulse-per-second signal input. 

If there's any question I haven't covered here, please let me know.

73 Hans G0UPL 







On Mon, Jul 15, 2019, 16:31 Robin Midgett <K4IDC@...> wrote:
Hi Graham & the group,
The issue Sid & I and possibly others who aren't reading the mail on this subject isn't about stability with the TCXO or OCXO. The stability with those optional oscillators is well documented and not in question, and for a broad range of applications, mine included, well more than sufficient.
The issue here is making the ProgRock work reliably with GPS discipline, and why that isn't happening reliably.
Diatribes about the NEED for GPS discipline in anyone's application are irrelevant simply because the fact is the product doesn't perform reliably as advertised with GPS discipline, and, very importantly, within the context of kit building and the price of the kit, this is not a deal breaker or terribly surprising. This is part of the value of kit building; the builder has the opportunity to improve the kit as they see fit, or not.
What is perhaps more interesting and worth studying is why the GPS discipline isn't as reliable as it should be, and what's to be done to mitigate that deficiency. Based on the current responses to our (Sid & my) posts, Hans may be the only person qualified to really answer the questions regarding the apparent deficiency.
Further, personal attacks are not helpful, Andy Brilleaux. Let's leave those for the elementary school playground. Let's approach this issue scientifically and see if a successful solution can be had. I suspect it can and will.
Thanks,
Robin Midgett K4IDC


On Sun, Jul 14, 2019 at 3:15 PM Graham W <gram.warrington@...> wrote:
I have built a few prog rocks. I did not use the 27 mhz crystal as supplied, but installed a TCXO as suggested in the manual. I find ,even without GPS control that it is very stable. The pads are already there for the TCXO.
Graham VE3WGW

Join QRPLabs@groups.io to automatically receive all group messages.