Date   

Re: QCX classic in QCX+ Case

Ted 2E0THH
 

Hi Carl
A couple of years before the birth of the QCX+ and by complete coincidence, I enclosed my QCX in virtually an identical box and with a very similar layout to the QCX+. I have all the templates still if they would be of any help to you.



73s Ted
2E0THH


Re: Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

Alan G4ZFQ
 

My understanding is that the hashtable is only used for the type 2 and type 3 WSPR transmissions, which are "extended" type transmissions, for I could be wrong - but I am fairly familiar with the WSJT-X documentation and I don't see anywhere in the documentation that would prove me wrong... am I missing something?
Hans,

I'm not sure if or where any real detailed information is published.
From time to time such things are mentioned in the WSJT-X group.

The hashtable is used for complex calls I do not know if the decoder can "confuse" the transmission types.

https://www.sm2cew.com/Digital%20communications%20using%20minimal%20transfer.pdf

is possibly what you refer to about JT65, in any case it details "Deep Search".
I cannot confirm whether this is relevant to WSPR.

There are quite a few other decoders that have their data uploaded to WSPRnet, I've never looked into the way they work.

But fundamentally we look desperately for answers instead of simply accepting that false decodes are inherent in these modes.
One of the developers has said that the decoder is not working properly if no false decodes are made.

There is also confusion created by the WSPRnet site. The map seems to have bugs, shows stations in the wrong place when another site using the same data shows correct. Maybe a few bugs in the data presentation?

73 Alan G4ZFQ


Re: Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

tony.volpe.1951@...
 

Thanks for the information and ideas.

I was sure that it was nothing to do with the QCX firmware.

I think somehow it is to do with an aggressive form of decoding which looks in the data for other features in common in the transmitted string.

It can't be anything else and the qcx has been switched off between the transmission of the two calls.


Re: New QCX Mini arrived

GIUSEPPE
 

Hello everyone, my new qcx mini arrived yesterday.  now the assembly begins.  Thank you very much Hans.  73 iu8eun Joseph

_._,_._,_


Re: Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

Hans Summers
 

Hello Alan
 
>as I know it is not done in the WSJT-X
> software for WSPR at all;

Hans,

It is, the "hashtable" I referred to.

My understanding is that the hashtable is only used for the type 2 and type 3 WSPR transmissions, which are "extended" type transmissions, for callsigns with prefixes or for transmitting 6-character callsigns. 

QCX is only capable of the standard type 1 WSPR transmission. The Ultimate3S kit can do type 2/3 (extended). 
 
It may be disabled by disabling the "Deep" decode. But that just stops
you from making a small number of false decodes.

I have seen that setting but I don't think it is applicable to WSPR. 

I could be wrong - but I am fairly familiar with the WSJT-X documentation and I don't see anywhere in the documentation that would prove me wrong... am I missing something? 

73 Hans G0UPL
http://qrp-labs.com 


Re: A simple QCX AGC #mods #qcx

Jim AJ8S
 

CAUTION: Do not use a conductive screwdriver to adjust the 10k potentiometer if the radio is mounted in a metal case. This can cause the wiper to short to ground possibly damaging the 5 volt regulator or the potentiometer.


Re: tuners for experimental antennas and the QCX

Bert N8NN
 

I use an LDG-100 Plus antenna tuner for portable operation. 

Small, light weight, powered from internal AA batteries, tunes with a fraction of a watt. Tunes up to 16:1 SWR.

Bert N8NN


Re: Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

Alan G4ZFQ
 

as I know it is not done in the WSJT-X software for WSPR at all;
Hans,

It is, the "hashtable" I referred to.
It may be disabled by disabling the "Deep" decode. But that just stops you from making a small number of false decodes.

73 Alan G4ZFQ


Re: Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

Alan G4ZFQ
 

Ron Carr wrote:
The receiving software keeps a database that it uses to match complex calls and 6 character grid squares to the correct call.  And the matching algorithm is not perfect as I believe it uses a hash or similar scheme.  I could see something like this happening if you or he used a call like  K1URC/3   or a grid like FN54fk.
Tony,

Yes, some decodes are difficult or impossible to fathom. Due to the hashtable feature complex calls are suspect and best not used if not really required.
Was there a complex call involved?
You did the right thing, check how many others spotted the "transmission", whether propagation even was possible.
This one seems very strange but so do some other false decodes.

73 Alan G4ZFQ


Re: Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

Hans Summers
 

Hi Ron, Tony

That is indeed a mystery. 

Ron, you are correct about 6-char grid squares in the extended WSPR transmission format - but the QCX is not capable of transmitting this extended format. It can only handle the simple normal WSPR transmissions. 

Tony, it cannot be a problem with Forward Error Correction because this relates to the encoding of the transmission itself, on the QCX. Forward Error Correction is, somewhat loosely, the term applied to the encoding of data with additional bits via the used encoding protocol, that allow the decoding station to correct errors in the transmission. The QCX cannot be transmitting or encoding your friend's callsign, since you have replaced it with your own. 

Furthermore it cannot be a problem with the QCX somehow remembering the encoding of your friend's callsign, since the encoded sequence of 162 symbols in a WSPR transmission is not stored in EEPROM, it is always calculated dynamically and exists in volatile RAM only. Therefore it is not persisted through power cycles. It is hard to see therefore, how this mystery could be caused by any problem in the QCX firmware itself. 

Some digital modes augment their decoding logic with a probability-based fuzzy match, looking for probable (but not algorithmically certain) matches between the decoded data, and a database of existing callsigns - which could be callsigns the decoding station has heard before, or in some cases an internet-based list of callsigns. This is a somewhat controversial practice, as far as I know it is not done in the WSJT-X software for WSPR at all; I know JT65 and Opera are two modes that use this controversial technique but I have not heard of it being applied to WSPR, though I could be wrong. 

All of which makes it a bit of a mystery... I do not see how this phenomenon could ever be caused by the QCX firmware itself, though equally well I don't see that it could be caused by WSJT-X either... unless there is some feature of WSJT-X I don't know of, or maybe there are other more aggressive WSPR decoder software packages out there which DO apply the controversial probability match. 

73 Hans G0UPL
http://qrp-labs.com

On Fri, Feb 26, 2021 at 12:53 PM Ron Carr <rcarr@...> wrote:
The receiving software keeps a database that it uses to match complex calls and 6 character grid squares to the correct call.  And the matching algorithm is not perfect as I believe it uses a hash or similar scheme.  I could see something like this happening if you or he used a call like  K1URC/3   or a grid like FN54fk.


Re: Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

Ron Carr
 

The receiving software keeps a database that it uses to match complex calls and 6 character grid squares to the correct call.  And the matching algorithm is not perfect as I believe it uses a hash or similar scheme.  I could see something like this happening if you or he used a call like  K1URC/3   or a grid like FN54fk.


Re: Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

tony.volpe.1951@...
 

I should have added that only 2 stations have 'spotted' these phantom 'transmissions' of the call. It isn't general at all.


QCX classic in QCX+ Case

m0icr@...
 

With apologies if this has already been answered elsewhere, but having conducted a search through group messages I failed to find the any comments on this topic.

I have a QCX classic which I am considering putting into a QCX+ case, I recognize I will need to connect the LCD and controls off board etc. 

I at not inclined for this QCX to be used in a BaMaTech case, as good as they are (and I have one for another QCX), I wish to put this radio in a 'vertical' type orientation).

Does anyone have any thoughts/experience of putting a QCX classic into a QCX+ case?

 

73, Carl M0ICR

 

 


Weird WSPR decode anomaly - Probably a FEC problem with wspr decoding software

tony.volpe.1951@...
 

A few days ago, I loaned one of my QCX radios to a mate so he could see how it worked. He is interested in starting WSPR himself and we programmed his call into my QCX40 classic and he ran it for a couple of days on a twenty minute frame setting.

I then got it back and  used it myself WITH MY CALL set up in it.

If I do a database search on his call, I still find a few current decodes which show his call, even though there were no transmissions with his call - only mine is in use. The wrong decodes are on the same frequency as mine with the same Maidenhead square and power. Is it possible that the Forward Error Correction at the receiving station is looking at other parts of the transmission and guessing a callsign the rx did not receive. I am absolutely certain that the call shown was not transmitted for the last two days.


Re: Setting time on QCX - wspr mode

Hans Summers
 

Hello Gerry
 
Thanks Alan for your reply. As I see it the 27mhz update from the GPS stream ensures an accurate transmission frequency. The 20mhz osc is updated by the GPS serial data stream (to quote
Hans from the manual) to ensure a stable time lock. I was just puzzling why if the 27mhz update is displayed, why is the 20mhz update not displayed also. Is this just a function of the QCX programme and it was never intended to display it? I know that the clock is in fact being updated as it is set accurately after the first WSPR transmission and I presume after each and every subsequent transmission.. 

The 20MHz crystal is not calibrated during the regular GPS calibration at the end of each WSPR transmission. Only the real time clock (RTC) is set. It is not necessary to calibrate the 20MHz crystal every time since any minor frequency deviation due to temperature drift will cause an irrelevant time shift during WSPR operation. 

20MHz crystal calibration using the GPS is possible in the alignment menu. It is enough to do this once when setting up the radio after assembly. It is not even necessary to do this, since even a few kHz of error will still have no important impact on timekeeping in the short-term (between RTC updates by the GPS at the end of each cycle). 

73 Hans G0UPL
http://qrp-labs.com


Re: tuners for experimental antennas and the QCX

ajparent1/KB1GMX
 

Hi Jim,

A long bunch of yeas back I did an 7x7 L tuner
with one switch and two rotary encoders.

I'd learned from Altair in early 75 that switch flipping was painful
so two 7 bit up down counters driving relays did the work.  Turn
the knob right and the C or L increases, to the left decreases.
Leds on each relay gave binary value of L or C.

A toggle selects what end the cap is at.  Works nice and 
is battery unfriendly as there can be 14 relays active at
40ma each. Usually about half were active.   This was
before cheap latching relays.  The companion MPU of the
day would have been 8748, or maybe the big gun 8751
both would have added power consumption.

A three knob Z tuner has the advantage of no batteries
or RFI.

Allison
-------------------------------
Please reply on list so we can share.
No private email, it goes to a bit bucket due address harvesting


Re: Setting time on QCX - wspr mode

Arv Evans
 

Geoff

I was proposing something a little different.  In QCX products frequency is
controlled by the SI5371a.  The 1-PPS is used for frequency or rate of
digital mode timing.  Maybe I misstated what I meant. 

If I can get all the ducks to stay in line, my alternative method of generating
the 1-PPS will be published in a few days (probably toward the 1st of next
month).

Arv
_._


On Thu, Feb 25, 2021 at 5:38 PM geoff M0ORE via groups.io <m0ore=tiscali.co.uk@groups.io> wrote:

I don't think the 20MHZ oscillator is controlled by the NEMA data from the GPS. The clock is maintained by the NEMA but that is not the same thing. If the NEMA is setting the clock time, the frequency of the 20MHz clock is not that important.

On 25/02/2021 20:30, Gerald Ball via groups.io wrote:
Thanks Alan for your reply. As I see it the 27mhz update from the GPS stream ensures an accurate transmission frequency. The 20mhz osc is updated by the GPS serial data stream (to quote 
Hans from the manual) to ensure a stable time lock. I was just puzzling why if the 27mhz update is displayed, why is the 20mhz update not displayed also. Is this just a function of the QCX programme and it was never intended to display it? I know that the clock is in fact being updated as it is set accurately after the first WSPR transmission and I presume after each and every subsequent transmission..  73 Gerry G4OJF
On 25 February 2021 at 17:15 Alan G4ZFQ <alan4alan@...> wrote:


This might suggest that the 20mhz osc 
is not being updated. 
Gerry

This has to be done manually. It just affects timekeeping without a GPS.
If you cannot measure it, check time drift and calculate.

73 Alan G4ZFQ






    


Re: Setting time on QCX - wspr mode

geoff M0ORE
 

I don't think the 20MHZ oscillator is controlled by the NEMA data from the GPS. The clock is maintained by the NEMA but that is not the same thing. If the NEMA is setting the clock time, the frequency of the 20MHz clock is not that important.

On 25/02/2021 20:30, Gerald Ball via groups.io wrote:
Thanks Alan for your reply. As I see it the 27mhz update from the GPS stream ensures an accurate transmission frequency. The 20mhz osc is updated by the GPS serial data stream (to quote 
Hans from the manual) to ensure a stable time lock. I was just puzzling why if the 27mhz update is displayed, why is the 20mhz update not displayed also. Is this just a function of the QCX programme and it was never intended to display it? I know that the clock is in fact being updated as it is set accurately after the first WSPR transmission and I presume after each and every subsequent transmission..  73 Gerry G4OJF
On 25 February 2021 at 17:15 Alan G4ZFQ <alan4alan@...> wrote:


This might suggest that the 20mhz osc 
is not being updated. 
Gerry

This has to be done manually. It just affects timekeeping without a GPS.
If you cannot measure it, check time drift and calculate.

73 Alan G4ZFQ







Re: Setting time on QCX - wspr mode

Arv Evans
 

If there was an alternative to generating one-PPS from GPS, and
if you could use CAT to send time and date and fixed location to
your QCX...would there be any need for a GPS.  Frequency
stability could be developed from the one-PPS, and for non-mobile
locations you would not need updatable latitude and longitude. 

Yes, thinking about this as a future project.  An accurate one-PPS
has already been demonstrated in my shop.  The rest is a to-be-coded
way to send the other data from my NTP synced PC and forward that
via CAT link.

Arv
_._


On Thu, Feb 25, 2021 at 1:30 PM Gerald Ball via groups.io <gerryball2=talktalk.net@groups.io> wrote:
Thanks Alan for your reply. As I see it the 27mhz update from the GPS stream ensures an accurate transmission frequency. The 20mhz osc is updated by the GPS serial data stream (to quote
Hans from the manual) to ensure a stable time lock. I was just puzzling why if the 27mhz update is displayed, why is the 20mhz update not displayed also. Is this just a function of the QCX programme and it was never intended to display it? I know that the clock is in fact being updated as it is set accurately after the first WSPR transmission and I presume after each and every subsequent transmission..  73 Gerry G4OJF
> On 25 February 2021 at 17:15 Alan G4ZFQ <alan4alan@...> wrote:
>
>
> >This might suggest that the 20mhz osc
> > is not being updated.
>
> Gerry
>
> This has to be done manually. It just affects timekeeping without a GPS.
> If you cannot measure it, check time drift and calculate.
>
> 73 Alan G4ZFQ
>
>
>
>
>


--
gerry






Re: #alignment #qcxmini #alignment #qcxmini

Robert Graf
 

Howdy! Replacing IC9 fixed the issue, the IC9 OPA2277U was indeed faulty. Now it's working. Cheers, -Robert K6RGG

2261 - 2280 of 64940