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

Groups > comp.lang.forth > #16306

Re: GA144 polyForth

Show all headers | View raw

On 10/15/2012 2:03 PM, Howerd wrote:
> On Oct 15, 1:54 am, rickman<gnu...@gmail.com>  wrote:
>> On 10/14/2012 5:00 AM, Howerd wrote:
>>
>>> On Saturday, October 13, 2012 11:30:44 PM UTC+2, rickman wrote:
>>
>>> Hi Rick,
>>
>>>> Then you are looking for resolution, not VCO speed.
>>> I am looking for both - detection of very small signals and very small time intervals.
>>
>> In the GA144 the time interval will be determined by the CPU speed, I
>> think the best you might get is around 10 ns, but I don't recall
>> exactly, this might be for a clock timed loop that just takes the data
>> and passes it on.  At that speed you will only get 4.3 ENOB (effective
>> number of bits) theoretical max.  That's not very sensitive.
>>
>>>> Many other ADCs will give you very high resolution as well.
>>> Digital resolution, yes, but analog resolution probably not.
>>
>> Uh, yeah...  right.  It's time to learn about electronics.  You can
>> think that you are going to toss existing theory out the window, but
>> this is not the area that needs to be reinvented in order to learn
>> about... what was it you were exploring again?
>>
>>>> GA144 ADC for high resolution at very slow sample rates.
>>> I think you are using "resolution" in two different ways - there is analog resolution ( ability to detect a given change in voltage ), and ADC resolution ( number of bits ).
>>
>> Yes, they are related by the gain of your amplifiers... uh, if you had
>> amplifiers.  In the GA144 integrating ADC the analog resolution will be
>> related to the sample rate...  if you have a sample rate.  The faster
>> the sample rate the lower the analog resolution.  The 4.3 bits I mention
>> above are over the analog range of about 1.2 volts, this is not well
>> defined in the data sheet, so I'm not certain what this range is.  The
>> ADC has a non-linear curve with more resolution in the center which is
>> what I am assuming will be used.  Trying to get the full analog range of
>> 1.8 volts uses the compressed ranges near the limits with very low
>> analog resolution.
>>
>> The digital resolution is the number of bits.  The analog resolution is
>> the analog range divided by the number of bits.  No magic, no new
>> science to be invented.  The two are directly connected.  The only way
>> to improve the analog resolution is to slow down the measurement to give
>> longer integrations or to use an amplifier to get the same voltage range
>> at the ADC input with a smaller range on the amplifier input.
>>
>>>> The rate of the VCO is not the sample rate of the ADC
>>> It is if it is a 1-bit ADC, sort of.
>>
>> Ok, you can go ahead and think of this as a 1 bit ADC but that buys you
>> the worst possible resolution at the highest sample rate.
>>
>>> Its the analog resolution that I am interested in. I presume that the GA144's VCO is just a handful of transistors, so the bottom bit of the VCO count represents some very small change in the charge at the input pin.
>>
>> No, the counter bits do NOT correspond to anything at the input.  The
>> counter free runs at a rate between about 3.5 GHz and 5.5 GHz.  The raw
>> readings just keep incrementing and the absolute values mean nothing.
>> You get an ADC reading by SUBTRACTING one reading from the next.  This
>> DIFFERENCE is proportional to the integral of the voltage at the input
>> over the sample period.
>>
>> Actually, the range of the VCO in the linear area is only about 1.3 or
>> 1.4 GHz rather than the 2 GHz I used to calculate the ENOB.  The
>> frequency range is what determines the difference range and the ADC
>> resolution.
>>
>>> Only with the GA144 do I get very sensitive analog inputs together with some fast processing, plus a high level (eForth or polyForth) IDE, all on chip.
>>> I think this is magic :-)
>>
>> Yes, I expect it must seem like magic...  Or you could listen to people
>> who don't see it as magic, but rather understand the details and can
>> explain how it works as if it were engineering...
>>
>> I'm pretty sure you won't see anything in your signals using the GA144
>> that you can't see as well if not better using other devices.  For
>> example, how well will your readings be time correlated using multiple
>> ADCs in the GA144?  I can't get an answer to questions like this.  Or
>> even how long the GA144 nodes take to come out of sleep when the input
>> clock transitions.  These are *very* important numbers when using the
>> ADC for signal acquisition.  Random delays here cause signal
>> distortion/noise.
>>
>> Rick
>
> Hi Rick,
>
>> You can think that you are going to toss existing theory out the window,...
> Not at all - I am looking for observable effects predicted by existing
> theory.

Then why do you need to use something that you feel will uncover things 
that haven't been seen before?  If it fits in with existing theory, then 
it should be observable with existing technology.


>> The digital resolution is the number of bits.
> Ageed.
>
>> The analog resolution is the analog range divided by the number of bits.
> Only in the most simplistic model, ignoring oversampling, compressed
> sampling, and maybe some other effects.
>
> What concerns me here is that you seem to have such confidence in your
> theoretical models of what goes on in electronic circuits.
> Surely any theory only covers the available data, and must be modified
> when new data comes long that doesn't fit in.
> I want to look for new data...

That's fine, but my point is that you have said nothing understandable 
that indicates the GA144 will do anything any other ADC can't do.  You 
talk about 5 GHz as if it is the sample rate and it isn't, you talk 
about the counter lsb as if this is somehow related to a very low 
sensitivity voltage and it isn't.  Before you can even make a 
measurement with the GA144 ADC you need to understand how it works and 
how it doesn't work.


> I think the discussion of the GA144's ADC is missing the point. Let me
> try to explain by describing two circuits :
>
> 1. An antenna, RF amplifier, anti-aliassing filter, very fast ADC,
> fast DSP. Say some electrons wander down the antenna - what does it
> take to observe a change in the DSP's output?

Your use of "DSP's output" is not clear.  Do you mean the ADC output? 
To see a change you need enough voltage at the input to the ADC to cross 
one of the many thresholds in the ADC.  This will of course on the 
voltage change at the antenna, the characteristics of the filter and the 
gain of the amplifier.


> 2. An antenna connected to the VCO input of an F18. The VCO is
> presumably very few FET's arranged to oscillate, clocking a line of
> edge triggered flip-flops. Bit 0 of the counter is averaged at, say,
> 100 Mhz rate.

This made sense until you talk about bit 0 "averaged at" 100 MHz.  I 
don't know what that means.  The frequency of the VCO output will vary 
between the values I listed the other day.  Bit 0 will toggle at half 
that rate.  Of course, this rate varies with the voltage of the input 
signal.


> I predict that #2 would be more sensitive, i.e. it would take fewer
> electrons to make a visible change. There is also significantly more
> possibility of quantum coupling efects occuring over just a few
> transistors than over circuit #1.

Quantum coupling to what?  How will the VCO frequency change with 
quantum coupling?  What in the GA144 will let you detect quantum 
coupling if it does happen?  I don't recall a quantum coupling detector 
listed in the data sheet.

I don't see how the GA144 is any more sensitive to the antenna signal 
than the GA144.  In fact the GA144 can be fairly insensitive depending 
on the sample rate.  At high sample rates it is very insensitive.


> Also, if I do not find any interesting new effects using the GA144,
> there is not much more to be done, besides going to a faster chip
> process, since this looks to me like the absolute minimum number of
> components to convert a signal at the antenna to something useable.
>
> I have nothing against circuit #1 - it does exactly what it is
> designed to do.
>
> Here are some questions that might be answered experimentally by the
> GA144 :
>
> 1. does electrical current flowing down a wire have oribital angular
> momentum (OAM), and if so could this be useful?

If you are going to measure this, you need to predict outcomes.  What 
will be observed if you do detect OAM?  What will be observed if you 
don't detect OAM?  Until you can answer that question there is no 
experiment really.


> 2. if a radio wave containing OAM arrives at two antennas, can the OAM
> be detected by two F18 VCO's ?

I give up, can it?


> 3. is it posible to demodulate RF signals using an GA144 by applying
> simple fast algorithms?

I can answer this one, yes.  Just like you can demodulate RF signals 
using simple, fast algorithms on any other processor.


>> how well will your readings be time correlated using multiple ADCs in the GA144?
> This interests me too. There are two F18's with analog pins next to
> each other, so it would be possible to have one waiting for the other
> with just the latching time of the ports between them. I would expect
> jitter of around 10ns if the F18 cores are also doing something useful
> with the data, but this is really just a guess.

10 ns is a long time in the RF world.  If you sample a 100 MHz carrier 
(middle of the FM band) this is an entire cycle of the carrier, 360 
degrees, 2 pi radians, lots of confusion possible here.

Some folks posting here who worked with GA claim there can be low double 
digit ps of uncertainty in the sampling time, but I think this depends 
on a great many factors and I can't get answers out of GA to confirm any 
of it.


>> Or even how long the GA144 nodes take to come out of sleep when the input clock transitions.
> As I understand this, the GA144 doesn't "go to sleep" - it is clocked
> by receiving an instruction on one of its ports.
> So no time at all.

Hmmm, a difference of nomenclature.  When I say "sleep" and you say 
"clocked" we are talking about the same thing.  While it is waiting for 
the input transition it is "asleep".  Or you could say it is "crouched" 
like a cat, waiting to "spring" and "pounce" on its "prey", opps, I mean 
"data".  Cat like reflexes!  Yes, I want Schrödinger's cat in my CPUs...


> The VCO-counting-ADC is free running, so any two would be independent.
> You could synchronise reading them, but the read pulse would not be
> connected to the VCO, so I would expect a lot of jitter. I think the
> GA144's ADC's are good for audio maybe, but not for low jitter, high
> speed, high resolution measurements.

I thought you were interested in high resolution???  Now I'm very confused.


> In my experience, it is best never to use ADC's, but to convert the
> signal you want to measure into a time period. The GA144 is good at
> measuring time periods...

Oh, do you have lots of experience with this?  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.  After calibrating (somehow) he 
examines the counter at the start and the end of a time period.  Is this 
what you mean?  Notice that there is no input signal in this example. 
Where would you connect your input signal?


> I'm sorry if this sounds like the classic Forth question and answer :
> Q. how would you do X in Forth? A. don't do X, do Y.

I'm still confused, what is X again?  No, what is Y?  No, I am asking 
"why", no, I want to know "ex"...

Who's on first?

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