|
Hi all
I updated the?SSB?beta?testing webpage of the brave, here:??and released?firmware?version?1_01_004?to it. I did not solve problems with SSB phase distortion calibration, but I added a couple of additional failsafes. I am inclined to stop calling it beta. But I welcome your opinions on this. I know there is more to do, there will always be more to do... I think I would be more comfortable calling it the official version and moving onward. Having it all properly documented in the operating manual and all in one place would simplify things and reduce confusion. What do you think??
These are the changes: - Bug fix: Incorrect PA voltage display on the Diagnostics screen due to 57 / 10 being rounded to 5, as discussed in this forum.
- Change TX color in the diagnostics screen from red to blue, to avoid confusion since red things are errors.
- Added two more USB Virtual COM serial ports. QMX now presents itself as a USB hub with a 24-bit stereo 48ksps USB sound card and three USB Virtual COM serial ports attached. The advantage of this is that you can be running WSJT-X connected to a serial port, then run a terminal emulator connected to a different serial port; then you can make adjustments to the gain for example, to get the WSJT-X SNR meter at your desired level. You can also use other tools like "Input analysis" in the "PC and CAT" menu, which displays incoming audio tones from the PC; previously this could not be used unless you used VOX for Tx/Rx control. The CAT monitor can also be useful to be able to monitor incoming CAT commands and responses in realtime?on one port, with CAT running on another. And going forward, for developers who wish to experiment with BASIC scripting, it will also be important to have multiple serial COM ports.
- Added CAT LC; command to retrieve LCD contents: it returns a 32-character string, whose contents are whatever is on the LCD at that instant. Any custom characters are replaced by spaces. The only exception to this is the VFO indicator which is replaced by an 'A' or 'B' character.
- Added CAT commands SA; which returns the AGC dB value (dB of attenuation applied by the AGC system).
- Added CAT command SM; which returns the S-meter value. This value is in dB. To convert to S-units, divide by 6.
- Added CAT command PC; which returns the power level during TX. The value is in tenths of a Watt. For example response PC45; would mean 4.5W.?
- Added CAT command SW; which returns the SWR meter reading during TX. The value is in units of hundredths. For example response SW142; would mean the SWR measured is 1.42.?
- Added CAT command SS to get/set SSB input source. Valid values are 0 (USB from PC), 1 (Two-tone test generator) or 2 (External microphone).?
- I migrated AF, RF, Image, LPF and Test ADC I/Q terminal tools to the standard ASCII-art graphing tool I developed. Previously every tool had its own piece of code, which of course were copy-and-pasted from each other and largely similar. The advantage is also that the standard ASCII-art graphing tool I developed, also has an interface to display a miniature version of the graphs on a 20 x 16-pixel canvas, shown in a 4 x 2 character section at the right-hand side of the LCD. This means all these sweep tools are now also available on the LCD and buttons, without needing to use the terminal emulator to see them. They are all under the "Hardware tests" menu.?
- I created a new tool called "PA mod. test" specifically to check the operation of amplitude modulator. This is under the "Hardware tests" menu both on the terminal interface and the LCD user interface. Attached is an example of a correctly functioning amplitude modulator. The x-axis shows the DAC value, the y-axis shows the measured PA voltage. A correct result is a straight line that goes (almost) from zero to (almost) the QMX supply voltage; a 12V unit will saturate at about a DAC value of around 2500 as shown.?
- The Hardware tests / Diagnostics screen is now also available on the LCD interface. Here there are 6 screens, which you scroll between by using the Tune knob. You initiate TX (if you wish) by pressing the left button (Keyer/RIT/Menu) button. The six screens are Supply voltage, 3.3V SMPS, 5V SMPS, Bias SMPS, TX and Keyer inputs. When scrolling through these screens, any items which are errors (which on the terminal would be colored RED), on the LCD they flash at a rate of 2.5 Hz to get your attention. You can change the band by turning the Volume knob. So in this way you can easily do all the functions of the Diagnostics screen, on the LCD itself without needing a terminal emulator.?
- The SSB calibration tool now tests the PA amplitude modulator first, and refuses to run if the modulator isn't working properly. To determine if it is working properly or not, it sets the DAC value to 1000. This should produce a PA voltage of around?5.02 V in theory. "Fail" is when the measured voltage is outside the range 4 to 7V. Probably this range is too wide and could be considerably narrowed. But it should easily identify cases where a fault in the amplitude modulation circuit is causing the PA voltage to be always at max.,?which would both prevent proper phase distortion measurements, as well as prevent SSB generation working, as well as stress the PA transistors because they'd run at full power during the entire lengthy calibration process.?
- I have not yet changed or improved the way calibration works; but now if the calibration fails by producing nonsense phase error measurements, and has not got further than DAC value 600, then it is called a "Fail" Calibration now writes zero phase compensation for the entire vector, if that band calibration fails. This way you could continue with other band calibrations, and still have Phase predistortion switched on, it will just have no effect because the phase predistortion?vector will be all zeroes.?
Here is a note about the multiple new USB Virtual COM Serial ports, because it's interesting (well I think so anyway) and I made an interesting discovery.?
Many years ago (2018) when working on the QSX project, Alan M0PUB was very very helpful, he is an expert on USB and on STM32. The ST library examples have various common USB device examples including Virtual COM Serial. But they do not have any examples or any library support for "Compound Device Class", which is what you call it when you have multiple USB devices effective on ONE USB cable. In other words it's like one of those little USB hub things you plug into your PC and it provides 4 separate ports; but in this case, it is all done virtually. So Alan helped out (A LOT) by writing me some code for Compound Device Class support, with a 48ksps stereo 24-bit USB sound card and a USB Virtual COM Serial port as the two devices. This code was written originally to help me with QSX, but it is now in QDX, and in QMX.?
Resource constraints exist on the STM32F446 microcontroller.?
Firstly there are only 6 endpoint pairs numbered 0 to 5. An endpoint is a buffer for USB communication between a host (your PC) and a device (the QMX). A "pair" means that it has one for sending data in one direction from host to device, and one for sending data in the other direction from device to host. Endpoint 0 is always used in USB systems for control purposes. A USB Sound card (USB Audio device) requires 1 endpoint pair for in/out audio streaming. A USB Virtual COM Serial port requires TWO USB endpoints, one is for data in/out and the other is called the "Command" endpoint. So 1 endpoint used for control (endpoint 0 always), 1 endpoint for audio, and 2 endpoints for Serial COM, that means 4 of the 6 are until now, used up.?
The other resource constraint is the 1280 byte FIFO buffer in the microcontroller. The definition of how this buffer is allocated between the various USB endpoints on both send and receive, and is a "little" complex :-/? There are rules in the STM32F446 reference manual about how to allocate the FIFO buffer. But there aren't any warnings if the FIFO isn't allocated correctly, or if it is over-allocated; just nothing will work properly. Alan M0PUB commented way back in 2018 that the 1280 byte buffer, being only 320 32-bit "words", isn't very large at all and is only marginally sufficient in this application because 24-bit stereo 48ksps audio in and out uses up a fair chunk of it (with 1000 USB transactions per second).?
Alan M0PUB's excellent work resulted in a transparent "USB hub" wrapper for the devices, which doesn't use up any endpoints or FIFO space, all of which are dedicated to the end devices themselves (Audio and Serial).?
The issue is only 2 spare endpoint pairs. But I wanted to add at least ONE more COM serial port, as well as be able to add a USB Flash drive in future too, for the BASIC scripting implementation - for the possibility of users being able to share programs, copy them into QMX etc. Since a COM serial port uses up two endpoints, and a USB Flash drive would require one, that would need THREE Spare endpoint pairs, but only TWO are available - even before we start considering the scarcity of the FIFO buffer hardware.?
After a certain amount of research I learned that what is called the "command" endpoint isn't really for commands, it's not a very good name for it. It's for event notifications from the device to the host (unidirectional only), and indeed some implementations call it (a better name, I think) the "interrupt" endpoint. Virtual COM serial is actually only one sub-class of the "Communications Device Class" USB device type. It so happens that some types of serial port like the old RS232 which had not just Data Transmit and Data Receive signals, but also control signals such as request to send (RTS), clear to send (CTS), data terminal ready (DTR), and data set ready (DSR). Use of these is sometimes called "hardware flow control", as opposed to "software flow control" which uses only Transmit/Receive data signals and manages readiness in software.?
QMX uses software flow control and it turns out that in this limited subset of functionality, there is NEVER any need to send event notifications to the USB host. The "command" (really interrupt or event notification) endpoint of the Virtual COM Serial port is therefore entirely wasted as it is never used. What a pity to waste such valuable endpoints, where there are only six available in an STM32F446, on event notifications which are NEVER needed in our application! And how unfortunate tending toward TRAGIC that much lesser STM32 microcontrollers in the family, such as the STM32F103 used in the U4B, and the STM32F070 used in the ProgRock2, have EIGHT bidirectional endpoints not 6.?
But I discovered an interesting solution experimentally! The "command" or "interrupt" endpoint of each Virtual COM serial port can be defined as a non-existent endpoint, not a real one, and allocated no FIFO buffer space. So in this beta version of QMX firmware, there are three Virtual COM serial ports. You will find them for example as COM4, COM5, COM6 in a Windows system (perhaps), or as /dev/ttyACM0, /dev/ttyACM1 and /dev/ttyACM2 in a Linux system (unless there are other ttyACM USB devices on the PC, in which case they could be numbered 1, 2, 3 for example).
The data in/out endpoints are assigned to actual endpoints in the microcontroller numbered 2, 3 and 4 (remember 0 is for control, and 1 is for the Audio USB soundcard). The corresponding command/interrupt endpoints are unidirectional from device (QMX) to host (your PC) and are assigned to non-existent "ghost" endpoints 6, 7 and 8. The fact that these endpoints don't really exist doesn't matter for QMX, because it is never ever going to send any data over them. The PC is also happy, because according to its theories, a USB Virtual COM port should provide two endpoints, one for bidirectionally for data and one unidirectionally for "event" notifications; the PC doesn't know that the endpoint at the other end of the link doesn't really exist and that it will never receive any events on it.?
Everyone's happy, both PC and QMX; and the QMX now has THREE serial ports, as well as still a spare endpoint I can use for a USB Flash drive. It proved possible to fine-tune the FIFO use so it works also. I'll stop waffling now but it was an interesting exercise to me.?
|
I would call it Beta until the SSB phase distortion calibration is more robust.
Chris
|
Hi Chris
I would call it Beta until the SSB phase distortion calibration is more robust.
Please can you try it in this new beta version and let me know what you find??
73 Hans G0UPL
|
Calibration of QMX+ completed.? Results below:
(three QMXs to be tested)
Some phases stopped early
160m? 1100
80m? ?1300
60m? 2500
40m 2600
30m 2600?
20m 2500
17m 700
15m 700
12m 1500
10m 2300
6m 1200
Chris
|
Is it at all possible to set up virtual COM ports so that they will have a consistent name when (re)connecting? I've found that under MacOSX, the name changes every time you plug it in. This makes it slightly annoying when you have to set it up every time in WSJT-X and other software.
I think I've seen that ability on a seeedstudio T1000 meshtastic device.
Calibration of QMX+ completed.? Results below:
(three QMXs to be tested)
Some phases stopped early
160m? 1100
80m? ?1300
60m? 2500
40m 2600
30m 2600?
20m 2500
17m 700
15m 700
12m 1500
10m 2300
6m 1200
Chris
|
Is it at all possible to set up virtual COM ports so that they will have a consistent name when (re)connecting? I've found that under MacOSX, the name changes every time you plug it in. This makes it slightly annoying when you have to set it up every time in WSJT-X and other software.
I think I've seen that ability on a seeedstudio T1000 meshtastic device.
It's done on QDX already and I intend to do it on QMX too. It only works on Linux. On Windows, the OS ignores the name you give it and always gets called COM4, COM5 etc. What happens on Mac I'm not sure! Perhaps some Mac user with a QDX could comment?
73 Hans G0UPL
|
The solution is simple, upgrade to Linux, Jan.
Diarmuid EI4LF?
Is it at all possible to set up virtual COM ports so that they will have a consistent name when (re)connecting? I've found that under MacOSX, the name changes every time you plug it in. This makes it slightly annoying when you have to set it up every time in WSJT-X and other software.
I think I've seen that ability on a seeedstudio T1000 meshtastic device.
It's done on QDX already and I intend to do it on QMX too. It only works on Linux. On Windows, the OS ignores the name you give it and always gets called COM4, COM5 etc. What happens on Mac I'm not sure! Perhaps some Mac user with a QDX could comment?
73 Hans G0UPL
|
The solution is simple, upgrade to Linux, Jan.
Maybe not, Diarmuid... we don't even know that Mac doesn't do it yet...?
|
More info on USB naming, I just checked again the way QMX does it.?
I attached a screenshot of my?/dev/serial/by-id directory. There are three devices, named by their "Interface ID", which are 00, 02 and 08. I could change that so that they are called 00, 01 and 02. The bit which is namable in QDX is the part that says "QMX_Transceiver" here (and in QDX, by default, is QDX_Transceiver).?
In WSJT-X or your terminal emulator, you would be able to specify the port name as, for example:
/dev/serial/by-id/usb-QRP_Labs_QMX_Transceiver-if00
Now this will never change. The other device in the screenshot is my STLink programmer I use to flash the code into the QMX.?
So this is why it's useful. On Linux the port naming is according to when you plug things in (or switch them on). My plugged in ST programmer therefore has name /dev/ttyACM0 and then the three QMX ports would become /dev/ttyACM1, 2 and 3. The issue is that if the ST programer wasn't plugged in then the QMX ports would be named ttyACM0, 1 and 2. But if you enter the name as above, in the by-id device folder, then it never changes regardless of whether there's an ST programmer or any other kind of serial device attached.?
I recall the original point of this was that people might connect multiple QDX to their PC. Then they could name them "QDX-Hi" and "QDX-Lo" for example, if they connected an 80-20m QDX and a 20-10m QDX. That will happen on QMX too, it's the QMX which gets a unique name, so if you had multiple QMX they could be identified. But the unique naming of the port is already possible (Linux).?
MacOSX and Linux share common roots in UNIX. But I know nothing about Mac stuff and whether any of this might be applicable. I'd be happy to make any of the parameters in the USB device description configurable as well as the product name, if it helps - but I think this is a question first for a Mac OSX expert, which I'm not.
On Wed, Apr 23, 2025 at 9:03?PM Hans Summers via <hans.summers= [email protected]> wrote: The solution is simple, upgrade to Linux, Jan.
Maybe not, Diarmuid... we don't even know that Mac doesn't do it yet...?
|
Hello, I installed the new FW and have some trouble.
Under Win I see
Audio - QMX Transceiver - ok
Audio - USB Audiodevice - not ok
Com - STMicroelectronics Virtual COM Port (COM <x>) - ok
Com - STMicroelectronics Virtual COM Port (COM <y>) - ok
?
No COM-Port is working, "Unable to open connection ... Configuring serial port: Error31: Device not working" (the last part in German, maybe a bit different in English).
?
All the tricks around the driver working before without success now.
?
Any suggestion?
?
73 Ludwig
?
|
Some phases stopped early
160m? 1100
80m? ?1300
60m? 2500
40m 2600
30m 2600?
20m 2500
17m 700
15m 700
12m 1500
10m 2300
6m 1200
My results here on a QMX+
160m: 2650 80m: 2650 60m: 2650 40m: 2650 30m: 2650 20m: 2650 17m: 1150, subsequent one-off tries 1200 15m: 1500 12m: 1350 11m: 1950 10m: 700, subsequent one-off tries: 1750, 1500, 1750 6m: 2650
None of these are classified as a "fail" by the calibration system, which would occur if they generate spurious nonsense wagging up and down all over the place. They are all reasonably clean curves until the point they suddenly stop.
|
Starting WSJT-X a errormessage appears "Error in sound input". Maybe its from the not ok USB Audio device (see my post before)? But there is "Audio - QMX Transceiver" and I choose this in WSJT-X but without success.
?
Until now the new FW is a disaster here.
?
73 Ludwig
|
Mine connections come up fine (win10)
Could the "STM..." devices be from different things you have plugged in? - the serial ports from my QMX show as "USB Serial Device", and the audio ports as "Digital Audio Interface (QMX Transceiver)", as before.
?
Snips of Device manager, with QMX as COM10,11,12, and the normal QMX audio devices:
and
?
|
Mine also come up fine. I am using one com port for JTDX, one for LOG4OM, and one for Putty, all at the same time with no issues.
?
Windows 11.
?
Tony
AD0VC
|
Maybe it's only ok for Win10 and up. For field operation I'm using an older and small Netbook / Notebook only good for Win7. So I test all for Win7 using the STMicroelectronics driver for Win7.
?
It would be nearly worst case if I would need a new Notebook for field operation. Maybe I'm not the only one who wants to use Win7 together with the QMX?
?
And besides the COM-Port also my audiodevice doesn't work. I tested using Audacity --> Error.
?
73 Ludwig
|
Good afternoon, Hans -
First - incredible work on this.? There don't seem to be
many folks left that are putting out and fully supporting complex
kits the way that you are, and I can absolutely say that I've
learned quite a bit about soldering (and some about electronics
troubleshooting) from your kits.? Now that I've buttered you up,
here's my question - are all of the virtual COM ports identical in
function in this latest QMX firmware?? Meaning can any of the
three be used for any supported function on the QMX by an
application?? Or is it like some radios (looking at you, Yaesu)
where the different virtual COM ports support different
functions/capabilities from one-another.
Thanks!
73
-- Matt N3AR
On 4/23/2025 11:25 AM, Hans Summers via
groups.io wrote:
toggle quoted message
Show quoted text
More info on USB naming, I just checked again the way QMX
does it.?
I attached a screenshot of my?/dev/serial/by-id directory.
There are three devices, named by their "Interface ID", which
are 00, 02 and 08. I could change that so that they are called
00, 01 and 02. The bit which is namable in QDX is the part
that says "QMX_Transceiver" here (and in QDX, by default, is
QDX_Transceiver).?
In WSJT-X or your terminal emulator, you would be able to
specify the port name as, for example:
/dev/serial/by-id/usb-QRP_Labs_QMX_Transceiver-if00
Now this will never change. The other device in the
screenshot is my STLink programmer I use to flash the code
into the QMX.?
So this is why it's useful. On Linux the port naming is
according to when you plug things in (or switch them on). My
plugged in ST programmer therefore has name /dev/ttyACM0 and
then the three QMX ports would become /dev/ttyACM1, 2 and 3.
The issue is that if the ST programer wasn't plugged in then
the QMX ports would be named ttyACM0, 1 and 2. But if you
enter the name as above, in the by-id device folder, then it
never changes regardless of whether there's an ST programmer
or any other kind of serial device attached.?
I recall the original point of this was that people might
connect multiple QDX to their PC. Then they could name them
"QDX-Hi" and "QDX-Lo" for example, if they connected an 80-20m
QDX and a 20-10m QDX. That will happen on QMX too, it's the
QMX which gets a unique name, so if you had multiple QMX they
could be identified. But the unique naming of the port is
already possible (Linux).?
MacOSX and Linux share common roots in UNIX. But I know
nothing about Mac stuff and whether any of this might be
applicable. I'd be happy to make any of the parameters in the
USB device description configurable as well as the product
name, if it helps - but I think this is a question first for a
Mac OSX expert, which I'm not.
On Wed, Apr 23, 2025 at
9:03?PM Hans Summers via
<hans.summers= [email protected]>
wrote:
The solution is simple, upgrade to Linux, Jan.
Maybe not, Diarmuid... we don't even know that Mac
doesn't do it yet...?
|
Maybe it's only ok for Win10 and up. For field operation I'm using an older and small Netbook / Notebook only good for Win7. So I test all for Win7 using the STMicroelectronics driver for Win7.
?
It would be nearly worst case if I would need a new Notebook for field operation. Maybe I'm not the only one who wants to use Win7 together with the QMX?
?
And besides the COM-Port also my audiodevice doesn't work. I tested using Audacity --> Error.
If it turns out that the new multi-COM feature doesn't suit Win10 then I could make this feature configurable, so that if switched off, you just had exactly the same configuration as before. So don't worry. Let's see, any other people?with Win7? If so, any feedback?
|
Hans,
I use a mid 2011 21.5" Mac running OS10.13.6 High Sierra.
Using "Terminal" I have operated, at various?times, ?two QDX's and a U4B and all 3 are identified as /dev/tty.usbmodemFDxxx ? xxx has always been the same number.
I hope this is of some help.
Thanks for all your hard work, I can hardly wait for the BASIC scripting to be available on the QMX(+).
72 John M0JBA
On Wed, 23 Apr 2025 at 20:52, Kaufman, Matt - N3AR via <matt.d.kaufman= [email protected]> wrote:
Good afternoon, Hans -
First - incredible work on this.? There don't seem to be
many folks left that are putting out and fully supporting complex
kits the way that you are, and I can absolutely say that I've
learned quite a bit about soldering (and some about electronics
troubleshooting) from your kits.? Now that I've buttered you up,
here's my question - are all of the virtual COM ports identical in
function in this latest QMX firmware?? Meaning can any of the
three be used for any supported function on the QMX by an
application?? Or is it like some radios (looking at you, Yaesu)
where the different virtual COM ports support different
functions/capabilities from one-another.
Thanks!
73
-- Matt N3AR
On 4/23/2025 11:25 AM, Hans Summers via
wrote:
More info on USB naming, I just checked again the way QMX
does it.?
I attached a screenshot of my?/dev/serial/by-id directory.
There are three devices, named by their "Interface ID", which
are 00, 02 and 08. I could change that so that they are called
00, 01 and 02. The bit which is namable in QDX is the part
that says "QMX_Transceiver" here (and in QDX, by default, is
QDX_Transceiver).?
In WSJT-X or your terminal emulator, you would be able to
specify the port name as, for example:
/dev/serial/by-id/usb-QRP_Labs_QMX_Transceiver-if00
Now this will never change. The other device in the
screenshot is my STLink programmer I use to flash the code
into the QMX.?
So this is why it's useful. On Linux the port naming is
according to when you plug things in (or switch them on). My
plugged in ST programmer therefore has name /dev/ttyACM0 and
then the three QMX ports would become /dev/ttyACM1, 2 and 3.
The issue is that if the ST programer wasn't plugged in then
the QMX ports would be named ttyACM0, 1 and 2. But if you
enter the name as above, in the by-id device folder, then it
never changes regardless of whether there's an ST programmer
or any other kind of serial device attached.?
I recall the original point of this was that people might
connect multiple QDX to their PC. Then they could name them
"QDX-Hi" and "QDX-Lo" for example, if they connected an 80-20m
QDX and a 20-10m QDX. That will happen on QMX too, it's the
QMX which gets a unique name, so if you had multiple QMX they
could be identified. But the unique naming of the port is
already possible (Linux).?
MacOSX and Linux share common roots in UNIX. But I know
nothing about Mac stuff and whether any of this might be
applicable. I'd be happy to make any of the parameters in the
USB device description configurable as well as the product
name, if it helps - but I think this is a question first for a
Mac OSX expert, which I'm not.
On Wed, Apr 23, 2025 at
9:03?PM Hans Summers via
<hans.summers= [email protected]>
wrote:
The solution is simple, upgrade to Linux, Jan.
Maybe not, Diarmuid... we don't even know that Mac
doesn't do it yet...?
|
On Wed, Apr 23, 2025 at 10:15 PM, Hans Summers wrote:
then I could make this feature configurable,
Hello Hans, thanks for the quick response. Exactly this came in my mind but I didn't know about the effort.
And it looks like a thing of old Win7. Changing between a QMX with FW03 and one with FW04 the same COM-Port is available for both, but useable only for the QMX with FW03. For the QMX with FW04 the COM-Port is shown by the device manager as ok. But when I try to use it I get an error message.
?
73 Ludwig
|
are all of the virtual COM ports identical in
function in this latest QMX firmware?? Meaning can any of the
three be used for any supported function on the QMX by an
application?? Or is it like some radios (looking at you, Yaesu)
where the different virtual COM ports support different
functions/capabilities from one-another.
I have never owned nor any radio transceiver other than homebrew and QRP Labs radios. So I mostly have no idea what they do.
But yes, in QMX, all three Virtual COM ports are completely identical. In all cases, the supported functions are currently CAT and Terminal. Any Virtual COM port is assumed to be a CAT interface, unless a carriage return or line feed character is received, in which case it becomes a Terminal. No CAT commands ever include carriage return or line feed characters which is why this works. Choosing "Exit Terminal" from the main menu before closing your terminal emulator returns a COM port to the CAT function.?
73 Hans G0UPL
|
Kaufman, Matt - N3AR