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. I have torn the bicep in my left arm and probably took too many pain killer before I emailed.. Hi Hi
Your help will be most appreciated...
Thank You
Ron Pearson KA5HZV
|
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
|
QCX Mini Displaying //???/??/
New QCX Mini (20m) build and everything seems to be working except for the screen will go blank and/or display a mix of /'s and ?'s after the initial boot screen. Boot screen always displays both lines of text and then roughly half the time I get the random mix of ?//? on just the top line or a single black character on the top right. The other half of the time the screen displays the frequency on the top line and I'll get a few button presses before it again falls back to the ?/???? junk. Pushing any of the buttons updates the line but never goes back to anything other than a single black box or the junk characters.
?
I've inspected the board pretty closely, re soldered pretty much everything on the board at this point, and checked continuity between the screen and IC2 pins which all seems to check out. I've also checked the voltage on all the screen pins with a multimeter and while they aren't exactly what is in the build guide they seem to be within the expected operating range. That about hits the limit of what I know to do for troubleshooting, any advice would be more than welcome.
|
Well, one step forward, one step back.? When I unsoldered Q516, it came off the board in two pieces.? Replacing it cured the erratic behavior.
?
However, while waiting for the part, I decided to touch up some solder joints.? As luck would have it, I made the problem worse, I now have zero output power.? The only other symptom is that when I try to key the transmitter with a hand key in CW, there's no side tone in the headphones.
?
?Supply ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Controls
?Voltage: ? ? ? 12.0 V ? ? ? ? ? ? ? ? Left enc. btn:
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Left btn:
?3V3 SMPS ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Right btn:
?Frequency: ? ? 116666 Hz ? ? ? ? ? ? ?Right enc.btn:
?Status: ? ? ? ?SMPS ? ? ? ? ? ? ? ? ? Left enc.:
?Voltage: ? ? ? 3.33 V ? ? ? ? ? ? ? ? Right enc.:
?Duty max: ? ? ?27 %
?Duty cycle: ? ?24 % ? ? ? ? ? ? ? ? ? Inputs
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Paddle dah
?5V SMPS ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Paddle dit
?Status: ? ? ? ?OK
?Voltage: ? ? ? 5.01 V ? ? ? ? ? ? ? ? Transmitter ? ?SWR Protect
?Duty max: ? ? ?43 % ? ? ? ? ? ? ? ? ? Enabled? ? ? ? Yes
?Duty cycle: ? ?36 % ? ? ? ? ? ? ? ? ? Frequency: ? ? 7074000 Hz
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PIN fwd bias: ?30 mA
?BIAS SMPS ? ? ? ? ? ? ? ? ? ? ? ? ? ? PTT signal: ? ?--ON---
?Status: ? ? ? ?ON ? ? ? ? ? ? ? ? ? ? RF output: ? ? --ON---
?Current: ? ? ? 30.6 mA ? ? ? ? ? ? ? ?Voltage: ? ? ? 10.1 V
?Duty max: ? ? ?50 % ? ? ? ? ? ? ? ? ? Power: ? ? ? ? 0.0 W
?Duty cycle: ? ?0 % ? ? ? ? ? ? ? ? ? ?SWR:
?
I'm sure it's a soldering issue, that's how I'm going to attack the problem unless my reading takes me elsewhere.? I left it last night when I got the bias circuit fixed but didn't have any RF output, so I'm just beginning to look at this problem.? The transmitter voltage is in red, so I assume it should be higher than the 10.1 V shown.
?
Thanks all for the help, this group is fantastic.? Makes me feel good about the hobby.
?
Andy, WB9YXA
?
?
?
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
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 groups.io <tonyscam@...> 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
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
Very true. Any optimizing compiler (and the GNU C++ compiler is one) will pre-factor "pure" numeric constants. Often, leaving the numbers as they are makes it easier to read the code.
Jack, W8TEE
On Tuesday, April 15, 2025 at 06:59:57 PM EDT, Jerry Gaffke via groups.io <jgaffke@...> wrote:
In this case, it would truly be immeasurable.
Any decent C complier will precompute 57.0/10.0.
>? voltage *= (57.0 / 10.0);
?
After spending decades on FPGA's and processors without FP hardware, I'm rather partial to all the fixed point tricks.
A skill hardly needed anymore, good to be retired.
?
Jerry, KE7ER
?
?
On Tue, Apr 15, 2025 at 01:22 PM, jjpurdum wrote:
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.
|
Re: Trying to capture 2x16 LCD signal...
?
16x2 LCD are quite similar, here is one of the specs
|
Trying to capture 2x16 LCD signal...
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)
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
In this case, it would truly be immeasurable.
Any decent C complier will precompute 57.0/10.0.
>? voltage *= (57.0 / 10.0);
?
After spending decades on FPGA's and processors without FP hardware, I'm rather partial to all the fixed point tricks.
A skill hardly needed anymore, good to be retired.
?
Jerry, KE7ER
?
?
On Tue, Apr 15, 2025 at 01:22 PM, jjpurdum wrote:
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.
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
Hi Andy,
So true! I’ve had my share of nightmares fixing/modifying old code with literally no comments. Talk about misery, especially when the original engineers left the organizations. When I made changes, I always commented them but a lot of engineers under time pressure from management don’t comment. Bad management practices IMO.
Tony AC9QY
On 15/04/2025 22:26, Tony Scaminaci via wrote:
> I prefer using comments to explain
More than 40 years professional programming has taught me that the code
and the comments rapidly lose synchronisation. Especially when other
programmers end up updating existing code they never wrote!
:-)
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
On 15/04/2025 22:26, Tony Scaminaci via groups.io wrote: I prefer using comments to explain More than 40 years professional programming has taught me that the code and the comments rapidly lose synchronisation. Especially when other programmers end up updating existing code they never wrote! :-)
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
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
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
Hi Hans,
Thanks for the explanation. Yeah, I see it now - I was looking for some hardware issue as opposed to a firmware issue. I saw your firmware fix right after I posted… ships passing in the night:-).
I totally understand writing code in such a way as to assist in future recall. I prefer using comments to explain calculations that are fixed as constants due to design implementation. I’d defined the 5.7 multiplier as a floating point constant and group it together with all of my other constants including comments explaining how these constants were derived, mostly because I can’t remember why I did something weeks after I do it.
Anyway, great catch on the integer division. It’s an easy mistake to make.
Tony AC9QY
On Tue, Apr 15, 2025 at 2:54?PM Hans Summers via <hans.summers= [email protected]> wrote: Looking at the schematic, I see a resistive divider consisting of R508 and R509 hanging off Q507’s drain. Depending on the states and gain of Q514 and Q515, R508/R509 provide some current path to ground which *might* affect the voltage the ADC sees. I don’t know how you arrived at a gain calculation of 6.24 or what that means exactly.
The amplifier consisting of Q512, Q513, Q514 and Q515 pulls whatever current is necessary through R506 in order to try to make the voltage at the base of Q513 equal to the voltage at the base of Q515. It's kind of like an op-amp having inverting and non-inverting inputs: the simple way to think of the op-amp is that it will try to do something to the output in order to make the voltage at its inputs equal.?
In this case the voltage at the gate of Q515 is the PA voltage (at the Q507 drain) divided by a potential divider consisting of R508 and R509. The ratio is 1.91 / (1.91?+ 10) = 1 / 6.24. It's analogous to?the feedback resistor of a simple inverting op-amp configuration. This is what gives the 5-transistor amplifier (PA amplitude modulator) a gain of 6.24.?
This is a separate thing to the potential divider made up of R525 and R526 which deliver a 1 / 5.7 fraction of the PA voltage to the ADC_PA processor pin for measurement (and display on the diagnostics?screen).? ? Bottom line is measuring the PA DC voltage with a ?DVM should be close to what the display reads, within a few percent tolerance, over all possible PA voltages. Otherwise, the user can become confused as Stan pointed out. It would be better to not display the PA voltage at all if an accurate figure over all voltages can’t be guaranteed.
Yes, as I mentioned in my previous post, there was a bug here, and now it should be reasonably accurate in the next firmware version when this?bug fix is implemented.?
The whole point of the PA voltage measurement on the Diagnostics screen is to make sure that the PA modulator is working properly. It's another way for QMX to self-test itself. It could in theory ramp up the DAC voltage and check that the output of the amplitude modulator was always at the expected voltage, by measuring it. Currently it's only checking the two extremes but this is an important check and as for other items in the Diagnostics screen, if there are any errors they light up RED inverse text, to highlight the problem.?
> Why not simply multiply by 5.7? No need to divide.
Sometimes to make the code clear, for when one comes back ages later and wonders what possessed one to write such confusing things, it helps to have the explanation as part of the code. In any case, the compiler optimizer removes any calculations involving constants so it does not increase the program size or execution time. It's just a form of in-code documentation. It would indeed be just as good to write 5.7 then a comment explaining where that comes from.?
73 Hans G0UPL
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
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 groups.io <tonyscam@...> 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
|
|
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
Looking at the schematic, I see a resistive divider consisting of R508 and R509 hanging off Q507’s drain. Depending on the states and gain of Q514 and Q515, R508/R509 provide some current path to ground which *might* affect the voltage the ADC sees. I don’t know how you arrived at a gain calculation of 6.24 or what that means exactly.
The amplifier consisting of Q512, Q513, Q514 and Q515 pulls whatever current is necessary through R506 in order to try to make the voltage at the base of Q513 equal to the voltage at the base of Q515. It's kind of like an op-amp having inverting and non-inverting inputs: the simple way to think of the op-amp is that it will try to do something to the output in order to make the voltage at its inputs equal.?
In this case the voltage at the gate of Q515 is the PA voltage (at the Q507 drain) divided by a potential divider consisting of R508 and R509. The ratio is 1.91 / (1.91?+ 10) = 1 / 6.24. It's analogous to?the feedback resistor of a simple inverting op-amp configuration. This is what gives the 5-transistor amplifier (PA amplitude modulator) a gain of 6.24.?
This is a separate thing to the potential divider made up of R525 and R526 which deliver a 1 / 5.7 fraction of the PA voltage to the ADC_PA processor pin for measurement (and display on the diagnostics?screen).? ? Bottom line is measuring the PA DC voltage with a ?DVM should be close to what the display reads, within a few percent tolerance, over all possible PA voltages. Otherwise, the user can become confused as Stan pointed out. It would be better to not display the PA voltage at all if an accurate figure over all voltages can’t be guaranteed.
Yes, as I mentioned in my previous post, there was a bug here, and now it should be reasonably accurate in the next firmware version when this?bug fix is implemented.?
The whole point of the PA voltage measurement on the Diagnostics screen is to make sure that the PA modulator is working properly. It's another way for QMX to self-test itself. It could in theory ramp up the DAC voltage and check that the output of the amplitude modulator was always at the expected voltage, by measuring it. Currently it's only checking the two extremes but this is an important check and as for other items in the Diagnostics screen, if there are any errors they light up RED inverse text, to highlight the problem.?
> Why not simply multiply by 5.7? No need to divide.
Sometimes to make the code clear, for when one comes back ages later and wonders what possessed one to write such confusing things, it helps to have the explanation as part of the code. In any case, the compiler optimizer removes any calculations involving constants so it does not increase the program size or execution time. It's just a form of in-code documentation. It would indeed be just as good to write 5.7 then a comment explaining where that comes from.?
73 Hans G0UPL
|
Hi Andrey,
At least there is some progress.? But this is very strange.? I have not seen anyone report multiple failures on the control line transistors before.?? As for your PCB#2 test, to know further what is wrong, we would need to measure voltages on LIN_REG_EN, PWM_3V3, IC101 input, and Q102 gate while you have it powered with 5.6V.
?
I have no idea what the root cause of this could be.? A short of Vin or +12V to the control lines could burn the transistors - on QMX note that such shorts can happen because of close assembly tolerances - make sure nothing is touching together when fully assembled.? You can carefully check this with a light and a magnifier with the bottom cover off.? Pins and tabs from the display card can touch other items; examine the bodies of the encoders, the back of the power in jack, etc.
?
Yes, some main board faults can indeed burn out the power supplies - but usually that is from over-current, and the failures are typically different.? I think you reported that you measured ohms between all of the smps connector pins to the main board (each with respect to all others), and found none with low-ohms.? So at least the main board shouldn't have a power short to any of the pins.? If you put in new/fixed power supplies, and power up with your voltage at 6-7V and a 250mA current limit, you won't burn anything out, but will enable further testing.?
?
I guess it is possible that you got a set of SMPS boards that was populated with defective BSS123 FETs, but I've not heard anything like that reported before, either.? Note that you can order for US$10 a new set of SMPS boards from qrp-labs if that is better for you than replacing the components.
?
Stan KC7XE
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
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
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
Hi Hans,
Looking at the schematic, I see a resistive divider consisting of R508 and R509 hanging off Q507’s drain. Depending on the states and gain of Q514 and Q515, R508/R509 provide some current path to ground which *might* affect the voltage the ADC sees. I don’t know how you arrived at a gain calculation of 6.24 or what that means exactly.
Bottom line is measuring the PA DC voltage with a ?DVM should be close to what the display reads, within a few percent tolerance, over all possible PA voltages. Otherwise, the user can become confused as Stan pointed out. It would be better to not display the PA voltage at all if an accurate figure over all voltages can’t be guaranteed.
Tony AC9QY
On Tue, Apr 15, 2025 at 1: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
|
Re: QMX/QMX+ internal Transmit Voltage measurement question
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
|
jjpurdum