Re: QMX+ goes into safe mode with antenna tuned to 1.5 SWR
I agree with the other two answers. Pay close attention to the X502 antenna connection area. The jumper is critical of course. And more than one QMX+ has has a solder splash on the SMA connector pads ( under the BNC ) where no component is actually soldered so it does not get the scrutiny that most connections get. A center pin to ground is easy to occur here.?
73
Dick
W4PID
|
Re: Here's hoping for QMX+ v2
The ideal product to me would look similar to the FX-4CR from the outside and contain a "rearranged" QMX+ inside. For this, the circuit would have to be redistributed on two QMX size PCBs, plus a display board with the colour LCD, and a speaker amp IC somewhere. The case (about twice as high as a QMX classic) would have sufficient space for two 4mm thin 2.8Ah Lipo cells ( why not a removable GK40) fitted inside. The front panel LCD would be similar to the 4CR, i.e. with frequency, spectrum, waterfall display and status information. The front panel would also have 6 or 8 push-buttons for what we need most, i.e. band up/down, filter narrow/wide, mode, tune, etc, with a couple of them user defined. All this would substantially improve the handling and user experience of these fine little rigs. The two original QMX push-buttons would of course remain so that the FW can be reused 1:1.?
With a target price say of $200 for the kit or $300 for the ?factory assembled and tested unit I'd certainly pre-order one at once.?
Adding a robust 10W MOSFET PA would be welcomed by many, but of course this is a major design change with a heap of consequences? e.g. cooling, larger toroids, higher cost, etc. etc. and we would be leaving the pure QRP segment.
Best of all, the QSX file could finally be closed once and? for all...
|
Re: QMX CW issue, omits dits
Thanks a lot for your ideas, thanks Hans for your explanaition.
?
Sometimes the easiest solution is the most likely. After some further experimenting I found that in fact it was a contact problem at the paddle jack. After fixing this, the keying now works as it should.
?
Problem solved :-)
?
73 de Michael DF9TZ
?
|
Ron, it looks like you might be counting the IC pins wrong. You show about 12 v on pin 5 and about 2.5v on pin 8. It should be the opposite. Looking down on the top of the IC with the notch or dot at the top, the top left pin is 1 and it counts counter clockwise around from there with pin 5 at the bottom right and pin 8 at the top right. Hope that makes sense.?
Ron
The QCX was returned to me as "Not Working."
I set it up on a 12vDC battery and dummy load. Then used a signal generator and found that the QCX was receiving a signal. Also, using another radio (FT-891) I transmitted and the 891 received the QCX signal. Next I put in on the osciliscope and found that the output was 1V peak to peak.
At this point I checked Q1, Q2 and Q3. All were functioning properly.
Here I began checking the IC's. The pins I did not list here are within specs. The ones listed were not.
IC5 pin 5 (2.28 is actually showing 12v
IC5 pin 8 11.67) is 2.55
IC6 pin 3 (1.63) is 2.66
IC6 pin 5 (1.55) is 11.67
IC6 pin 8 (11.67) is 2.66
IC7 pin 3 1.99) is 2.60
IC7 pin 5 (1.89) is 11.67
IC7 pin 8 (11.67) is 2.66
IC8 pin 3 (0.65) is 2.57
IC8 pin 5 (0.65) is 2.57
IC8 pin 8 (11.67) is 2.60
IC9 pin 3 (0.65) is 4.49
IC9 pin 5 (0.67) is 11.67
IC9 pin 8 (11.67) is 2.56
IC10 pin 5 (4.21) is 11.67
IC10 pin 6 (3.94) is 5.94
IC10 pin 8 (11.67) is 5.90
This is as far as I got. Sorry for the 1st email, Hans. I have torn the bicep in my left arm and probably took too many pain killer before I emailed.. Hi Hi
Any help will be most appreciated...
Thank You
Ron Pearson KA5HZV
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
I'm not in the least surprised that SSB maxed out the processor.? Corollary of Parkinson's law maybe.? Processing requirements expand to match what is available.
?
Do you use fixed point arithmetic?? This uses integer arithmetic but choosing a position for the binary point.? And choosing the values and ranges to make divisions in particular binary.? For example in this example if the factor was 6.4 instead of 5.7 the conversion in decivolts would be a 6 bit shift.?? It would take some careful resistor selection but with 1% resistors something could be done.
This is of course overkill for this measurement, which isn't done often, but the inner loops of the SSB code might benefit from using fixed point, and maybe even hand optimising for the really critical parts.? I've done that, using a profiler, or even setting and clearing an output pin and using a scope to see where most of the activity was, then had optimising.? Things such as avoiding register shifts and storage of temporary variables could save 20 to 30%.
?
All really difficult but a lot of fun.
|
Re: QMX and power bank PD
Thanks all. Looking forward to getting out there and giving it a go! I think I was just worried from all the stories of people damaging their QMX. I'm hoping the LEFS 8010 will be a good choice as I can hop across bands without a tuner - within the limits of the QMX I chose, I went for the middle one 60m to 15m. If I get good at CW TX/RX (and win the lottery) I might reward myself with a Begali one day!
?
73
|
and here is the one built by me with valuable assistance for trouble shooting. It is less noisy. but the tones are there !
--
Martin
DK3UW
|
On Wed, Apr 16, 2025 at 01:19 AM, WB9YXA wrote:
As it stands right now, the SWR jumps around erratically, but the BIAS SMPS now looks 'normal'? 30.5 mA and 4% Duty cycle.
?
?
The SWR will jump around erratically if there's no output power because the SWR calculation will be dividing two small numbers.
?
4% duty on the bias SMPS seems small.? I'm seeing 15% with a 12V supply. ? AIUI the bias current is determined by measuring the ADC _BIAS voltage.? I don't recall hearing how this is converted to a current but it probably assumes that the circuit around the bias generation is correct.
?
One thing to check is the output power independently of the QMX, measuring the peak voltage on your dummy load for example.? If you are seeing power then there could be a problem with T507 because this is what measures the power in the QMX.
?
And I suggest that you do your tests at a lower voltage, 7V and 500mA max for example.? This will help your QMX to survive while you sort out what the problem is.
|
Re: Trying to capture 2x16 LCD signal...
Hi Mike?
I'm not sure I know the answer to your question from memory but the HD44780 datasheet will tell you all you need to know, these things are 40+ years old now and remain the same.?
But my question is why why why! Aren't you making life very hard for yourself... I will soon add CAT commands to return the LCD contents, if you are trying to replicate the display elsewhere this could be a lot easier way to do it, than trying to reverse engineer the HD44780 and create a virtual shadow HD44780...
73 Hans G0UPL
I have been trying to capture the digital signals driving the 2x16 LCD on my fully functional QMX transceiver. ?
?
I am using an application called Scopy and the ADALM2000 learning module hardware from Analog Devices.? I don't understand the captured data.? I am hoping someone on this forum is familiar with this protocol and can provide some insight.
?
My two main questions I have are:
1) Should the Enable line go high when the microprocessor of the radio is writing to the screen?? From what I have captured so far these does not seem to be the case.? However the reference material I read on line about typical 2x16 LCD screens indicates the Enable signal means write to the screen.
?
2) Should the Register Select (RS) line go high when the microprocessor is writing an ASCII character and low when it is writing a screen command?? My data collection shows that there seems to be far more RS pulses than Enable pulses, which I don't understand.
?
Am am attaching a screen shot of the data collected when I power up the QMX receiver with the factory reset splash screen.? I have the Enable pin tied to input bit 0, the RS pin tied to input bit 1 and LCD data bit 0 through 7 tied to input pins 2-9 respectively.
?
Any info on this would be greatly appreciated.
?
Thanks in advance
?
Mike (KC2EHR)
|
I just went into Putty diagnostics and? discovered? something interesting. the tone is always there but on the lower bands it is deeper getting higher for each band and stay at the same height from 12 m on.? Here is a file from Audacity.
?
That is the QMX+ built by QRP Labs. Mine sounds different but has the same sceme.
--
Martin
DK3UW
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
Why not multiple the voltage by 5700 to get the value in millivolts?
That would work also. But it's not necessary, it isn't a problematic or time-sensitive part of the code at all.?
73 Hans G0UPL
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
Why not multiple the voltage by 5700 to get the value in millivolts?
--
73 Matti OH6BEX
|
QMX+ kit build - RX birdies on Digi and loud wide tone on CW
Hi,
?
I've just completed construction of a QMX+ for 9V, with a good inspection for dry joints and solder bridges.
?
Things seem fine on TX - power varies from 5+ watts on lower bands to about 2.5 watts on higher ones.
?
However, on RX on Digital mode there are birdies at 700, 1400, 2100 and 2800Hz on all bands, with 12m showing others at 1000, 1500, 2000 and 3000Hz but at lower level. I have made a couple of QSOs on FT8, so it is working, but I'm sure these tones will cause problems with received tones at these frequencies. On CW mode though, there is a wide range of audio tone from about 600 to 750Hz with a spike at 700Hz. On 15m it is really loud (WSJT-X waterfall shows it as bright red). I can include screenshots of the WSJT-X waterfall for all bands on each mode if that helps.
?
Any ideas where I might start to look to solve it? I see there are numerous threads here about different tones being manifested, but I haven't found anything similar to my situation. I don't have the skills or equipment to replace the PC1804 chip which seems a possible solution to some of the audio anomalies.
?
TIA, 73, Kev G0AKH
|
JP501 is in place.? I decided I did a less than admirable job on T507, so I took it out and rewound it.? Still in the same place.
?
The error condition is "Supply Prot", which I assume means it's not happy about the status of the power rail(s).
?
As it stands right now, the SWR jumps around erratically, but the BIAS SMPS now looks 'normal'? 30.5 mA and 4% Duty cycle.
?
I'm calling it quits for the night.? I'll take this up again tomorrow.
|
hi Stan, did what you say, with only a dummy load... same behavior... sometimes sending complete correctly, sometimes loosing parts of characters, but not the same everytime... sometimes at the beginning, sometimes in the middle or at the end. But ok, may it`s a sign to do to much automatic? :-))? , let your fingers talk?
|
Re: QMX and WinLink/WARA HF settings
Oh, thanks so very much for these hints on Winlink ops!
|
QMX+ Just the Fax, Ma’am.
Oh emm gee, I just ordered a QMX+ kit. Yay!
I haven’t found a rundown on the specs for the current QMX/+. Does the new SSB firmware beta change anything for the sdr as a receiver? I am about 95% a listener, ham bands and not.
I enjoy getting radiofax, so if anyone has done that please let me know how it does?
Tnx es 73,
Aunty Bee
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
Avoiding floating point where possible, avoiding division, are all still important.?
QMX SSB is an example. It was the first time I've ever maxed out a CPU in embedded work. Nothing in QCX, QDX or QMX previously came close. Even with the huge power of 32-bit, floating point processor, running at 168 MHz, it still ran out of cycles. If was necessary to think of everything and choose where to make compromises, find which parts of the calculation were least sensitive to accuracy etc.
GCC is clever and takes care of many optimizations including replacing constant expressions like 57.0 / 10.0 with a single constant 5.7 rather than doing the division. Replacing all integer multiplications and divisions of powers of 2 by shifts is also an optimization implicitly handled by GCC.?
I discovered what its limits are. It won't reorganize a line of code to put all the constants next to each other!?
So:
Voltage = Voltage * 57.0 / 10.0;
Will be compiled, replacing the 57.0 / 10.0 with 5.7. ok. But:
Voltage = 57.0 * Voltage / 10.0;
Will be executed in full without optimization! So you end up with an additional division that isn't necessary.?
Also floating point division is still slower than floating point multiplication. So * 0.1 would he better than / 10.0, and the compiler doesn't change divisions into multiplications either.?
When you have code which executes 12,000 times a second and does a large amount of DSP, which itself contains loops - for example a 51-tap FIR filter contains 51 floating point multiplications and additions - you can end up in a situation where even getting rid of one superfluous division makes all the difference between success and failure. This was literally the case for me at one point late on the development when I'd put together all the modules I'd worked on: SSB, CESSB, Mic AGC, Equalizer, Compression etc. and of course now all the execution times of all of them which ran fine by themselves, all added up. At one point, removing ONE unnecessary division was the difference between success and failure.?
It's also important to code as homogeneously as possible. What I mean by this is that you need code which as far as possible, always takes the same amount of time to run. It's no good if you have code which runs 99% of the time in 1us, but the other 1% of the time something special happens which makes it take 100us. If your system is running audio steaming at 12ksps then 100us of processing causes you to miss the boat. Then you'd have to run everything at a slower rate to have time for the odd 100us. In other words everything has to go at the rate of the slowest thing that can happen. The resulting average CPU use would be rather poor on average. It isn't good use of available resources. So instead if you can somehow find a way to code it such that it always takes 2us 100% of the time you have a massively better outcome.?
A lot of this has parallels even with my 2+ decades spent in an entirely different world, pricing and risk management of exotic derivative products in investment banking and trading. Not a humble 32-bit CPU at 168 MHz but a large parallel supercomputer with 25,000 CPUs in server racks and an annual running cost of $millions. But still: the most important thing was taking care of the efficiency of parts of the calculation which would run billions of times over, and getting homogenous resource use, these were the critical aspects.?
Now the SSB code rakes 93% of CPU during transmit. The other 7% is needed for other parts of the system which just always run like the USB port, SMPS, UI (buttons and LCD) etc., and indeed a few things where homogenous calculation isn't totally possible.?
73 Hans G0UPL
There's still a place for that, especially in tight loops.?
Code changes can be dramatic. I remember an article that was touting the Boyer-Moore string searching algorithm. They compared the standard C library string compare with B-M and they reduced the search from like 2 minutes down to 42 seconds. (This was in the day when PC clock speeds were expressed in KHz.) They wrote their code in Pascal, but I still couldn't believe it would take that long. I researched their article and tested their B-M against a C version. (Pattern
Matching in C", Computer
Language, Nov., 1987.) I can't remember the exact numbers, but I made a few algorithm changes and got the time down to 7 seconds. Also, B-M loses to a brute force search when the target string is less than 9 (??) characters. The reason is because B-M has some setup time, but brute force does not. What the article really showed was that it pays to know what's available in you toolkit (i.e., libraries) and if the tool being used is the right tool (i.e., use brute force with short search strings).
Jack, W8TEE
On Tuesday, April 15, 2025 at 05:37:55 PM EDT, Tony Scaminaci via <tonyscam= [email protected]> wrote:
Hi Jack,
Been there, done that. Being primarily a hardware engineer, I avoid floating point math as much as possible, especially floating point division. The resulting hardware gets quite large or I can trade off hardware for longer latency. But where statistics are involved, floating point division is a necessity. And yes, I love using left-shift and right-shift operators for multiplication and division by powers of 2 since FPGA’s have dedicated hardware for these operations.
Tony AC9QY
Why not simply multiply by 5.7? No need to divide.
It used to be that a divide operation was the slowest math operation you could do. That's why you'll sometimes see an integer operation that divides by 2 done as a bit-shift right, or a multiply by 2 as a bit-shift left. Long ago when my company was marketing our statistics package and the 80366 was popular and had the 80387 math co-processor, our test suggested the time saved by using X *.5 instead of X/2.0 was barely measurable. Today, unless a divide operation is buried in a tight loop, it's probably not worth worrying about. Also, the divide expression is easier to understand.
Jack, W8TEE
?
On Tuesday, April 15, 2025 at 03:39:24 PM EDT, Tony Scaminaci via <tonyscam= [email protected]> wrote:
Why not simply multiply by 5.7? No need to divide.
Tony AC9QY On Tue, Apr 15, 2025 at 2:23?PM Hans Summers via <hans.summers= [email protected]> wrote: Hi all
I did a little bit of investigation and found the cause. The curse of C programmers... C programming 101, schoolboy error coming up... I'm so ashamed.
I correctly measure the voltage at the ADC_PA pin. This is the PA voltage divided by the potential divider made up of R525 (47K) and R526 (10K). According to the usual rules for potential dividers the ratio is 10 / (47?+ 10) which is 10 / 57. Therefore to convert the actual voltage measurement on the pin, to the real voltage to be displayed, I should multiply by 57 / 10.?
Now unfortunately what happens when you have a floating point variable, and you multiply it by?
voltage *= (57 / 10);
is that 57 and 10 are compiled as integers. The division 57 / 10 is equal to 5 (because division of integers truncates). Then the 5 gets converted to floating point implicitly, and the multiplication goes ahead in all due happiness.?
What the conscientious C programmer SHOULD do, when he wants a constant to definitely be understood and used by the compiler as a floating point value, is specify it with a decimal point zero, even when it is just 57 (in this example). So the correct way to write this line of code is:
voltage *= (57.0 / 10.0);
Which then will properly multiply the voltage by 5.7. Whereas it WAS being multiplied by 5.0, which is why the displayed value was too low.?
Many thanks to everyone involved in this thread, I am glad we could fix it! Now this will go into the next firmware version.?
Again I'd like to stress, currently the ONLY place this ADC_PA signal is used, is in the Diagnostics screen. And the silly multiplication by 5 (instead of 5.7) was also only done for the purposes of display on the Diagnostics screen. Hence the error does not affect anything else about the operation of QMX including the SSB self-calibration.
On Tue, Apr 15, 2025 at 9:29?PM Hans Summers via <hans.summers= [email protected]> wrote: What I still don't understand is this:
?- I measure 11.22V at the drain of Q507, while pressing the 'T' key in the diagnostic screen
?- but the voltage displayed in the diagnostic screen is 9.8V, over 1.4V difference.
?- a check of the voltage at ADC_PA, considering the 5.7 voltage divider factor, confirms that the processor should be seeing 11.2V.
I agree, it seems like something isn't quite right. I need to investigate it.??
? This measurement discrepancy is repeatable, and present also on my other QMX+.? On my 9V QMX, the difference is proportionally smaller, with 8.4V measured and 7.2V displayed.
?
This discrepancy was misleading to one user, who thought he could safely increase his supply voltage to get a full-range TX voltage.
Full-range TX was never meant to mean 0 to 12V PA voltage. The PA voltage is expected to be a bit less than the supply voltage. Regardless of the discrepancies noted above (which I need to investigate).??
73 Hans G0UPL
|
Andy, the main problem is the SWR Protect state, which defeats transmit.? The tx voltage is a little low, but ok.? Did you perhaps disturb the JP501 jumper, or T507?
|
I had a VERY similar issue with a QMX+. Powered up by itself, but mine did not power down and cycle back and forth.
The fix on my QMX+ was to replace Q104, the BSS123 that PWR_HOLD turns on.? No short to ground on either PWR_ON or PWR_HOLD.
I didn't record all the values like you did since it worked fine once it powered itself up, but I do recall that the Q104 BSS123 seemed to meter out ok in circuit. Maybe it was leaking just enough Source to Gate under power to turn on Q103 and Q105?
Easy enough to change if have any around or can get them locally, or you can order a new set of SMPSs from Hans.
Hope that helps!
--
Randy, N4OPI
|
Richard Hattaway
Ronald Taylor
Udo Die?elberg DF4BJ
Aunty Bee KF7RHB