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.

You still need an antenna tuner. The SWR meter is kind of useless
without one.

I'm want to be able to operate for at least 48-72 hours. I'm figuring
you need at least a 36-50 amp-hour battery to be self-sufficient.

tim ab0wr



On Sun, 06 May 2018 17:32:54 +0000
"Jim Sheldon" <w0eb@...> wrote:

Tim,
I have a "YouKits" digital QRP SWR/Wattmeter with a 2 amp hour LI-Ion
battery pack in it that just happens to be set up (by the factory) so
that you can pull the 12 volts out of the bottom via a coax power
connector and run your QRP rig. For short term ops, it a heck of a
lot lighter than a normal battery pack and it gives you SWR & power
as well and it reads to 25 watts on the power scale. Unless I happen
to be using it on the bench (rarely) it stays in my "Go bag" along
with the solar charger. I also have a small, 4 amp hour LiPo cell
phone charger pack with a built in 9 volt/12 volt switching supply as
well as the 5 volt USB charging output, that will run the SWR
Wattmeter & the rig at the same time that is about the size of my
cell phone and can also be charged off the solar panel. Between the
2, I have less than 1/2 a pound of weight (about the same as the
normal battery pack people carrry) and everything is well smaller
than the rig itself. Works for me.

Jim

------ Original Message ------

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.

?

From: [email protected] [mailto:[email protected]] On Behalf Of Jerry Gaffke via Groups.Io
Sent: Sunday, May 6, 2018 1:54 PM
To: [email protected]
Subject: Re: [BITX20] SWR

?

You said
? >? goes on about its business for a while
That's not correct, unless you add some code to handle i2c transmit and receive in
interrupt routines.? That's some code most of us would prefer to avoid.

We currently do blocking IO on I2C reads and writes.
Just clocking all those I2C bits around at 100khz takes considerably more time than doing the embedded ADC reads.

I'm assuming we are mostly concerned about delaying other operations, such as sensing the keyer.

If all you are worried about is how synchronous the two samples are,
then yes the 2 channel ADC chip on the I2C bus would be better,
even if we stick with the blocking code on i2c access.
Me, I'll try out a couple big caps first.

Jerry

On Sun, May 6, 2018 at 10:50 am, K9HZ wrote:

“Actually, reading values from an A/D over the I2C bus will take more time than just reading from the Nano's embedded ADC.?“

?

Yes, but in this case, taking more time is ok… because the Arduino commands the A/D to perform its function, goes on about its business for a while…the digitization happens independently of the Arduino processing, and the data will be waiting for you want to go get it. ?There is no real demand on when the data needs to be available, it’s more a demand of being synchronized (so it’s statistically better to get the average of 5 good numbers rather than 50 marginal numbers).? And (for me the best part) you really can employ an A/D with synchronized S/H for good coordinated forward and reverse power.?

?

I really don’t think anyone here (other than me) will ever do it this way.? Just indicating reverse power by some cheap method is probably fine for tuning an antenna.

?

From: [email protected] [mailto:[email protected]] On Behalf Of G1KQH via Groups.Io
Sent: Sunday, May 6, 2018 1:30 PM
To: [email protected]
Subject: Re: [BITX20] boosting the power on 28 MHz #ubitx

?

We must not speak too low about using the IRF510 as a cheap PA transistor, after a bit of tweaking output looks just fine! Even Uniden are now using IRF520's in their 27Mhz CB rigs:




73 Steve G1KQH

“Actually, reading values from an A/D over the I2C bus will take more time than just reading from the Nano's embedded ADC.?“

?

Yes, but in this case, taking more time is ok… because the Arduino commands the A/D to perform its function, goes on about its business for a while…the digitization happens independently of the Arduino processing, and the data will be waiting for you want to go get it. ?There is no real demand on when the data needs to be available, it’s more a demand of being synchronized (so it’s statistically better to get the average of 5 good numbers rather than 50 marginal numbers).? And (for me the best part) you really can employ an A/D with synchronized S/H for good coordinated forward and reverse power.?

?

I really don’t think anyone here (other than me) will ever do it this way.? Just indicating reverse power by some cheap method is probably fine for tuning an antenna.

?

Jim,

HF Signals buys them from a compnay called WTL Crystals, based in China. There are several sellers on ebay on aliexpress. Most of them are the same 2 pole filter that we use.? I found one just now :?

- f

On Sun, May 6, 2018 at 10:02 PM, Jim Sheldon <w0eb@...> wrote:

One question from me Ashhar, where can I obtain several of those 45 MHz filters?? What is the part number?

Thanks,

Jim Sheldon, W0EB

------ Original Message ------

From: "Ashhar Farhan" <farhanbox@...>

To: [email protected]

Sent: 5/6/2018 11:03:06 AM

Subject: Re: [BITX20] 45Mhz crystal filter specification

You must use the L network of the ubitx or use 1:9 balun to get the proper shape of the fiilter. The 45 MHz crystal filters usually have a termintion specified for around 600 ohms.?

Let me bullet this :

* All filters have the specified shape only when they are terminated at the specified impedance on both sides.

* The passive filters, including the crystal fitlers have no measurable termination to speak of at all. They have different responses at different impedances.?

* The capacitors of the ladder filter set the bandwidth.

* The termination impedance sets the ripple. Lower impedance brings steeper skirt at the cost of ripples in the bandpass. To remove the ripples you increase the impedance and lose the sharpness of the skirt.

On Sun, May 6, 2018 at 7:45 PM, Tim Gorman <tgorman2@...> wrote:

I'm using a direct probe. The 815 has a 50ohm input which should be a
match to most points in the ubitx. At least a close enough match to not
directly affect the circuits operation. I suppose I could use a 10x
scope probe but I'm not sure that would make much difference.

tim ab0wr

On Sun, 06 May 2018 01:03:42 -0700
freefuel@... wrote:

> Hi Tim,
>
> I'm interested to know how your connecting your SA to the circuit,
> from my recollection the majority of SA equipment has a 50 ohm input
> impedance, an input impedance that low is not conducive to hanging a
> probe off the circuit at any convient location.?
>
> -Justin N2TOH

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.

?