QRPLabs QDX

• - Ports COM andLPT - Manufacturer STMicroelectronics. The driver was installed, COM port assigned. Note that you may have to dismiss Windows warnings, it may say it is not the correct driver.

• For the QLG2:- (Same driver.)

• Note here https://www.ebyte.com/en/data-download.html?id=542&pid=485#load is the Navitrack software for the Ebyte module. The Navitrack software may be used to check it, see NMEA, satellites, send commands including the update command.

• On W7 you must run as Admin, W10 asks if you do not

QDX Firmware Update, Windows 7

Windows 7 does not see the QDX as a removable drive when the QDX is set to firmware update mode.

While it is far easier to take it, and the update file to a Windows 10/11/Linux? computer it is possible to use Windows 7.

IMPORTANT! DO NOT USE THIS METHOD UNLESS YOU ARE EXPERIENCED AND PREPARED TO SPEND TIME GETTING THE COM PORT DRIVER BACK! This is an emergency method if you have no other way of updating.

Connect the QDX. Power it up with the interruption to put it in update mode, LED flashing ~5 times a second.

In Device Manager it appears as a COM port with a Code 10 problem.

Go to "Update Driver" - "Browse My Computer" - "Let Me Pick..." Then I was offered the "Mass Storage Device" driver. This installed and the QDX appeared in Windows Explorer as "QDX". The file can then be copied to the QDX.

To return the QDX to normal operation I found I had to run the STM installation file VCP_V1.50_Setup_W7_(*bits*).exe again.

I was offered three options, chose "Repair" it continued, "Device Driver Installer" appeared and after ticking the boxes the QDX then worked correctly.

(A compatibility message appeared, I dismissed it.)

BUT this was just the beginning, after a reboot the COM port driver was not loaded. "Repair" worked until rebooted. Eventually I uninstalled the driver and reinstalled.

Terminal Program

The manual shows a Linux setup. Windows is just the same except that the serial device has to be entered as COM3 or whatever number Device Manager shows the QDX has been allocated.

puTTy https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

The default window in PuTTy may be difficult to read. Now amended, easier to see. Colours may be altered. https://superuser.com/questions/198452/how-do-i-change-the-colour-scheme-on-putty gives details. My post https://groups.io/g/QRPLabs/topic/91981919#87628 gives some idea of how to do it for the QDX terminal.

A few points I've noticed and noted about the QDX

Usually in Windows the QDX does not behave like most other USB devices. QDX users soon find that if the computer is booted with a QDX powered up or if the USB is removed and replaced we get the "Unrecognized Device" message. After powering the QDX it will only correctly send Windows its descriptor once. It must be power-cycled for it to be recognized again. This still applies to v3 onwards.

Updating firmware. I have found that the QDX does not always appear as a memory device in Windows 7, maybe other earlier versions. I simply put the new firmware on a memory stick and "borrowed" a Windows 10 computer.

****

When checking my early v1 QDX if found the TCXO was 74Hz low, 24.999926MHz.

This is somewhat more than I expected. It remains stable. Later versions are much closer to nominal.

****

I also noticed a way of checking that the temperature compensation works.

Placing a cold finger on the TCXO I observed by monitoring on my SDR waterfall that the frequency quickly rose then fell slowly to its original. Removing my finger the frequency quickly fell and then rose to original.

Note this test is best done when coming in with cold hands:-)

****

The case is not grounded, some have noted problems due to this. It is metal and in any case it is a good idea to ground it, various suggestions in the QRPLabs group.

****

WSJT-X Syslog

Take these notes as a guide, I suspect this instance of WSJT-X was malfunctioning but nevertheless the store of files can get large.

Browsing my QDX WSJT-X log directory I found a wsjtx_syslog.log file almost 500MB in size. (Also look in the Logs folder, old ones are stored there.)

It is a text file and contained an enormous number of lines, one for every second WSJT-X had run. Like:-

[RIGCTRL][2022-04-09 02:53:42.563848][251:17:18.932752][error] kenwood_get_mode: error getting filter width, error: -1

[RIGCTRL][2022-04-09 02:53:43.563627][251:17:19.932596][error] kenwood_get_mode: error getting filter width, error: -1

[RIGCTRL][2022-04-09 02:53:44.564848][251:17:20.933593][error] kenwood_get_mode: error getting filter width, error: -1

December 2022:- The CAT situation has been confusing, it is now being given a Hamlib identity. See the QRP Labs group, the QDX CAT is based on a subset of the TS480 commands

There have been discussions on which Kenwood emulation the QDX supports. Some, including me, have said that TS440 does not work (or exist in the drop-down?) "use TS480".

I had WSJT-X set for TS480 CAT, this asks for the QDX to return values it cannot. Therefore an error message is written into the wsjtx_syslog.log file every time WSJT-X polls the QDX.

The answer to this is to use the TS440S CAT definition. I remember that I thought did not work correctly so changed to TS480 which appears to work correctly, maybe something else was wrong.

I may well have been mistaken, going back to the FT440S choice the QDX is working and no errors are logged to the wsjtx_syslog.log file.

IF the TS440S choice really does not work then something needs to be altered.

If the TS480 has to be used then to avoid wsjtx_syslog.log getting too large there are a few things that can be done.

WSJT-X polling can not be turned off but it may be set to longer intervals up to 99 seconds. This is a good idea, Hans says polling is pointless. The optimum solution could be for the QDX to have its own Hamlib definition.

Delete the file regularly. It just recreates another empty file

Below are pastes from the WSJT-X group, by creating the ini file various limits may be set.

An example of the syslog.ini file, it must be edited to suit your requirements.

[Sinks.SYSLOG]

Destination=TextFile

Asynchronous=true

AutoFlush=false

FileName="${AppLocalDataLocation}/wsjtx_syslog.log"

TargetFileName="${AppLocalDataLocation}/logs/wsjtx_syslog_%Y-%m.log"

RotationTimePoint="01 00:00:00"

Append=true

EnableFinalRotation=false

MaxSize=41943040

MinFreeSpace=1073741824

MaxFiles=12

Target="${AppLocalDataLocation}/logs"

ScanForFiles="Matching"

Format="[%Channel%][%TimeStamp(format=\"%Y-%m-%d %H:%M:%S.%f\")%][%Uptime(format=\"%O:%M:%S.%f\")%][%Severity%] %Message%"

Filter="%Severity% >= info"

Editing examples:-

Append=false (restarts the file every time you start, but no record after a restart.)

WSJT-X)MaxSize (specify how big you want to allow it to get. 2621440 = 2.5MB should be more than ample unless you know better.)

EnableFinalRotation (file will rotate and keep 12 files by default -- see MaxFiles)

In my system the log files are here \\DELL\Users\dell\AppData\Local\WSJT-X - rigname=QDX1

It is reached in WSJT-X by File - Open log directory.

[Note the Save drop-down is not normally relevant, should be none. This can really fill your drive with .wav files!]

Other syslog "errors"

***

Example

[SYSLOG][2022-05-26 11:07:54.063657][00:18:19.663040][warning] Detected dropped audio source samples: -528 (-0.011 S)

[SYSLOG][2022-05-26 11:21:54.044840][00:32:19.614684][warning] Detected dropped audio source samples: -528 (-0.011 S)

From https://wsjtx.groups.io/g/main/message/24669

"small numbers like that can be ignored, we had to set the cut off somewhere. Negative numbers indicate more samples than expected. The counts are for each period of the current mode, there is never an exact expected count due to latencies between soundcard and software. In summary, you have nothing to worry about, if the discrepancies are of the order of 0.5 seconds and happen often then you would have a problem with your audio streaming throughput or system timekeeping.

****