?

Hi Chris, thanks for your offer I could start whenever is most convenient for you. I will be using the single mode QRSS kit with a 3.500MHz Xtal.

Vy 73 de Colin DD5CF / G1ZOS

--- In QRPLabs@..., Chris Mac wrote:
>
> Hi there. I'm happy to tune to 80m for a few days if you want a European 80m grabber.
>
> When would you want it to start and what frequency?
>
> Chris.
>
> Sent from Chris Mac's iPhone
> Amateur radio callsign: G?MQW
>
>
> On 21 Oct 2012, at 15:32, "dd5cf_colin" wrote:
>
> > Hi to all members, does anyone know of a grabber for the 80m band?
> >
> > 73 de Colin DD5CF / G1ZOS
> >
> >
>

Hi there. I'm happy to tune to 80m for a few days if you want a European 80m grabber.

When would you want it to start and what frequency?

Chris.

Sent from Chris Mac's iPhone
Amateur radio callsign: G??MQW


On 21 Oct 2012, at 15:32, "dd5cf_colin" <jobaco@...> wrote:

Hi to all members, does anyone know of a grabber for the 80m band?

73 de Colin DD5CF / G1ZOS

?

Hi to all members, does anyone know of a grabber for the 80m band?

73 de Colin DD5CF / G1ZOS

Hi Yannick,

Well done! This is great work and I would be interested in a partial kit. I
am also interested in your idea for a 9850 based DDS. I have a back copy of
QEX somewhere with an article by an Italian ham who drives one with a PIC.
9850 development boards are available from china for 5 Euros in single
quantities e.g.


There are also other DDS modules available based on the AD9833 which are a
bit more expensive but go down to VLF.

73s Steve

Did your's arrive Colin?

On 19 October 2012 16:01, dd5cf_colin <jobaco@...> wrote:

**


Hi Steve, thanks for the reminder


--- In QRPLabs@..., Stephen Farthing <squirrox@> wrote:

Hi Guys,

I just wanted to make sure that there is no one left out there with a

slow

running AVR who has not yet contacted me for a replacement. I shipped

them

to everyone before I left for my holiday a couple of weeks back so you
should all have received them by now. If you have not and not told me
please get in touch by email quoting "Slow running AVR" in the message
header and the number of chips you need and where to send them to in the
text of the message and I'll ship them out tomorrow or Monday morning.

73s Steve G0XAR

Hi Guys,

I just wanted to make sure that there is no one left out there with a slow
running AVR who has not yet contacted me for a replacement. I shipped them
to everyone before I left for my holiday a couple of weeks back so you
should all have received them by now. If you have not and not told me
please get in touch by email quoting "Slow running AVR" in the message
header and the number of chips you need and where to send them to in the
text of the message and I'll ship them out tomorrow or Monday morning.

73s Steve G0XAR

?

Any idea when those of us waiting for the corrected chips will receive them (due to programming error causing x8 slow clock)?

?

Best regards,

?

Gary, K7EK

?

Hi Clint,

Not sure if this is relevant or not, but I am still in the process of finishing off my board and noted a timing issue when running WSPR with the clock free running (v1.5 firmware).

I have fitted a simple positor type crystal heater and after the initial warm up period the frequency is very stable and within 1Hz of where I have set it.

Setting the real time clock manually compared to a MSF clock, I could decode the first couple of WSPR transmissions, but after a period of around 40 minutes the clock had gained 12 seconds, so the start timing was completely wrong and no decoding was possible. Checking the oscillator frequency, this was still the same as the stored frequency (within +/-1 Hz).

Hopefully once I hook up a GPS receiver this will not be a problem, but appears perhaps something is not quite right with the free running RTC.

73, Bob G8VOI

--- In QRPLabs@..., "cctbcn" <turner@> wrote:

Hi Hans,

Thanks for the thoughtful reply!

I'll disable the GPS mode and look to see if the clock accuracy works as it should when free-running: I've not tried that and in retrospect, it would have been a good diagnostic step.

As for the pulse duration, as I mentioned, I did change it to an R/C input - IIRC, a 0.05 uF in with a 10k to ground on the beacon side, this resulting in a much narrow pulse - and this didn't help, but now knowing that you actually look at both sides of the pulse, I can see how this might have an effect.

FWIW, the addition of this circuit did create two pulses - but only one was positive (rising edge) while the other was negative, clamped by the AVR's input protection diodes to about -0.6 volts and I would not expect it to trigger the input as no ringing was evident on the (100 MHz) scope. Nevertheless, I've seen some micros that do funny things on some inputs when they go beyond one rail or the other...

When I get the chance, I'll try lengthening the pulse a bit using the series diode plus cap/resistor. If that doesn't work, I'll tack an edge-triggered timer on the 1pps input so that I can vary the duration of the input pulse from very narrow to much longer than 100 ms.

What is the logic threshold on that input, anyway? I'm asking since the addition of a diode will put the "high" voltage down into the 2.5-2.7 volt area...

* * *

I was curious, however: I suppose that a software menu option could have been "+GPS" or "-GPS" to allow options edge triggering - and the fact that many GPS receivers output microsecond-wide pulses would make the selection generally irrelevant in these cases - assuming consistent pulse length, of course. Why the non-use of edge triggering, then? I've not looked at the data sheet for this chip, but I suppose that maybe it could be an IOC (Interrupt-On-Change) input, polling, or some other reason?

* * *

No problem with the Code Protection: I do that on chips that I sell, too!

Thanks and 73,

Clint



--- In QRPLabs@..., Hans Summers <hans.summers@> wrote:

Hi Clint

There's a lot of information there, I have some things to comment/suggest
etc.

Firstly, I think it would be wise to check that the clock divide-by-8 fuse
problem isn't applicable to your chip. If you switch off the GPS (set it to
Off in the menu), does the kit work Ok? When waiting for the time for a
transmit WSPR frame, the clock should show on the LCD - does it count
normally? If so, then clearly there is a problem only with your GPS unit
not suiting the kit very well, and we have to address that problem only.

- I was able to issue commands to the GPS receiver so that it outputs

ONLY $GPRMC strings. I've tried setting it for updating once per second,
or once every second - no difference.

Yes, I do no think that the problem is with too many sentences in the
serial data stream.

- I've tweaked the 1pps voltage so that it's comfortably within the CMOS

threshold of a device operating from a 5 volt rail - no difference.

3.3V should be Ok for an AVR directly.

- At some point, the seconds count will by synchronized to the 1 second

interval: It may be 1 or 2 seconds off, but the change occurs right on the
1 second interval.

- Over a period of 10-20 seconds, I can visually watch the LCD's

seconds-counter "walk" away from the UTC second, slowing down by about 1/2
second after that period.

- At some point, the LCD seconds will jump and re-synchronize.

Clearly, the "time" on the AVR isn't close enough to allow a free running

clock and it looks like it drifts away from the window rather quickly. I
let the unit run for several hours and not once was I able to get a valid
WSPR decode.

Probably if your clock was really free-running, i.e. if you completely turn
via the "Use GPS" setting, the unit should run for many days. The accuracy
of the clock is limited only by how accurately you were able to tune the
frequency - if it matches the value set in the "Frequency" configuration
parameter, then the timing will be very accurate.

However I have a suspicion about what is going on here. The GPS 1pps input
is not watching either the positive or the negative edge. It actually
triggers an interrupt on BOTH edges. How it decides which one to attend to:
it is looking for a change in signal level which arrives at the right time,
to lock onto. I think the problem here is that your GPS unit has a 100ms
pulse, which is exactly the threshold set in the code, for what is the
"right time". A very short pulse would be Ok, and so would a longer pulse.
But if the pulse length is exactly 100ms, then sometimes it will be
triggering on the rising edge, and sometimes the falling edge - depending
on whether it thinks it is more or less than 100ms long as timed by the kit.

Thinking that the 100ms long 1pps pulse (rising edge coincides with the

second)

I put a series capacitor (0.05uF) with a 10k to ground on the UQRSS side

to turn

it into a brief rising pulse, but this hasn't changed anything, either.

When you added this circuit, I don't think it helped because you
essentially created two brief pulses 100ms apart so the same problem was
there.

I'm not explaining this very well nor can I think of a better way to
explain it right now. But basically I think that your pulse is exactly the
right length for the kit to be getting confused by it and I suspect that
the symptoms you observe are consistent with my understanding of what would
happen if a pulse of 100ms was applied. Less or more is fine, but exactly
100ms is a problem. There has to be a threshold somewhere, and I chose
100ms!

This is suspicion only. I may be wrong. However I think we could prove it
easily enough. In order to test my theory, you should try lengthening the
pulse so it is more than 100ms. You could do it with a 74HC123 etc but I
think the easiest way would be: a diode from the GPS module 1pps signal to
the "Ultimate" kit input, with a small capacitor to ground, and a resistor
across the capacitor. Say 0.05uF and 100K. That should lengthen the pulse
by a few ms, enough to get it away from 100ms. I would be very interested
to see if this helps.

I don't get any ERROR message, so this doesn't exactly fit the "slow

clock" problem, but there's something amiss, here. I do have access to an
Atmel AVR Dragon programmer, so if there's a fuse that can be flipped
(assuming that it's not code-protected) I could try that?

Sorry, it is code-protected. Long story, I won't go over it again here. But
we felt it necessary :-(

73 Hans G0UPL

Hi Hans,

Thanks for the thoughtful reply!

I'll disable the GPS mode and look to see if the clock accuracy works as it should when free-running: I've not tried that and in retrospect, it would have been a good diagnostic step.

As for the pulse duration, as I mentioned, I did change it to an R/C input - IIRC, a 0.05 uF in with a 10k to ground on the beacon side, this resulting in a much narrow pulse - and this didn't help, but now knowing that you actually look at both sides of the pulse, I can see how this might have an effect.

FWIW, the addition of this circuit did create two pulses - but only one was positive (rising edge) while the other was negative, clamped by the AVR's input protection diodes to about -0.6 volts and I would not expect it to trigger the input as no ringing was evident on the (100 MHz) scope. Nevertheless, I've seen some micros that do funny things on some inputs when they go beyond one rail or the other...

When I get the chance, I'll try lengthening the pulse a bit using the series diode plus cap/resistor. If that doesn't work, I'll tack an edge-triggered timer on the 1pps input so that I can vary the duration of the input pulse from very narrow to much longer than 100 ms.

What is the logic threshold on that input, anyway? I'm asking since the addition of a diode will put the "high" voltage down into the 2.5-2.7 volt area...

* * *

I was curious, however: I suppose that a software menu option could have been "+GPS" or "-GPS" to allow options edge triggering - and the fact that many GPS receivers output microsecond-wide pulses would make the selection generally irrelevant in these cases - assuming consistent pulse length, of course. Why the non-use of edge triggering, then? I've not looked at the data sheet for this chip, but I suppose that maybe it could be an IOC (Interrupt-On-Change) input, polling, or some other reason?

* * *

No problem with the Code Protection: I do that on chips that I sell, too!

Thanks and 73,

Clint



--- In QRPLabs@..., Hans Summers <hans.summers@> wrote:

Hi Clint

There's a lot of information there, I have some things to comment/suggest
etc.

Firstly, I think it would be wise to check that the clock divide-by-8 fuse
problem isn't applicable to your chip. If you switch off the GPS (set it to
Off in the menu), does the kit work Ok? When waiting for the time for a
transmit WSPR frame, the clock should show on the LCD - does it count
normally? If so, then clearly there is a problem only with your GPS unit
not suiting the kit very well, and we have to address that problem only.

- I was able to issue commands to the GPS receiver so that it outputs

ONLY $GPRMC strings. I've tried setting it for updating once per second,
or once every second - no difference.

Yes, I do no think that the problem is with too many sentences in the
serial data stream.

- I've tweaked the 1pps voltage so that it's comfortably within the CMOS

threshold of a device operating from a 5 volt rail - no difference.

3.3V should be Ok for an AVR directly.

- At some point, the seconds count will by synchronized to the 1 second

interval: It may be 1 or 2 seconds off, but the change occurs right on the
1 second interval.

- Over a period of 10-20 seconds, I can visually watch the LCD's

seconds-counter "walk" away from the UTC second, slowing down by about 1/2
second after that period.

- At some point, the LCD seconds will jump and re-synchronize.

Clearly, the "time" on the AVR isn't close enough to allow a free running

clock and it looks like it drifts away from the window rather quickly. I
let the unit run for several hours and not once was I able to get a valid
WSPR decode.

Probably if your clock was really free-running, i.e. if you completely turn
via the "Use GPS" setting, the unit should run for many days. The accuracy
of the clock is limited only by how accurately you were able to tune the
frequency - if it matches the value set in the "Frequency" configuration
parameter, then the timing will be very accurate.

However I have a suspicion about what is going on here. The GPS 1pps input
is not watching either the positive or the negative edge. It actually
triggers an interrupt on BOTH edges. How it decides which one to attend to:
it is looking for a change in signal level which arrives at the right time,
to lock onto. I think the problem here is that your GPS unit has a 100ms
pulse, which is exactly the threshold set in the code, for what is the
"right time". A very short pulse would be Ok, and so would a longer pulse.
But if the pulse length is exactly 100ms, then sometimes it will be
triggering on the rising edge, and sometimes the falling edge - depending
on whether it thinks it is more or less than 100ms long as timed by the kit.

Thinking that the 100ms long 1pps pulse (rising edge coincides with the

second)

I put a series capacitor (0.05uF) with a 10k to ground on the UQRSS side

to turn

it into a brief rising pulse, but this hasn't changed anything, either.

When you added this circuit, I don't think it helped because you
essentially created two brief pulses 100ms apart so the same problem was
there.

I'm not explaining this very well nor can I think of a better way to
explain it right now. But basically I think that your pulse is exactly the
right length for the kit to be getting confused by it and I suspect that
the symptoms you observe are consistent with my understanding of what would
happen if a pulse of 100ms was applied. Less or more is fine, but exactly
100ms is a problem. There has to be a threshold somewhere, and I chose
100ms!

This is suspicion only. I may be wrong. However I think we could prove it
easily enough. In order to test my theory, you should try lengthening the
pulse so it is more than 100ms. You could do it with a 74HC123 etc but I
think the easiest way would be: a diode from the GPS module 1pps signal to
the "Ultimate" kit input, with a small capacitor to ground, and a resistor
across the capacitor. Say 0.05uF and 100K. That should lengthen the pulse
by a few ms, enough to get it away from 100ms. I would be very interested
to see if this helps.

I don't get any ERROR message, so this doesn't exactly fit the "slow

clock" problem, but there's something amiss, here. I do have access to an
Atmel AVR Dragon programmer, so if there's a fuse that can be flipped
(assuming that it's not code-protected) I could try that?

Sorry, it is code-protected. Long story, I won't go over it again here. But
we felt it necessary :-(

73 Hans G0UPL

Hi Clint

There's a lot of information there, I have some things to comment/suggest
etc.

Firstly, I think it would be wise to check that the clock divide-by-8 fuse
problem isn't applicable to your chip. If you switch off the GPS (set it to
Off in the menu), does the kit work Ok? When waiting for the time for a
transmit WSPR frame, the clock should show on the LCD - does it count
normally? If so, then clearly there is a problem only with your GPS unit
not suiting the kit very well, and we have to address that problem only.

- I was able to issue commands to the GPS receiver so that it outputs

ONLY $GPRMC strings. I've tried setting it for updating once per second,
or once every second - no difference.

Yes, I do no think that the problem is with too many sentences in the
serial data stream.

- I've tweaked the 1pps voltage so that it's comfortably within the CMOS

threshold of a device operating from a 5 volt rail - no difference.

3.3V should be Ok for an AVR directly.

- At some point, the seconds count will by synchronized to the 1 second

interval: It may be 1 or 2 seconds off, but the change occurs right on the
1 second interval.

- Over a period of 10-20 seconds, I can visually watch the LCD's

seconds-counter "walk" away from the UTC second, slowing down by about 1/2
second after that period.

- At some point, the LCD seconds will jump and re-synchronize.

Clearly, the "time" on the AVR isn't close enough to allow a free running

clock and it looks like it drifts away from the window rather quickly. I
let the unit run for several hours and not once was I able to get a valid
WSPR decode.

Probably if your clock was really free-running, i.e. if you completely turn
via the "Use GPS" setting, the unit should run for many days. The accuracy
of the clock is limited only by how accurately you were able to tune the
frequency - if it matches the value set in the "Frequency" configuration
parameter, then the timing will be very accurate.

However I have a suspicion about what is going on here. The GPS 1pps input
is not watching either the positive or the negative edge. It actually
triggers an interrupt on BOTH edges. How it decides which one to attend to:
it is looking for a change in signal level which arrives at the right time,
to lock onto. I think the problem here is that your GPS unit has a 100ms
pulse, which is exactly the threshold set in the code, for what is the
"right time". A very short pulse would be Ok, and so would a longer pulse.
But if the pulse length is exactly 100ms, then sometimes it will be
triggering on the rising edge, and sometimes the falling edge - depending
on whether it thinks it is more or less than 100ms long as timed by the kit.

Thinking that the 100ms long 1pps pulse (rising edge coincides with the

second)

I put a series capacitor (0.05uF) with a 10k to ground on the UQRSS side

to turn

it into a brief rising pulse, but this hasn't changed anything, either.

When you added this circuit, I don't think it helped because you
essentially created two brief pulses 100ms apart so the same problem was
there.

I'm not explaining this very well nor can I think of a better way to
explain it right now. But basically I think that your pulse is exactly the
right length for the kit to be getting confused by it and I suspect that
the symptoms you observe are consistent with my understanding of what would
happen if a pulse of 100ms was applied. Less or more is fine, but exactly
100ms is a problem. There has to be a threshold somewhere, and I chose
100ms!

This is suspicion only. I may be wrong. However I think we could prove it
easily enough. In order to test my theory, you should try lengthening the
pulse so it is more than 100ms. You could do it with a 74HC123 etc but I
think the easiest way would be: a diode from the GPS module 1pps signal to
the "Ultimate" kit input, with a small capacitor to ground, and a resistor
across the capacitor. Say 0.05uF and 100K. That should lengthen the pulse
by a few ms, enough to get it away from 100ms. I would be very interested
to see if this helps.

I don't get any ERROR message, so this doesn't exactly fit the "slow

clock" problem, but there's something amiss, here. I do have access to an
Atmel AVR Dragon programmer, so if there's a fuse that can be flipped
(assuming that it's not code-protected) I could try that?

Sorry, it is code-protected. Long story, I won't go over it again here. But
we felt it necessary :-(

73 Hans G0UPL

Hi Alex,

There have been a number of firmware versions since v1.02, the full list is
here , but I do not think
that any of the bug fixes are applicable to your case.

I did find the photo you uploaded eventually, you put it in someone else's
folder I think ;-) In case anyone else couldn't find it, it's here in
woodiescbj's folder:



That photo shows message "TEST" in QRSS mode. I do not think there is a
problem here. You can see the strong line when the transmission is on. The
much weaker line when the keying is off, is just your sensitive receiver
picking up the signal from the oscillator, un-amplified. It's normal I
think, no problem. Receiving stations will not pick up the signal from your
crystal oscillator. It's just that you're right next to it.

In the Test mode you should see an FSK square wave as in the manual at
section 9. If you do not - then you need to check what settings you have in
the "FSK (Hz)" setting and the "FSK Adj." setting. Try 5 and 01,000
respectively. If you still see no shift in TEST mode, then I think some
checking of the circuit around the LED is needed.

73 Hans G0UPL



--- In QRPLabs@..., "g7kse" <g7kse@> wrote:

Thanks for the quick response Hans,

hope this helps better diagnose if there is a problem

The software version is 1.02
Kit bought in August
Receiver is connected to PC running Argo
Mode selected (nominally) CW
RF load on kit 20dBm
Rx RF Gain backed off

Powering up is a bit hit and miss - Occasionally it doesn't start up,

sometimes it'll start up with what I assume is a corrupted set of
characters on the LCD. Sometimes its fine. I can't find a fault with wiring
here although any pointers would be helpful

In test mode I was expecting to see the frequency shift every second

(Speed set to 01)with an output on Argo pretty much as per the build
instructions section 7. What I actually get is what looks and sounds like a
carrier without any frequency shift. Or nothing at all.

In CW mode I get a similar situation where I get a constant carrier heard

through the receiver speaker and shown on Argo. The output looks like the
carrier is on and keying produces the correct code but he carrier never
drops off. I'll put a capture from Argo into the photos folder.

Hope this is enough. I will keep on experimenting here and hopefully will

get it sorted out.

Alex, g7kse


--- In QRPLabs@..., Hans Summers <hans.summers@> wrote:

Hi Alex,

I'm sorry but it's not quite clear to me what you're seeing here, and

what

you're expecting to see.

Please can you confirm your version is v1.02? Versions before that had

an

on/off keying problem but that was fixed in v1.02. FYI the full version
history is here: .

You mention the "Test" mode - in this mode the signal should be constant
carrier, with a frequency shift every N seconds where N is the speed
setting you have entered.

How are you monitoring the signal and what load are you using at the RF
output of the kit? Are you using Argo to monitor, or just listening on

the

receiver audio?

I think more information is necessary, to help to either diagnose the
problem, or even if there IS an actual problem :-)

73 Hans G0UPL



--- In QRPLabs@..., "Alex" <g7kse@> wrote:

I've got a little problem that I think isn't a result of my mistake. I

get a constant carrier and can not see anything whilst in test mode. I
don't have sophisticated test gear just a reiver and dmm.

the kit powers up and if I use the cw mode for example there is a

constant carrier on just about the right frequency and the cw dit and

dahs

will go on nicely but the carrier doesn't drop off. Its making the PA

quite

hot and I'm sure (well fairly) it not something I've done. the software
version is 1.2

Any clues?

Alex, g7kse

I've put my 30 meter UQRSS together and have been fiddling with it for a bit now and have noticed something that has me scratching my head.

I'm using a Axiom Sandpiper II GPS module that has a serial output (RS-232, which I have inverted to 5 volt logic) and a 1pps output that goes high (to +3.3 volts) for 100 milliseconds.

The GPS receiver outputs a number of sentences, namely the GGA, GLL, GSV, GSA, RMC and VTG strings: There doesn't appear to be any way to select which ones are emitted.

What I'm observing is that timing of the clock displayed in WSPR mode seems to vary randomly +/- 1 or 2 seconds from actual GPS time and WWV.

What is interesting is that the second displayed on the LCD *is* synchronized precisely with UTC - it's just that it's the wrong second.

I've tried baud rates from 4800 through 38400 and haven't been able to see any difference.

Thinking that the 100ms long 1pps pulse (rising edge coincides with the second) I put a series capacitor (0.05uF) with a 10k to ground on the UQRSS side to turn it into a brief rising pulse, but this hasn't changed anything, either.

One thing that I *do* see happening is that if I stare at the display long enough, I note that the seconds digits occasionally do not advance which explains it occasional lagging: Apparently, it will eventually re-check the time and, unseen by me thusfar, it will pop ahead again - by 1 or 2 seconds in advance of UTC.

So, several questions come to mind:

- Is the 1pps rising-edge sensitive? If so, this would make its duration irrelevant.
- Is the logic threshold on the 1PPS input safely within the range to accommodate 3.3 volt logic?
- Could too many NMEA sentences be doing something internally (e.g. too many recources/interrupts) that might cause the timing to wander excessively?

Since the 30 meter oscillator is on all of the time, I suppose that I could monitor the frequency during the "key up" period if I knew the amount of offset and if there is any repeated self calibration going on - this, to see if the FLL is functioning, or also being affected by the loss of 1pps pulses?

* * *

On an unrelated note, I have observed that occasionally, the CPU (or possibly the display) does not start up when power is applied, but a disconnecting and re-application of power has always been successful.

The recent thread about popped finals brings this to mind: If the oscillator doesn't start up for some reason - and neither does the CPU - then the FET could be turned fully on with no RF drive if the pin were to float high - or even if the CPU was running, but the oscillator outputting a logic state that, when keyed, turned on the FET. Years ago, I designed a LowFER/MedFER power amplifier that used a coupling cap, resistor and diode to protect the FET should a similar event occur!

73,

Clint
KA7OEI