|
QMX+ SSB Calibration
??????????? Yesterday I decided to venture into the latest beta release of QMX SSB. I'm nearly 100% CW op, so this was mostly done out of curiosity. I'm a big fan of Hans and QRPLab, and have been impressed with the SSB technology.????
?
Anyway, the firmware install went fine. This QMX+ is factory-built, by the way, and has been trouble free. The only mic I have was intended for use with a PC and has no PTT, so I turned VOX on. The mic test built into the firmware worked fine (with PUTTY) and indicated the mic was working fine with the default gain.? So I ran the LONG calibration process (I'm guessing it took about 30 min., but I didn't measure the time), initiated by the R command so it went through all 3 calibrations on all bands with no further input from me, and completed normally, as far as I could tell.??
?
But, the curves produced by the phase error and IMD Sync cals are in many cases, drastically different from the ones that Hans posted. I included some samples below - some similar to Hans', and some very different. On the IMD Sync curves, there's a set of numbers to the right of each plot, and those numbers are within +/-2 or 3 of those on Hans' plots. I'm guessing that's what matters for those.
?
After calibration, with my mic (tested good in the mic test) plugged in and VOX on, I get no output when speaking into the mic ( into dummy load). I tried power cycling, the QMX, but still no output. In fact, the radio doesn't switch to transmit at all. The rig still works fine in CW mode. Its certainly possible that there's some SSB setting I've overlooked. Any comments welcomed.
?
73,
Randy, KS4L
?
|
|
#qmx SSB Firmware beta 1_01_004 release
#qmx
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:
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.? 73 Hans G0UPL |
|
Re: QMX+ with WA3TFS amplifier
Jamie, glad to hear? that all went well.
?
If I remember correctly, you installed C17 with a switch to bypass it.? Whenever C17 is switched inline, RF detection will be active and work without a PTT cable installed.? If C17 is inline and a PTT cable is installed, both will be active!? I had mine wired this way for a while and Allison recommended to remove C17 to avoid possible QMX finals damage.
?
For the QMX, bypass C17 and just use PTT.? If you mistakenly use only RF detection with the QMX, it will transmit once and stop until you power cycle the QMX as we both found out.
?
Wiring in the C17 and bypass switch adds flexibility if you want to use the amp with different rigs.? Since the QMX is my only QRP rig, I opted to leave C17 and the switch out.? It is easy enough to add if I find a need to do that in the future.
--
73, Jim - AE5JE |
Randy
AE5JE - Jim
BrianB