Ok, so Jerry doesn't write code the same way you do. Neither do I. Prolly why I didn't see anything wrong with it.
Vince.
toggle quoted message
Show quoted text
On 05/06/2018 01:38 PM, Jack Purdum via Groups.Io wrote: Well, not really. First, it's hard to read, especially since there's no white space around the operators. Second, look at the generated code. It's the same for:
while (div>0) { if (d--==r) lcd.print('.'); lcd.print((val/div) + 0x30); val = val%div; div = div/10; }
or
while (div > 0) { d--; if (d == r) lcd.print('.'); lcd.print((val / div) + '0'); val = val % div; div = div / 10; }
yet, which is easier to read? Also, if you just happened to use a pre-X3J11 compiler, the /if() /expression could be evaluated incorrectly since the post decrement operator has higher precedence than the test for equality. (True, the chances of that happening are pretty small, but still non-zero.) Finally, why use the hex representation for zero when '0' makes it easier to read? The indenting on the first example is misleading, since a quick glance makes it appear that the second call to the lcd object is controlled by the/if /expression, which it is not. Also, whitespace makes it easier to read expressions and cost nothing, so why not use it? You could also use the %= and /= operators, but that makes the code harder to read and has no impact on the generated code. Given a choice, I will always pick the form that is easier to read, especially when there's no performance hit.
Jack, W8TEE
On Sunday, May 6, 2018, 1:22:15 PM EDT, Vince Vielhaber <vev@...> wrote:
Places the decimal point. Actually pretty slick.
Vince.
On 05/06/2018 11:31 AM, Jack Purdum via Groups.Io wrote:
if (d--==r) lcd.print('.');
What??
Jack, W8TEE
On Sunday, May 6, 2018, 10:41:34 AM EDT, Jerry Gaffke via Groups.Io <jgaffke@... <mailto:[email protected]>> wrote:
Here's my unproven code for displaying forward and reverse power in Watts plus SWR on the bottom line of the 16x2 LCD, when using a TandemMatch with diode detectors. It's actually quite simple and not computationally expensive.. Hereby released under GPL v3.0
Could be made more accurate by adding the schottky diode drop to the two voltage readings. Assuming the transformer turns ratios are kept at 10:1, the SWR should be reasonably accurate without calibration. Especially if a few uA of bias is added to the diodes.
Power readings should be reasonably accurate if the SWR is close to 1:1 since they assume a 50 ohm load.
Maximum analogRead() return value is 1023, and represents a peak RF voltage of 5 volts. Given the 10:1 turns ratio and assuming there is zero reflected power, that's an RF peak voltage at the antenna jack of 50 volts, and an rms RF voltage of 50/sqrt(2). Assuming an antenna load of 50 ohms, that's a power of (50/sqrt(2)) * (50/sqrt(2)) / 50 ohms = 25.0 watts. From this, we determine the value of PSCALE in the code below.
Using the linear-in-db ad8307 could be done with the same code, but first using a table lookup to convert to RF volts. I don't really want to be computing anti-logs on a Nano. A table lookup will burn some flash.
################################################################ // Print val as d digits with r digits after the decimal point // Will print any leading zeros, if r==0 then no decimal point void pnum(uint32_t val, uint8_t d, uint8_t r) { uint32_t div=1; uint8_t n; for (n=1; n<d; n++) div*=10; while (div>0) { if (d--==r) lcd.print('.'); lcd.print((val/div) + 0x30); val = val%div; div = div/10; } }
// Read TandemMatch's 2 detectors, display forward and reverse power, swr #define PSCALE (1023L*1023/(25*10))// ADC max of 1023 is 25 Watts, display Watts*10 void show_swr() { // SWR = (1+1.0*vr/vf)/(1-1.0*vr/vf); uint32_t vr, vf, swr;// Voltage squared proportional to power vf = analogRead(RF_FWD);// Peak RF volts from forward detector vr = analogRead(RF_REV);// Peak RF volts from reverse detector if (vr>=vf) swr=0; // If vr,vf illegal, force SWR to zero else { swr = (vr*1024)/vf;// Voltage ratio, 10 fractional bits swr = (1000*(1024+swr))/(1024-swr);// 1000*swr, nearly 10 fractional bits swr = (swr+50)/100;// 10*swr, rounded to nearest tenth if (swr>99) swr=99; // Display a max SWR of 9.9 } lcd.setCursor(0, 1);// Fill bottom LCD line, example: lcd.print('f'); pnum(vf*vf/PSCALE,3,1);// "f12.4 r03.1 s1.7" lcd.print('r'); pnum(vr*vf/PSCALE,3,1);// with fwd,rev power in watts lcd.print('s'); pnum(swr,2,1);// and swr to max of 9.9 } #################################################################
My primary reason not to mess with ad8307's is that they are harder to dead bug. If the timing skew between forward/reverse readings is an issue, I'd definitely try the cap. Likely still accurate enough.
Bill wrote:
58.6 KHz would be ok, but to get that rate probably assumes that the processor is dedicated to the task, not off doing other uBITx work,
We currently use a blocking analogRead() in many places in the code, each taking over 100us. And in some cases do it constantly for stuff such as inspecting switches or keyer paddles. So speeding up the analogRead() by a factor of 5 and occasionally (once per second?) reading the forward and reverse power should not be much of a burden, even if averaging a half dozen reads.
Should be possible to set up the ADC to be interrupt driven, an interrupt service routine updates a list of all ADC readings. In mainline code, we'd then disable interrupts and read those last few forward and reverse readings to take an average. Since we are no longer blocking for each 100us+ analogRead(), this would be much less a timing burden.
Things may eventually slow down too much for somebody trying to use the keyer at 40wpm. Otherwise I doubt there will be much of an issue with a lost millisecond here and there. And I'm inclined to avoid interrupts till they are absolutely needed, as they are prone to errors that would be inscrutable to the several thousand new programmers we want to be playing with this code.
Jerry, KE7ER
On Sat, May 5, 2018 at 10:45 pm, K9HZ wrote:
Hmmm¡ we should probably take this off-line at this point. This has to do with A/D resolution time vs. filter time.
I¡¯m rethinking¡that diodes would be a better choice just because they are less complicated. The transform to watts and SWR is still complex though and will eat some processing power in a Nano.
-- Michigan VHF Corp.
-- Michigan VHF Corp.
|