#48257

开云体育

“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.

?

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it:

Like us on Facebook!

?

Moderator – North American QRO Group at Groups.IO.

?

email:? bill@...

?

Show quoted text

From: [email protected] [mailto:[email protected]] On Behalf Of Jerry Gaffke via Groups.Io
Sent: Sunday, May 6, 2018 12:19 PM
To: [email protected]
Subject: Re: [BITX20] ND6T AGC implementation for uBIT-X

?

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

I think we can get by with just a couple ADC reads, use that to compute the SWR.
If too much jitter, just follow Arv's suggestion and make the caps bigger.

If that doesn't work, then average it out over several samples.
Or just show what you got and let the operator do the averaging.
But I think the large cap is all we need here, especially if we have 20us sample times.

And a couple 20us sample times is a drop in the bucket compared to time spent updating the si5351.
And if we are worried about spending too much time on housekeeping, then an i2c display
is not a good idea unless we set up queues and shovel data out to it with an interrupt routine.
That i2c display with blocking IO is orders of magnitude worse than a couple 20us ADC reads.

Jerry, KE7ER

On Sun, May 6, 2018 at 08:30 am, K9HZ wrote:

Slowing down processing by additional code. Yes I'm extremely aware of this problem hence the my posts on timing. An outboard I2C A/D removes a lot of this load because 1) we are already using the I2C library for other functions in the radio, and 2) the update frequency requirements once off the original Arduino are much lower.

Virus-free.

#48266

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

Show quoted text

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.

?

#48270

开云体育

We must use different libraries.? I send out the start conversion word to the part address… and away it goes.? Then sometime later, ?I poll to see if conversion is ready/ do a read at the same time (because you get one or the other for free).? If the data isn’t ready, throw away what you got back and go do something else.? If you test every quarter-second, you would always get the data and the ready bit set TRUE.? Then update the display.? Again, the time it takes to do the A/D conversion isn’t important off-board as long as both power readings are congruent and ready together at some point.? The reads can be executed whenever convenient as not to interfere with keying, CAT commands, etc. without using interrupts.

?

With all this said, I support using a couple of caps and doing something really easy.? Maybe it works perfectly.

?

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it:

Like us on Facebook!

?

Moderator – North American QRO Group at Groups.IO.

?

email:? bill@...

?

Show quoted text

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.
?

Virus-free.

#48276

I agree the I2C would be a lot slower.? You are better off using the ADC inputs directly and let it "free-run" (I use ADC6 and ADC7).? That way when you need to access the data, it's just a quick check of the "conversion complete flag" and grab the data from the registers.

Show quoted text

On Sun, May 6, 2018 at 2:35 PM, K9HZ <bill@...> wrote:

We must use different libraries.? I send out the start conversion word to the part address… and away it goes.? Then sometime later, ?I poll to see if conversion is ready/ do a read at the same time (because you get one or the other for free).? If the data isn’t ready, throw away what you got back and go do something else.? If you test every quarter-second, you would always get the data and the ready bit set TRUE.? Then update the display.? Again, the time it takes to do the A/D conversion isn’t important off-board as long as both power readings are congruent and ready together at some point.? The reads can be executed whenever convenient as not to interfere with keying, CAT commands, etc. without using interrupts.
?
With all this said, I support using a couple of caps and doing something really easy.? Maybe it works perfectly.
?
?
Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
?
Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois
?
Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it:
Like us on Facebook!
?
Moderator – North American QRO Group at Groups.IO.
?
email:? bill@...
?
?
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.
?

Virus-free.

--

Paul Mateer, AA9GG
Elan Engineering Corp.

NAQCC 3123, SKCC 4628

#48317

Why is the i2c so much slower? When using the adafruit ads1015 the
entire analog to digital conversion is completely off-loaded from the
nano. All you have to do is read the registers in the ads1015. There is
a small amount of overhead in the i2c communication protocol but it
isn't significant from what I can see. 

It isn't a matter of how fast the analog to digital conversion can be
done because you don't have to read the voltage repetitively as fast as
you can. You can't adjust a tuner faster than the nano can read it from
an i2c adc. 

There was an earlier thread where it was argued that off-loading
everything you could from the nano to an attached processor provided
more cycles for things the nano *has* to accomplish. I would think that
would surely include doing analog-to-digital conversion. 

tim ab0wr

On Sun, 6 May 2018 15:24:42 -0500
"AA9GG" <paul.aa9gg@...> wrote:

I agree the I2C would be a lot slower.  You are better off using the
ADC inputs directly and let it "free-run" (I use ADC6 and ADC7).
That way when you need to access the data, it's just a quick check of
the "conversion complete flag" and grab the data from the registers.

On Sun, May 6, 2018 at 2:35 PM, K9HZ <bill@...> wrote:

We must use different libraries.  I send out the start conversion
word to the part address… and away it goes.  Then sometime later,
I poll to see if conversion is ready/ do a read at the same time
(because you get one or the other for free).  If the data isn’t
ready, throw away what you got back and go do something else.  If
you test every quarter-second, you would always get the data and
the ready bit set TRUE.  Then update the display.  Again, the time
it takes to do the A/D conversion isn’t important off-board as long
as both power readings are congruent and ready together at some
point.  The reads can be executed whenever convenient as not to
interfere with keying, CAT commands, etc. without using interrupts.



With all this said, I support using a couple of caps and doing
something really easy.  Maybe it works perfectly.





*Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ*



Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois



Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com <>

*Like us on Facebook! **[image: facebook icon]*
<>



Moderator – North American QRO Group at Groups.IO.



email:  bill@...





*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.





<>
Virus-free. www.avg.com
<>
<#m_7015192241025951502_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


 

#48322

Here's the datasheet:
? ??
Pages 20-23 are of interest.
Looks to me like it is on the order of 10 bytes transferred via the i2c bus for each ADC read,
since we have to switch channels between reads to choose forward vs reflected power.
At 100 khz, that's 10us * 10 * 8bits/byte = 800 us.
That's an order of magnitude slower than reading the Nano's ADC using a an analogRead() call, around 100us.

It is possible to speed the i2c bus up from 100 khz to 400 khz,
But we can speed up the Nano ADC reads by a factor of 5, fiddling with the ADC clock prescaler.

So using the Nano's ADC is much faster than using this i2c ADC chip
Now if you found a good SPI ADC chip, that might be a different story.

Jerry

#48325

开云体育

If you are only reading one variable, it’s much better to use the Nano’s A/D.? There is no syncing to do… just let it run continuously and read whats ever in the register.

?

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it:

Like us on Facebook!

?

Moderator – North American QRO Group at Groups.IO.

?

email:? bill@...

?

Show quoted text

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

?

Here's the datasheet:
? ??
Pages 20-23 are of interest.
Looks to me like it is on the order of 10 bytes transferred via the i2c bus for each ADC read,
since we have to switch channels between reads to choose forward vs reflected power.
At 100 khz, that's 10us * 10 * 8bits/byte = 800 us.
That's an order of magnitude slower than reading the Nano's ADC using a an analogRead() call, around 100us.

It is possible to speed the i2c bus up from 100 khz to 400 khz,
But we can speed up the Nano ADC reads by a factor of 5, fiddling with the ADC clock prescaler.

So using the Nano's ADC is much faster than using this i2c ADC chip
Now if you found a good SPI ADC chip, that might be a different story.

Jerry

Virus-free.

#48326

开云体育

BTW I’m using the MCP3202… SPI and dual channel with Sample and Hold…

?

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it:

Like us on Facebook!

?

Moderator – North American QRO Group at Groups.IO.

?

email:? bill@...

?

Show quoted text

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

?

Here's the datasheet:
? ??
Pages 20-23 are of interest.
Looks to me like it is on the order of 10 bytes transferred via the i2c bus for each ADC read,
since we have to switch channels between reads to choose forward vs reflected power.
At 100 khz, that's 10us * 10 * 8bits/byte = 800 us.
That's an order of magnitude slower than reading the Nano's ADC using a an analogRead() call, around 100us.

It is possible to speed the i2c bus up from 100 khz to 400 khz,
But we can speed up the Nano ADC reads by a factor of 5, fiddling with the ADC clock prescaler.

So using the Nano's ADC is much faster than using this i2c ADC chip
Now if you found a good SPI ADC chip, that might be a different story.

Jerry

Virus-free.

#48364

If you are reading more than one analog channel then my reading shows
that analogread() can take between 200usec and 300usec as the ADC is
muxed and it takes some time for the analog channel to stabilize because
of the impedance of the channel.

That's not an order of magnitude difference. 

Reading data from something like an ads1015 takes four bytes plus seven
start/ack/nack/stop signal times (e.g. 7 clock cycles).

The master does start/i2c address byte+write bit/slave register
address/start/i2c slave address+read bit/nack/stop. The slave sends
ack/ack/ack/data byte

That's 10*5*8 = 400us. While that is more than successive reads of
analog channels it does not take up precious resources on the nano. If
you are using analog ports you are going to have to use a different
port for forward and for reverse power, using up precious resources on
the nano and taking at least twice as long to read as the 100us minimum
for successive reads on the same channel. 

I only need to do my i2c stuff while tuning up, using a "Tune" or
"Diagnositc" menu option perhaps. Once that is done I use up no nano
resources at all. Using the analog ports will tie those resources up
permanently whether they are actually being used or not.

tim ab0wr

On Sun, 06 May 2018 19:38:31 -0700
"Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:

Here's the datasheet:
? ??
Pages 20-23 are of interest.
Looks to me like it is on the order of 10 bytes transferred via the
i2c bus for each ADC read, since we have to switch channels between
reads to choose forward vs reflected power. At 100 khz, that's 10us *
10 * 8bits/byte = 800 us. That's an order of magnitude slower than
reading the Nano's ADC using a an analogRead() call, around 100us.

It is possible to speed the i2c bus up from 100 khz to 400 khz,
But we can speed up the Nano ADC reads by a factor of 5, fiddling
with the ADC clock prescaler.

So using the Nano's ADC is much faster than using this i2c ADC chip
Now if you found a good SPI ADC chip, that might be a different story.

Jerry

#48366

If you are reading multiple variables, such as forward and reverse
power, then it becomes a big question of resources on-chip vs resources
off-chip. 

For instance, I want to read PA current and reverse power. That's two
analog ports on the nano vs none for an i2c peripheral. If I also want
forward power then it becomes three analog ports vs none for an i2c
peripheral. If I also want PA temperature then it's four analog ports
vs none for an i2c peripheral. Reading multiple analog ports through
the nano muxed ADC doesn't appear to be much faster than doing i2c
reads from peripherals. 

tim ab0wr

On Sun, 6 May 2018 22:15:37 -0500
"K9HZ" <bill@...> wrote:

If you are only reading one variable, it’s much better to use the
Nano’s A/D.  There is no syncing to do… just let it run continuously
and read whats ever in the register.

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ 

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com <>

Like us on Facebook!  <>

Moderator – North American QRO Group at Groups.IO.

email:   <mailto:bill@...> bill@...

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

Here's the datasheet:
    
Pages 20-23 are of interest.
Looks to me like it is on the order of 10 bytes transferred via the
i2c bus for each ADC read, since we have to switch channels between
reads to choose forward vs reflected power. At 100 khz, that's 10us *
10 * 8bits/byte = 800 us. That's an order of magnitude slower than
reading the Nano's ADC using a an analogRead() call, around 100us.

It is possible to speed the i2c bus up from 100 khz to 400 khz,
But we can speed up the Nano ADC reads by a factor of 5, fiddling
with the ADC clock prescaler.

So using the Nano's ADC is much faster than using this i2c ADC chip
Now if you found a good SPI ADC chip, that might be a different story.

Jerry

---
This email has been checked for viruses by AVG.

#48368

Tim? AB0WR

I2C as used with Arduino boards is usually defined for relatively slow (100 KHz) speed.

I2C defines several speed grades but the term baud rate is quite unusual in this
context. The speed grades (standard mode: 100 kbit/s, full speed: 400 kbit/s,
fast mode: 1 mbit/s, high speed: 3,2 Mbit/s) are maximum ratings.
<>

I2C or TWI being a serial bus the data is clocked at the individual bit rate, or no more
than 12500 eight-bit bytes per second.? Parallel-to-serial conversion and serial-to-

parallel conversion can also eat up a lot of machine cycles if it is done with software
instead of using built-in UART type autonomous functions.

The issue of Arduino running out of cycles needed to do its work is usually a false

problem.? Code can be arranged such that the important parts get the most
attention.? Sometimes using interrupts is a good approach and at other times just
calling important subroutines multiple times around the execution loop will suffice.
?

Attached hardware can also be problematic if it requires a lot of CPU cycles from

the host processor to support it.? Servicing slow attached hardware can sometimes

be handled by breaking down its demands for service into small function calls and

spreading the load out to times when the host processor is not doing critical tasks.

Adding sub-processors or smart attached hardware is another option that sometimes

helps to speed things up.? In these cases the bus interface speed and bandwidth

may become the roadblock unless functional load balancing is done to make the
best possible efficiency in data flow between devices.? If only two devices are used

and need to talk to each other it may be faster to use parallel communications

instead of a serial bus.? Interrupt driven parallel bus systems should be much more

efficient than traditional serial bus systems.

Code layout involves optimization for speed where speed is needed.? Relying on

compiler optimization is sometimes not enough to make CPU cycles available

when and where they are needed.

In the "bad-old-days" of sub-1_MHz processors that took 6 or more cycles to do

anything we did things like cycle counting and time parameterization of our code.?

Thank goodness we rarely need to do that in today's world of single-cycle

execution and 16 MHz or faster processors.? But...the method is still valid if you

need to do something involving critical real-time like operations.? Making a flow

diagram and penciling in CPU cycles for each function takes time and effort but

can be helpful in certain critical situations.

Arv
_._

Show quoted text

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

Why is the i2c so much slower? When using the adafruit ads1015 the
entire analog to digital conversion is completely off-loaded from the
nano. All you have to do is read the registers in the ads1015. There is
a small amount of overhead in the i2c communication protocol but it
isn't significant from what I can see.

It isn't a matter of how fast the analog to digital conversion can be
done because you don't have to read the voltage repetitively as fast as
you can. You can't adjust a tuner faster than the nano can read it from
an i2c adc.

There was an earlier thread where it was argued that off-loading
everything you could from the nano to an attached processor provided
more cycles for things the nano *has* to accomplish. I would think that
would surely include doing analog-to-digital conversion.

tim ab0wr

On Sun, 6 May 2018 15:24:42 -0500
"AA9GG" <paul.aa9gg@...> wrote:

> I agree the I2C would be a lot slower.? You are better off using the
> ADC inputs directly and let it "free-run" (I use ADC6 and ADC7).
> That way when you need to access the data, it's just a quick check of
> the "conversion complete flag" and grab the data from the registers.
>
> On Sun, May 6, 2018 at 2:35 PM, K9HZ <bill@...> wrote:
>
> > We must use different libraries.? I send out the start conversion
> > word to the part address… and away it goes.? Then sometime later,
> > I poll to see if conversion is ready/ do a read at the same time
> > (because you get one or the other for free).? If the data isn’t
> > ready, throw away what you got back and go do something else.? If
> > you test every quarter-second, you would always get the data and
> > the ready bit set TRUE.? Then update the display.? Again, the time
> > it takes to do the A/D conversion isn’t important off-board as long
> > as both power readings are congruent and ready together at some
> > point.? The reads can be executed whenever convenient as not to
> > interfere with keying, CAT commands, etc. without using interrupts.
> >
> >
> >
> > With all this said, I support using a couple of caps and doing
> > something really easy.? Maybe it works perfectly.
> >
> >
> >
> >
> >
> > *Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
> > PJ2/K9HZ*
> >
> >
> >
> > Owner - Operator
> >
> > Big Signal Ranch – K9ZC
> >
> > Staunton, Illinois
> >
> >
> >
> > Owner – Operator
> >
> > Villa Grand Piton – J68HZ
> >
> > Soufriere, St. Lucia W.I.
> >
> > Rent it: <>
> >
> > *Like us on Facebook! **[image: facebook icon]*
> > <>
> >
> >
> >
> > Moderator – North American QRO Group at Groups.IO.
> >
> >
> >
> > email:? bill@...
> >
> >
> >
> >
> >
> > *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.
> >
> >
> >
> >
> >
> > <>
> > Virus-free.
> > <>
> > <#m_7015192241025951502_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> >
> >?
>
>

#48370

So what would be the minimum compute requirement on an existing Nano ? Maybe read 2 analog inputs directly from 2 AD8307s? with only a scaling factor for Stockton Bridge coupler loss. Multiply that by 1dBm per 25mV (linear spec for the AD8307) and you have the Forward and Reflected power in dBm into a 50 ohm load.? Look up the "power" in Watts or tape a small chart on the bottom of the uBITX.

73 Kees K5BCQ

#48380

Power is proportional to the square of the voltage read from a diode detector, so that's just an extra multiply.
The Nano does an 8x8 hardware multiply in 2 clock ticks, so maybe a dozen ticks for 16x16, or 1us.

Vs a lookup table in flash to convert dBm to Watts, most hams will prefer a display in Watts.
Nano flash is in short supply, but it has lots of microseconds.
And the supply of $0.30 AD8307's is not guaranteed.?
Advantage here is that the AD8307 can detect ridiculously low power levels
if you can keep all those other noise sources from sneaking in.

Works either way, not too big a deal.
Could easily lay the board out for both, the additional area consumed is less than a toroid.

Jerry

Show quoted text

On Mon, May 7, 2018 at 08:58 am, Kees T wrote:

So what would be the minimum compute requirement on an existing Nano ? Maybe read 2 analog inputs directly from 2 AD8307s? with only a scaling factor for Stockton Bridge coupler loss. Multiply that by 1dBm per 25mV (linear spec for the AD8307) and you have the Forward and Reflected power in dBm into a 50 ohm load.? Look up the "power" in Watts or tape a small chart on the bottom of the uBITX.

#48382

开云体育

Correct, but it is more important that, in the case of SWR that the forward power and the reverse power be synced in time. ?Thats where the Arduino fails and you would want to do it off the Arduino. ?With ten random variables that don't need to be time related, you can just let the A/D run continuously and just grab data from the conversion register when you need it. They run in parallel with instruction processing so no time slots are lost.?

Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it:

email:??bill@...

?

Show quoted text

On May 7, 2018, at 10:49 AM, Tim Gorman <tgorman2@...> wrote:

If you are reading multiple variables, such as forward and reverse
power, then it becomes a big question of resources on-chip vs resources
off-chip.

For instance, I want to read PA current and reverse power. That's two
analog ports on the nano vs none for an i2c peripheral. If I also want
forward power then it becomes three analog ports vs none for an i2c
peripheral. If I also want PA temperature then it's four analog ports
vs none for an i2c peripheral. Reading multiple analog ports through
the nano muxed ADC doesn't appear to be much faster than doing i2c
reads from peripherals.

tim ab0wr

On Sun, 6 May 2018 22:15:37 -0500
"K9HZ" <bill@...> wrote:

If you are only reading one variable, it’s much better to use the
Nano’s A/D. ?There is no syncing to do… just let it run continuously
and read whats ever in the register.

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it: <>

Like us on Facebook! ?<>

Moderator – North American QRO Group at Groups.IO.

email: ??<mailto:bill@...> bill@...

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

Here's the datasheet:
???
Pages 20-23 are of interest.
Looks to me like it is on the order of 10 bytes transferred via the
i2c bus for each ADC read, since we have to switch channels between
reads to choose forward vs reflected power. At 100 khz, that's 10us *
10 * 8bits/byte = 800 us. That's an order of magnitude slower than
reading the Nano's ADC using a an analogRead() call, around 100us.

It is possible to speed the i2c bus up from 100 khz to 400 khz,
But we can speed up the Nano ADC reads by a factor of 5, fiddling
with the ADC clock prescaler.

So using the Nano's ADC is much faster than using this i2c ADC chip
Now if you found a good SPI ADC chip, that might be a different story.

Jerry

---
This email has been checked for viruses by AVG.

#48383

Arv,

I appreciate the info but using external ADC units don't require much
support from the main processor. And even at the 100khz bus speed don't
load the processor down when they aren't accessed repetitively as
critical operation elements.

tim ab0wr

On Mon, 7 May 2018 09:55:59 -0600
"Arv Evans" <arvid.evans@...> wrote:

Tim  AB0WR

I2C as used with Arduino boards is usually defined for relatively
slow (100 KHz) speed.

I2C defines several speed grades but the term baud rate is quite
unusual in this
context. The speed grades (standard mode: *100 kbit/s*, full speed:
*400 kbit/s*,
fast mode: *1 mbit/s*, high speed: 3,*2 Mbit/s*) are maximum ratings.
<>

I2C or TWI being a serial bus the data is clocked at the individual
bit rate, or no more
than 12500 eight-bit bytes per second.  Parallel-to-serial conversion
and serial-to-
parallel conversion can also eat up a lot of machine cycles if it is
done with software
instead of using built-in UART type autonomous functions.

The issue of Arduino running out of cycles needed to do its work is
usually a false
problem.  Code can be arranged such that the important parts get the
most attention.  Sometimes using interrupts is a good approach and at
other times just
calling important subroutines multiple times around the execution
loop will suffice.

Attached hardware can also be problematic if it requires a lot of CPU
cycles from
the host processor to support it.  Servicing slow attached hardware
can sometimes
be handled by breaking down its demands for service into small
function calls and
spreading the load out to times when the host processor is not doing
critical tasks.

Adding sub-processors or smart attached hardware is another option
that sometimes
helps to speed things up.  In these cases the bus interface speed and
bandwidth
may become the roadblock unless functional load balancing is done to
make the
best possible efficiency in data flow between devices.  If only two
devices are used
and need to talk to each other it may be faster to use parallel
communications
instead of a serial bus.  Interrupt driven parallel bus systems
should be much more
efficient than traditional serial bus systems.

Code layout involves optimization for speed where speed is needed.
Relying on
compiler optimization is sometimes not enough to make CPU cycles
available when and where they are needed.

In the "bad-old-days" of sub-1_MHz processors that took 6 or more
cycles to do
anything we did things like cycle counting and time parameterization
of our code.
Thank goodness we rarely need to do that in today's world of
single-cycle execution and 16 MHz or faster processors.  But...the
method is still valid if you
need to do something involving critical real-time like operations.
Making a flow
diagram and penciling in CPU cycles for each function takes time and
effort but
can be helpful in certain critical situations.

Arv
_._


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

Why is the i2c so much slower? When using the adafruit ads1015 the
entire analog to digital conversion is completely off-loaded from
the nano. All you have to do is read the registers in the ads1015.
There is a small amount of overhead in the i2c communication
protocol but it isn't significant from what I can see.

It isn't a matter of how fast the analog to digital conversion can
be done because you don't have to read the voltage repetitively as
fast as you can. You can't adjust a tuner faster than the nano can
read it from an i2c adc.

There was an earlier thread where it was argued that off-loading
everything you could from the nano to an attached processor provided
more cycles for things the nano *has* to accomplish. I would think
that would surely include doing analog-to-digital conversion.

tim ab0wr

#48393

Since the ADC on the nano is muxed, i.e. not every channel has its own
ADC, it takes time for the ADC to be connected to a specific channel
and for that channel to settle to a correct reading. So you do lose
time slots while this is occuring. It's why a random read takes 2 to 3
times longer than successive reads from the same channel.

At least that's how I read the specs. 

And you are right about letting the ADC in the peripheral just run
continuously. I don't consider SWR to be a critical item. You can
measure reverse power when you need to. And you can do the same for
forward power if you want. SWR isn't going to tell you anything extra
over just the two measurements themselves.

tim ab0wr

On Mon, 7 May 2018 11:40:02 -0500
"K9HZ" <bill@...> wrote:

Correct, but it is more important that, in the case of SWR that the
forward power and the reverse power be synced in time.  Thats where
the Arduino fails and you would want to do it off the Arduino.  With
ten random variables that don't need to be time related, you can just
let the A/D run continuously and just grab data from the conversion
register when you need it. They run in parallel with instruction
processing so no time slots are lost. 


Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ 
Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois
 
Owner – Operator
Villa Grand Piton - J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com

email:  bill@...
 

#48399

开云体育

I think you twisted my words. ? I said:

1. If you are resolving variables that are not time dependent between each other (like radio current and s-meter reading), you can let the on board A/D free run and grab and use what ever is in the register for that variable at any time. ?Yes they are all muxed but that doesn't matter because all you want is “a number”.

2. You cannot do time dependent resolution of different variables on the Arduino if timing is critical/ the variables are time dependent. ?Otherwise its like saying ill take the forward power today and the reverse power tomorrow and calculate swr from non-time related data. You are right, the A/D pins are muxed and that just exacerbates the problem as the number of analog pins used grows.?

3. ?If you do have variables where the time relationships are critical (swr, some audio sampling, filters, etc.) then the pest place to do the conversion is off the arduino. Use a sample and hold A/D for critical timed variables so the data time stamps match. It may or may not be critical how long it takes the data to get off the board to inside the Arduino. ?For for/rev power for swr it doesnt matter as long as the data pair has the same resolved time stamp. Audio and filters (fft) is more problematic. ?The answer is correct but shifted in real time so what you usually see (hear) is the right sound but delayed.?

It appears the temporal issue with sampling causes may people problems.?

Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it:

email:??bill@...

?

Show quoted text

On May 7, 2018, at 12:14 PM, Tim Gorman <tgorman2@...> wrote:

Since the ADC on the nano is muxed, i.e. not every channel has its own
ADC, it takes time for the ADC to be connected to a specific channel
and for that channel to settle to a correct reading. So you do lose
time slots while this is occuring. It's why a random read takes 2 to 3
times longer than successive reads from the same channel.

At least that's how I read the specs.

And you are right about letting the ADC in the peripheral just run
continuously. I don't consider SWR to be a critical item. You can
measure reverse power when you need to. And you can do the same for
forward power if you want. SWR isn't going to tell you anything extra
over just the two measurements themselves.

tim ab0wr

On Mon, 7 May 2018 11:40:02 -0500
"K9HZ" <bill@...> wrote:

Correct, but it is more important that, in the case of SWR that the
forward power and the reverse power be synced in time. ?Thats where
the Arduino fails and you would want to do it off the Arduino. ?With
ten random variables that don't need to be time related, you can just
let the A/D run continuously and just grab data from the conversion
register when you need it. They run in parallel with instruction
processing so no time slots are lost.

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ
Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton - J68HZ
Soufriere, St. Lucia W.I.
Rent it:

email: ?bill@...

#48400

Jerry,

I agree with the "And the supply of $0.30 AD8307's is not guaranteed"......always an exposure. "Advantage here is that the AD8307 can detect ridiculously low power levels"....nice !

I thought the low power levels would be useful for the low power users and not having to forward bias diodes which are still very nonlinear at the low end would be nice. Ge diodes I tested, about 10 types, were VERY inconsistent.....hence the HSMS-2815.

They even use those AD8307s for RSSIs (Receiver Signal Strength Indicator). ....probably another thread. Thanks for making this SWR sequence another thread.

73 Kees K5BCQ

#48408

Most low power users are 100mW or more.
And 100mW is polite enough when tuning up.

Into 50 ohms, that's sqrt(0.1*50) = 2.24 volts rms of RF, or 3.16 volts peak.
Assuming we keep the 10 to 1 transformer ratio (so can still take readings when at 20W),
that's 0.316 volts for the diode detectors to see when running at 100mW.

I'd think that if the schottky diodes had a bit of forward bias supplied as Art suggested,
they could be working pretty well at 0.316 volts.
Going lower where it's non-linear, could use some of that table lookup flash you had been allocating for the AD8307.

Yes, the germanium stuff is very temp dependent.?

I don't really know how well this diode thing will work on the low end.
But I think 100mW? may prove sufficient for sniffing out an antenna.
Will try to wire this diode detector tandem match up to my Nano, see what it does.

Jerry

Show quoted text

On Mon, May 7, 2018 at 11:56 am, Kees T wrote:

I thought the low power levels would be useful for the low power users and not having to forward bias diodes which are still very nonlinear at the low end would be nice. Ge diodes I tested, about 10 types, were VERY inconsistent.....hence the HSMS-2815.

#48411

Bill, and others.....

Trying to follow the conversation but it seems that we may be splitting hairs in use of

the built-in ADC and ADC Multiplexing.? Since CW RF is usually used for SWR and

for RF voltage measurements, would there be any appreciable change in readings

of two different ADC inputs during the few milliseconds required to take two successive

samples?? <>

I do understand that if we are attempting to measure phase shift there could be

differences due to measurement delay, but for normal ham radio use we are just using

the Arduino NANO as a DC voltmeter.? The measurements can be averaged over
several sample-and-hold cycles, or use two successive samples with the same ADC
input to insure the charge capacitor is fully charged and throw away the first sample.?

Of course this is measuring with a CW carrier, not with modulation or a two-tone
scheme.

I just now set up a NANO to measure DC voltage on two different ADC inputs.? There

is a small difference between first sample and successive ones in a string of samples

but after the first sample the voltage is stable.? Measuring 1 volt versus measuring 4

volts shows the same first-sample offset and stable readings for successive samples

of the same input.

Measuring two different inputs on separate ADC ports also shows the first-sample

offset with that being a -0.005 volt constant error if sampling alternate input ports

that have different voltages on them.? When I did 4 sequential samples of one port

and then the same on the other port, the 1st sample on each port shows the small

negative error but the 3 subsequent samples show the same 3.000 reading.

From this it seems that the 1st sample could be disregarded and a second sample

used for minimum error on same-port measurements.?

Next I configured my test equipment with a diode rectifier, 0.1 mfd filter cap, and

10K load resistor on the output of an Si5351a synthesizer at 7.0 MHz.? Output
attenuator was set for a constant sampling reading of 3.000 volts on the NANO.?
First sample measurements alternating between 4 samples the RF detector and
4 samples of another input at ground level shows the first RF sample may or may
not be exactly the same as the 3 successive samples (it jitters back an forth between
3.000 volts and 2.995 volts).? The grounded input always shows 0.000 volts for all
4 samples.

From this experiment I would feel confident that continuous CW output into an

SWR bridge would show adequate voltage measurements for single shot samples

and would be super accurate if two subsequent samples were taken on each ADC

input with the first sample dropped and the second sample used.

Arv? K7HKL
_._
?

Show quoted text

On Mon, May 7, 2018 at 12:48 PM, K9HZ <bill@...> wrote:

I think you twisted my words. ? I said:

1. If you are resolving variables that are not time dependent between each other (like radio current and s-meter reading), you can let the on board A/D free run and grab and use what ever is in the register for that variable at any time.? Yes they are all muxed but that doesn't matter because all you want is “a number”.

2. You cannot do time dependent resolution of different variables on the Arduino if timing is critical/ the variables are time dependent.? Otherwise its like saying ill take the forward power today and the reverse power tomorrow and calculate swr from non-time related data. You are right, the A/D pins are muxed and that just exacerbates the problem as the number of analog pins used grows.?

3.? If you do have variables where the time relationships are critical (swr, some audio sampling, filters, etc.) then the pest place to do the conversion is off the arduino. Use a sample and hold A/D for critical timed variables so the data time stamps match. It may or may not be critical how long it takes the data to get off the board to inside the Arduino.? For for/rev power for swr it doesnt matter as long as the data pair has the same resolved time stamp. Audio and filters (fft) is more problematic.? The answer is correct but shifted in real time so what you usually see (hear) is the right sound but delayed.?

It appears the temporal issue with sampling causes may people problems.?

Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
?
Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois
?
Owner – Operator
Villa Grand Piton - J68HZ
Soufriere, St. Lucia W.I.
Rent it:

email:??bill@...
?

On May 7, 2018, at 12:14 PM, Tim Gorman <tgorman2@...> wrote:

Since the ADC on the nano is muxed, i.e. not every channel has its own
ADC, it takes time for the ADC to be connected to a specific channel
and for that channel to settle to a correct reading. So you do lose
time slots while this is occuring. It's why a random read takes 2 to 3
times longer than successive reads from the same channel.

At least that's how I read the specs.

And you are right about letting the ADC in the peripheral just run
continuously. I don't consider SWR to be a critical item. You can
measure reverse power when you need to. And you can do the same for
forward power if you want. SWR isn't going to tell you anything extra
over just the two measurements themselves.

tim ab0wr

On Mon, 7 May 2018 11:40:02 -0500
"K9HZ" <bill@...> wrote:

Correct, but it is more important that, in the case of SWR that the
forward power and the reverse power be synced in time.? Thats where
the Arduino fails and you would want to do it off the Arduino.? With
ten random variables that don't need to be time related, you can just
let the A/D run continuously and just grab data from the conversion
register when you need it. They run in parallel with instruction
processing so no time slots are lost.

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ
Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton - J68HZ
Soufriere, St. Lucia W.I.
Rent it:

email: ?bill@...