From: [email protected] [mailto:[email protected]] On Behalf Of Ron Carr
Sent: Thursday, June 8, 2017 06:20 AM
To: [email protected]
Subject: [QRPLabs] Mounting the QLG1 inside the case.

?

I know it won't work without modifications, but I am considering cutting a square hole in my case and mounting the GPS just below the top cover.? About the only thing holding me back is my poor metal working skills.?? I have a house with a metal roof and this GPS works so well that it receives 7 to 10 satellites anywhere I put it.?? I don't think there is a need to have it on a long cable mounted where it can see the sky.

Has anyone tried something like this?? And did it work ok?? I suppose the extra metal above the ground plane could de-tune the antenna.?

Ron? K1URC

Simple answer - no.
Complicated answer - no.

;-)

73 de Andy

And, as we have discussing this topic, this morning at least, on
wsprnet.org the spots for CG3EXP show only a 4 character grid for the
first wspr frame and a six character grid for the second wspr frame. for
example

2017-06-08 14:22 CG3EXP 14.097108 -12 -3 FN25pa 0.2 KK1D
2017-06-08 14:20 CG3EXP 14.097110 -15 -3 FN25 0.2 KK1D

Something seems to have changed sometime around 2017-06-08 09:30
(approximately).

Perhaps someone is listening and has taken note !?!

cheers, Graham ve3gtc




On 6/8/2017, "Ron Carr" <rcarr@...> wrote:

Thanks Hans for the write up.?? I am completely sure you are correct that the issue is with the WSPRnet and how it guesses at the extended locator based upon some data it is storing,?? and/or the receiving program is also making guesses.
I noticed a couple of days ago that some of the incorrect decodes were associated with my call.?? In WSJT-X there is a selection in the FIle menu titled "open log directory" and in that directory is a file called ALL_WSPR.TXT?? In that log file I noticed that I had decoded the now incorrect extended locator some time ago and was the first locator I had sent to WSPRNet.?? Although my station was now sending the correct locator for the extended wspr messages,?? when the 4 character messages were received and reported they still showed the incorrect locator I had first sent to WSPRnet.?? I exited WSJT and deleted the log and restarted WSJT.?? I do not know if that helped at all.

For a guess as to what is going on,?? it is easy to envision the WSPRnet software keeping a data table with fields of Callsign, reporting station, and the extended locator.?? And envision some batch process that runs once every few hours to remove old data.

Ron?? K1URC

Thanks Hans for the write up.?? I am completely sure you are correct that the issue is with the WSPRnet and how it guesses at the extended locator based upon some data it is storing,?? and/or the receiving program is also making guesses.
I noticed a couple of days ago that some of the incorrect decodes were associated with my call.?? In WSJT-X there is a selection in the FIle menu titled "open log directory" and in that directory is a file called ALL_WSPR.TXT.?? In that log file I noticed that I had decoded the now incorrect extended locator some time ago and was the first locator I had sent to WSPRNet.?? Although my station was now sending the correct locator for the extended wspr messages,?? when the 4 character messages were received and reported they still showed the incorrect locator I had first sent to WSPRnet.?? I exited WSJT and deleted the log and restarted WSJT.?? I do not know if that helped at all.

For a guess as to what is going on,?? it is easy to envision the WSPRnet software keeping a data table with fields of Callsign, reporting station, and the extended locator.?? And envision some batch process that runs once every few hours to remove old data.

Ron?? K1URC

Hi Graham, Alan,

I can tell you some stuff about the U3S which will hopefully make it
clearer, and will also show why I believe WSPRnet or WSPR decoding programs
have a bug. I know this information is not published anywhere. I really
can't recall how I discovered it but I do remember it took a lot of
digging. Most likely I poked my head inside the PC WSPR software source
code and reverse engineered the rules from that.

Firstly: The Ultimate3S reads the GPS NMEA serial data stream once per
entire transmission cycle. It happens right before the calibration. In the
case of CG3EXP, the U3S sends 12 minutes of WSPR (6 x 2-minute
transmissions, i.e. a pair of WSPR transmissions on each band 40, 30 and
20m). Then it does a calibrate. The GPS position snapshot is therefore
taken at approx 12, 42 and 52 minutes past the hour. One snapshot every 20
minutes. The GPS position is NOT updated for every 2-minute WSPR
transmission.

We have also seen many examples in the data over the last few days, where
the position was reported differently by different stations, in the SAME
2-minute time slot.

Both of these facts individually, exclude any possibility of any GPS QRM,
corruption, jamming etc. It is impossible to explain the observations by
assuming faulty positions from the GPS.

Now to explain about how "Extended mode" WSPR works, in the case where you
wish to send a 6-character Locator (with a normal callsign, such as
CG3EXP).

A reminder first that an ordinary WSPR message consists of a callsign,
4-character locator, and power level in dBm. The power level is from 0 to
60dBm and only 0, 3, 7, 10, 13, 17 etc are allowed. These three fields
(callsign, 4-char locator and power) are packed into 50 binary bits of
data; then K1JT's clever stuff encodes that into 162 tones, each tone one
of 4 frequencies separated by 1.46Hz. The clever stuff shuffles everything
up and adds redundancy and forward error correction such that even in the
presence of QRM or QSB etc we have the astonishing global HF performance of
this mode even with very low powers.

When sending the 6-character locator, the first WSPR transmission is a
completely ordinary one. It sends as usual, callsign, 4-character locator,
and Power level.

The second transmission sends 6-character locator, a 15-bit hash code, and
the power. The packing into 50 bits is slightly different so that the WSPR
decoder can identify this as the special 2nd kind of transmission. The
6-character Locator is simply placed in what would normally be the callsign
field instead of the callsign. But it is rotated by one character. So for
example, IO91AB is sent as O91ABI. This is so that the "rules" for WSPR
callsigns (that govern the packing into 50-bits) are upheld. The 15-bit
hash code is placed into what would normally be the 4-character Locator
field.

The hash code is required because the 2nd WSPR transmission does not
contain the callsign. Only the 6-char Locator, 15-bit hash code, and power..
The 15 bits aren't enough to contain the callsign. Therefore the use of
this hash code.

So what is a 15-bit hash code? A mathematical process converts a callsign
into this 15-bit hash code. 15 bits means there are 32,768 possible values..
Of course there are many more possible callsigns, than 32,768. Therefore
this is a non-reversible computation, in which multiple callsigns map to
each hash code value. It is non-reversible because when you have decoded
the hashcode value, there is no way to know which of the many possible
callsigns which map to that value, to use.

Therefore the WSPR decoder program at every receiving station, receives the
first ordinary WSPR transmission and creates a table in memory of the
callsigns and hash code pairs. Then when this station receives a Type 2
special transmission, it decodes the hash code and looks in its table, to
find what callsign *probably* sent it (but not definitely). Stations could
"clash" by having the same hash code. But in practice most people
thankfully do not send 6-character "extended" WSPR so the probability of
such a collision is very low.

The Ultimate3S implements the WSPR protocol faithfully, as it must, so that
it matches the receiving station's decoding software. The above rules and
limitations are all pre-existing before the U3S. And hurt my head a lot,
writing all the code to handle.

So what it comes down to is this:

The 1st of each pair of transmissions sends callsign, 4-char locator,
power.
Example:
CG3EXP FN24 23

The 2nd of each pair of transmissions sends 6-char locator, hash code, power
Example:
FN24fq <hash> 23 (I do not know what the hash code for CG3EXP is and
it isn't important enough right now for me to work it out)

A receiving station which has already received one of the first type of
transmission, will have the callsign/hash code in its table in memory; and
when it encounters the 2nd type of message, it will know which callsign
probably sent it.

In a case where a station receives the 2nd type of transmission and has not
received the first, I believe that this spot is discarded, not uploaded to
WSPRnet - it cannot be uploaded because the WSPR decoder does not know what
callsign to send to WSPRnet.

Now you see - the first transmission of the pair ONLY sends 4-character
locator. BUT, WSPRnet always shows a 6-character locator! Where does it get
that 5th and 6th character from? This is the mystery! It makes them up, or
guesses them, from somewhere! It MUST be guessing the 5th and 6th
characters because the protocol is NOT sending them in the actual
transmission. In all the data, we see the 5th and 6th characters flapping
around sometimes. Most of the time the situation is well-behaved but
occasionally a situation somehow arises where the 5th and 6th character
"guesses" of the 1st WSPR transmission recorded in WSPRnet, jump between
several possibilities. We saw cases where the same timeslot had several
different values. The SECOND of the pair in WSPRnet always has the correct
6-character locator, which it must, because the whole 6-character locator
is being sent in the WSPR protocol.

This is a paste of the WSPRnet log for the transition from FN24ep to FN24fq:

2017-06-07 17:22 CG3EXP 14.097112 -6 -2 FN24fq +23 0.200
KU4QI EM87bx 1019 633
2017-06-07 17:20 CG3EXP 14.097122 -26 -2 FN24ep +23 0.200
KG4KNB EM55 1527 949

The interesting thing here is that at 17:20 the Ultimate3S has already
taken a fresh snapshot from the GPS (actually taken at about 17:12 when the
previous 6 transmissions cycle completed). The Ultimate3S knows that it is
now at FN24fq. But at 17:20 the Ultimate3S is sending the 1st of the pair.
Which only contains the 4-character locator FN24. Either WSPRnet, or the
WSPR decoding programs, are "guessing" the 5th/6th characters are "ep"...
so FN24ep is what is in the database. The 17:22 transmission is the 2nd of
the pair and it shows the correct actual 6-character locator FN24fq.

Here the "guess" is quite reasonable because WSPRnet is just remembering
the last 5th/6th characters it had for this callsign. What we don't
understand is why occasionally, as on Sunday, everything goes crazy and the
"guess" oscillates between several different values.

WSPRnet certainly stores its "guesses" in the database, per callsign -
please refer to App Note AN002 "My QTH is many
km wrong in the WSPR map ?€¡° how to fix it!", which is a tutorial on how to
force WSPRnet to report your correct 6-character locator even though you
are sending ordinary WSPR messages which only have 4-characters.

On the other hand, a strange thing that was noticeable the other day, was
that C3 visited two ports, quite close together. For many hours the
locators in the 1st reported WSPR message pairs were jumping around. But
not randomly! On the map it looked like the subsquares were all close to a
diagonal line across the Maidenhead square. That is probably an incorrect
inference though. The diagonal also happened to follow the path of the
water between these two ports. This is what makes me suspect that the
"guess" may also be made by the WSPR decoding software at each monitoring
station, as well as the WSPRnet database. I surmise that a particular WSPR
receiving station may have received C3 (full 6-character locator 2nd
message) as it was at a particular point in the short journey between these
two ports. Some time later, when C3 was already at its destination, this
same particular WSPR receiving station received the 1st message, and
"guessed" the 5th/6th characters, setting them to what it had received some
time earlier, and uploaded that to WSPRnet. Hence the jumping around, and
hence the multiple locators from different stations in the SAME timeslot.

But even that does not really explain what is going on - since the most
prolific reporter, K9AN, was receiving every single transmission, and his
decoding software therefore must know the full 6-char correct locator,
which it was uploading every time (on every band) in each 2nd message slot..
Yet K9AN was still having the INCORRECT 6-char locators associated with his
1st message type in the database.

Conclusions: there are a lot of unanswered questions about what is going on
and where. But to me it is clear that the Ultimate3S and its GPS are
behaving 100% correctly; there is some strange behaviour either in the
decoding software and/or in the WSPRnet website. I don't know which.

I don't have more answers than this, I'm afraid - this email explains all I
know about this issue... perhaps some of you much cleverer brains out there
than my tired confused ones, will see a way through this fog?

73 Hans G0UPL

Hello Ivan.?

On your remote receiving station, have you got an accurate PC time. Within one second accuracy.? There are a few PC time calibration programs on the web to keep your pic time super accurate.?

If not, you won't see any reports.?

My main U3S doesn't TX with much more power then you describe and I get out. Europe, USA mainly. Signal into about 30m of coax into a simple wire dipole.?

Also, the soldering on the LPF seems a little iffy. Especially C1, C2 and the winding on the left of the picture doesn't quite seem like it's taken properly.?

Are you using lead free solder.?? By the joints looking like they do I suspect you are.?

It doesn't sweat as well as leaded solder.?

Keep at it and you'll get there. It's just a learning curve you're in right now and it'll all come clear in the end.?

Kindest, James.?

On 8 Jun 2017, at 07:05, Kelly Keeton via Groups.Io <kellykeeton@...> wrote:

I'm concerned you cooked the transistor please read the bias settings, how to in the instructions.?

You can measure current so you have the tools. Drop the pot counter clockwise then slowly run it clockwise until you see deflection/increase on your current meter then leave it there or back it off a hair.?

This is proper zero bias setting.?

////

Do you have 5v solid power supply yet or are you still using dry cell battery? You need a better power source to continue.

////

I run my unit at 100ft of coax and am heard around the world on all bands on a 20/40 dipole ?no tuner At 1w or less. Never seen the transistor warmer then room temp. On the U3?

////

Do you have 5v at the transistor? Measured with multimeter?

What's your RMS or AC measured power on the RF at transmit into a dummy load??

Do you have a relay board attached??

Is your LPF properly oriented?

Did you check continuity on LPF?

Finally the power output is low you can cheat by running it with a local RX system and just touch parts of the board notice any change in signal on the rx?

Do you have any access to a oscilloscope??

Kelly K7MHI

Sent from a mobile device.?

On Jun 7, 2017, at 6:39 PM, Ivan Cholakov <ivantcholakov@...> wrote:

Thank you all for the great insight. We did the following today:
1. Detached and reattached the toroid that was pointed out as incorrectly placed. Added jumper as instructed.
2. Checked a few additional connections and one did not register well on the multimeter (we used enameled wire for the jumper) so we resoldered it.
Result:
1. The U3S is now transmitting. The amateur radio station next to it can receive the CW test signal.
2. PA Bias - this seems to be a little bit of a problem. In the absence of any test equipment we turn the potentiometer until the transistor starts to get hot. Idle consumption is 85mA and max consumption before transistor gets hot is 180 mA. This seems slightly low.
3.Using our home dipole ->? A station 30 miles away that we can control remotely does not receive the CW beacon. WSPR mode does not get detected or reported. This is using 100 ft of coax so as soon as the 5 days of rain here stops we will also test with a directly fed antenna.
Overall we are transmitting a signal but the indication is the signal is very weak. This could be due to the 100 ft of coax or due to more problems with the board where very minimal power gets transmitted.
Any suggestions are welcome. Thank you again.

I'm concerned you cooked the transistor please read the bias settings, how to in the instructions.?

You can measure current so you have the tools. Drop the pot counter clockwise then slowly run it clockwise until you see deflection/increase on your current meter then leave it there or back it off a hair.?

This is proper zero bias setting.?

////

Do you have 5v solid power supply yet or are you still using dry cell battery? You need a better power source to continue.

////

I run my unit at 100ft of coax and am heard around the world on all bands on a 20/40 dipole ?no tuner At 1w or less. Never seen the transistor warmer then room temp. On the U3?

////

Do you have 5v at the transistor? Measured with multimeter?

What's your RMS or AC measured power on the RF at transmit into a dummy load??

Do you have a relay board attached??

Is your LPF properly oriented?

Did you check continuity on LPF?

Finally the power output is low you can cheat by running it with a local RX system and just touch parts of the board notice any change in signal on the rx?

Do you have any access to a oscilloscope??

Kelly K7MHI

Sent from a mobile device.?

On Jun 7, 2017, at 6:39 PM, Ivan Cholakov <ivantcholakov@...> wrote:

Thank you all for the great insight. We did the following today:
1. Detached and reattached the toroid that was pointed out as incorrectly placed. Added jumper as instructed.
2. Checked a few additional connections and one did not register well on the multimeter (we used enameled wire for the jumper) so we resoldered it.
Result:
1. The U3S is now transmitting. The amateur radio station next to it can receive the CW test signal.
2. PA Bias - this seems to be a little bit of a problem. In the absence of any test equipment we turn the potentiometer until the transistor starts to get hot. Idle consumption is 85mA and max consumption before transistor gets hot is 180 mA. This seems slightly low.
3.Using our home dipole ->? A station 30 miles away that we can control remotely does not receive the CW beacon. WSPR mode does not get detected or reported. This is using 100 ft of coax so as soon as the 5 days of rain here stops we will also test with a directly fed antenna.
Overall we are transmitting a signal but the indication is the signal is very weak. This could be due to the 100 ft of coax or due to more problems with the board where very minimal power gets transmitted.
Any suggestions are welcome. Thank you again.