Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #16353

Re: GA144 polyForth

Show all headers | View raw

On 10/16/2012 7:12 AM, Howerd wrote:
> On Oct 15, 10:38 pm, rickman<gnu...@gmail.com>  wrote:
>
> Hi Rick,
>
>> If it fits in with existing theory, then it should be observable with existing technology.
> Yes, the GA144 is existing technology...

That is not sufficient.  There is a world of existing technology and 
some will do the job and some won't.  The point is... and I'm getting 
really tired of trying to make it, if the stuff you want to measure fits 
existing theory then the existing technology that also fits that theory 
should be capable of measuring it.  By existing technology I mean any 
ADC that has adequate resolution and speed.


>> you have said nothing understandable that indicates the GA144 will do anything any other ADC can't do.
> The GA144 is very simple, so the electrical path between input pin and
> counter output is very short.
> This might allow effects to be observed that would be smoothed out by
> amplifiers, filters and conventional ADCs.

But you don't have any idea that I can tell of what you are looking for. 
  You never answered my question about what two outcomes would show the 
existence or absence of the effect you want to measure.


>> You talk about 5 GHz as if it is the sample rate and it isn't,
> If you clock a counter at 5GHz +/-100MHz, as the frequency changes the
> value of bit 0 of the counter when observed every 10 ns will change,
> and this value, if summed over a long period of time, will reflect the
> change in frequency. Since this is a VCO a small change in voltage
> will cause a small change in frequency which will cause a change in
> the summed count value.

Why do you need to look at this one bit?  To detect the change in 
frequency over a long period you can just directly read the *entire* 
counter and subtract subsequent readings.  This value is directly 
proportional to the frequency.  The longer the period you monitor it the 
greater the analog resolution.  I'm not sure dealing with bit 0 the way 
you describe will even give you a meaningful value.  I believe you will 
simply be monitoring what amounts to aliasing.


> It depends on exactly how you define these terms, but you could view
> this as an oversampled 1 bit ADC - I'm not sure whether the sample
> rate is 5GHz or 100 MHz.

It's not.  The VCO won't run at 5 GHz unless your input voltage is very 
close to Vdd.


> Either way this is not important for my application, because I am not
> thinking of the VCO as an ADC.

I know, you aren't thinking of it as an ADC, but you are using it as an 
ADC.


>> you talk about the counter lsb as if this is somehow related to a very low
>> sensitivity voltage and it isn't.
> As explained above, a small change in the VCO frequency will be shown
> as a change in the summed counter value.

No, because the frequency shows up in the counter by taking the 
difference.


> The high digital resolution is because of the oversampling, and the
> high analog resolution is because of the summing ( or averaging ).

If you say so.


> I see it this way : the VCO is DC biassed to run at some frequency,
> say 1GHz, with a very small AC modulation applied to it ( from the
> antenna ).

Ok, now you are biasing the ADC input with the input superimposed.


> say the VCO runs between 1,000,000 Hz and 1,000,001 Hz as the AC
> signal changes ( a 1 part 10E9 change ).
> You read the VCO's counter every 10 ns, so you would see a count of
> 0 , 10 , 20 , 30  at the low frequency , with a missed count every
> 10E9 counts at the higher frequency. Average this over 1 second and
> you would see a change of 1 in the counter as the AC input changed
> ( 1,000,000 mod 2**18 or 1,000,001 mod 2** 18 ).

Ok, so now you are reading the entire counter, not just bit 0.  At the 
higher frequency you won't see a missed count, you will see a count of 
N+1.  This is how I am suggesting that you use the ADC as an ADC.  By 
"average" I assume you mean integrate or "sum"?  Average would loose 
data unless you use fractions and then it is really just the same as 
integrating with a wasteful division at the end.


> To express this in terms of ADC's, it is a 10 x oversampled 1 bit ADC,
> averaged over 1 second.

No, it is just the same ADC that is designed into the GA144 sampled very 
fast and then the differences added back together which is the same as 
just subtracting the first reading from the last.


> This has sacrificed analog range - you measure only deltas, but I am
> only interested in deltas.

That is how you use the ADC, take the delta of the counter readings. 
This gives you the integral of the voltage over the sample period.


> Given that you can display the change of 1 count on a PC screen, this
> means that you can detect a change on the input pin that causes a 1 in
> 10E9 change in frequency - this is the high analog sensitivity that I
> hope to see.

What voltage will result in the change of 1?  That depends on the period 
over which you integrate, it has nothing to do with the bias you apply. 
  In fact, if you look at the ADC input curve you will see that it is 
most sensitive at the mid range and by biasing it near Vdd you are in a 
very flat range with little sensitivity.


> The thing that makes the GA144 special is that the electrical circuit
> between input pin and counter is the smallest it could be, so there
> could be very small quantum effects that would probably not occur with
> a conventional ADC setup.

Please explain how these quantum effects will be observed?  What 
difference will this make on your readings?


>> While it is waiting for the input transition it is "asleep".
> I understand sleep mode in terms of chips like the MSP430, where the
> system clock is slowed down or stopped, and it takes some time to get
> it back to full speed.
> In the case of the MSP430 the design has been cleverly optimised for
> fast wake-up ( 6 us IIRC ).

Not 6 us, any processor can start up in 6 us if you keep the oscillator 
running or use gates for the oscillator.  The F18A stops to wait for an 
input and resumes in some time less than an instruction cycle.  They 
won't tell me how much of the port read instruction executes before the 
sleep and how much happens after the sleep.  But they tell me I am free 
to measure it for myself...


> Since the GA144 has no clock, it does not have a distinct sleep state,
> and therefore it has no wake up time.

That is your terminology.  Sleep means it is doing nothing and the 
processor is doing nothing while it is waiting for an input transition. 
  Call it a rose if that makes you feel better.


>>> In my experience, it is best never to use ADC's, but to convert the
>>> signal you want to measure into a time period.
>> Oh, do you have lots of experience with this?
> Yes - I have used time measurement in preference to voltage on many
> projects.
>
>> How does the GA144 measure time periods?
>> I think Chuck does it by tying the ADC input to Vdd which will run the VCO at max rate.
> Yes, that is my understanding too. Its just a fast counter. Is there
> any other way to measure time periods?
>
>> Notice that there is no input signal in this example.
>> Where would you connect your input signal?
> On a digital input of a neighbouring F18, so that it captures the VCO
> counter when the input changes state.

What is this input signal?  I thought we were talking about the antenna?


>> I thought you were interested in high resolution???  Now I'm very confused.
> I am interested in high resolution measurement of electrical charge
> flowing into the analog input pin.
> I think all this talk about ADC specs is confusing in this context...

No, what is confusing is that you won't talk about the ADC as an ADC. 
To measure electrical charge flowing (otherwise known as current) you 
need to add a resistor to turn the current into a voltage.  Then the ADC 
can measure the voltage.


>> I'm still confused, what is X again?
> X is  " how can I use the GA144's VCO as a very high resolution ADC?"
> Answer - you can't.
> Y is  " how can I use the GA144's VCO to measure very small analog
> changes on its input pin with very high resolution?" Answer - see
> above.

Ok, now I understand.  You don't want to measure voltage, charge *or* 
current, you want to measure ANALOG.  I can see why you don't want to 
use an ANALOG to DIGITAL converter to measure ANALOGs.  That would be 
pointless.   BTW, perhaps you should share with the Green Arrays people 
that their ADC can't measure with high resolution.  It will be news to 
them!!!


> I have found this thread very helpful, as it has forced me to organise
> and express my thoughts about what I would like to do with the GA144.
> Hopefully I will find some time soon to actually do these tests - I
> will report any results here :-)

Please keep us informed.  I am finding this very entertaining... sort of.

Rick

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-09-27 14:16 -0700
  Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-29 01:20 -0700
    Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-09-30 11:05 -0400
      Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 09:06 -0700
        Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-09-30 14:29 -0400
          Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 19:56 -0700
    Re: GA144 polyForth Coos Haak <chforth@hccnet.nl> - 2012-09-30 21:54 +0200
    Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-01 11:18 -0700
      Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-01 23:40 -0700
        Re: GA144 polyForth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-01 21:23 -1000
          Re: GA144 polyForth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-05 19:19 +0000
        Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-04 23:04 -0700
  Re: GA144 polyForth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-01 10:28 -0500
    Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-01 11:19 -0700
      Re: GA144 polyForth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-03 10:46 -0500
        Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-04 13:46 -0700
  Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-05 22:10 -0700
    Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-05 23:17 -0700
      Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-06 05:47 -0700
        Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-07 19:31 -0400
          Re: GA144 polyForth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-08 20:10 +0200
            Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-08 16:36 -0400
          Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-08 13:31 -0700
            Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-09 13:48 -0400
              Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-09 13:21 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-09 17:08 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 07:39 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 14:28 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 13:37 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 16:54 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 14:14 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 17:30 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-14 02:00 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-14 19:54 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-15 11:03 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-15 16:38 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-16 04:12 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-16 15:46 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-16 23:05 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-17 13:40 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-17 22:54 -0700
            Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 14:53 -0400
              Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 15:06 -0400
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 15:09 -0400
              Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-19 10:43 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-19 17:43 -0400
  Re: GA144 polyForth Mikael Nordman <oh2aun@invalid.com> - 2012-10-06 11:29 +0300
    Re: GA144 polyForth mhx@iae.nl (Marcel Hendrix) - 2012-10-06 11:14 +0200
      Re: GA144 polyForth Mikael Nordman <oh2aun@invalid.com> - 2012-10-06 16:08 +0300
    Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-07 10:57 -0700

csiph-web