Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

And some more talking about ADC

And some more talking about ADC

2007-06-11 by kernels_nz

Hi guys, I have a curly one, any creative suggestions would be
appreciated.

Im interested in digitzing a B/W video waveform from a standard CMOS
security camera, im only really interested in one line of video but
the conversion time of the average AVR A2D is around 13-50us but the
whole video frame is around 50us. 

I know I can overclock the AVR A2D to around 1MHz, but that still
would only give 4 conversions per video frame.

So, a few ways that I could see around the problem is:

1. Faster external ADC -> Not ideal because it adds cost, componets
and it's hard to get hold of Megasample ADCs. Also, having a fast
external ADC is useless unless you can communicate with it at super speed.

2. Slow down "time" somehow so that I buffer a frame of video
"somehow" and convert it at my leasure using the inbuilt ADC. <- This
method requires "magic" and im not sure what type ? maybe someone has
come across some way of doing this ?

3. Use some of the "line" cameras that allow me to clock the video
data out pixel by pixel. <- I can do this, and we even have the
cameras available @ work, but I would prefer to use a off-the-shelf
cheap video camera.

Any other ideas?

Thanks !

Hein B
Auckland, New Zealand.

Re: [AVR-Chat] And some more talking about ADC

2007-06-11 by dlc

You're looking at using a dedicated ADC chip here.  The fastest ones are 
parallel out, but the newer SPI based ones are also pretty fast.

DLC

kernels_nz wrote:
> Hi guys, I have a curly one, any creative suggestions would be
> appreciated.
> 
> Im interested in digitzing a B/W video waveform from a standard CMOS
> security camera, im only really interested in one line of video but
> the conversion time of the average AVR A2D is around 13-50us but the
> whole video frame is around 50us. 
> 
> I know I can overclock the AVR A2D to around 1MHz, but that still
> would only give 4 conversions per video frame.
> 
> So, a few ways that I could see around the problem is:
> 
> 1. Faster external ADC -> Not ideal because it adds cost, componets
> and it's hard to get hold of Megasample ADCs. Also, having a fast
> external ADC is useless unless you can communicate with it at super speed.
> 
> 2. Slow down "time" somehow so that I buffer a frame of video
> "somehow" and convert it at my leasure using the inbuilt ADC. <- This
> method requires "magic" and im not sure what type ? maybe someone has
> come across some way of doing this ?
> 
> 3. Use some of the "line" cameras that allow me to clock the video
> data out pixel by pixel. <- I can do this, and we even have the
> cameras available @ work, but I would prefer to use a off-the-shelf
> cheap video camera.
> 
> Any other ideas?
> 
> Thanks !
> 
> Hein B
> Auckland, New Zealand.
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

Re: [AVR-Chat] And some more talking about ADC

2007-06-11 by Jim Wagner

On Mon, 11 Jun 2007 02:48:22 -0000
 "kernels_nz" <kernels@slingshot.co.nz> wrote:
> Hi guys, I have a curly one, any creative suggestions
> would be
> appreciated.
> 
> Im interested in digitzing a B/W video waveform from a
> standard CMOS
> security camera, im only really interested in one line of
> video but
> the conversion time of the average AVR A2D is around
> 13-50us but the
> whole video frame is around 50us. 
> 
> I know I can overclock the AVR A2D to around 1MHz, but
> that still
> would only give 4 conversions per video frame.
> 
> So, a few ways that I could see around the problem is:
> 
> 1. Faster external ADC -> Not ideal because it adds cost,
> componets
> and it's hard to get hold of Megasample ADCs. Also,
> having a fast
> external ADC is useless unless you can communicate with
> it at super speed.
> 
> 2. Slow down "time" somehow so that I buffer a frame of
> video
> "somehow" and convert it at my leasure using the inbuilt
> ADC. <- This
> method requires "magic" and im not sure what type ? maybe
> someone has
> come across some way of doing this ?
> 
> 3. Use some of the "line" cameras that allow me to clock
> the video
> data out pixel by pixel. <- I can do this, and we even
> have the
> cameras available @ work, but I would prefer to use a
> off-the-shelf
> cheap video camera.
> 
> Any other ideas?
> 
> Thanks !
> 
> Hein B
> Auckland, New Zealand.
> 

No, one video line is about 64us (very close to same for
NTSC and PAL).

Philips (now NXP) makes a whole bunch of video ditizer ICs.
They are very nice and do the synchronizing, etc for you.
You would need a video sync detector for any digitizer
solution.

The simplest, by far, would be a line sensor, I think.
Within limits you can clock it at any rate you want. 

Jim


---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

Atmega162 shared interrupt PCINT10 and timer

2007-06-11 by Sandu Teo

Hello
   
  I am working at a sonar sistem .
  When the sensor detects something, a response is sent to the mirocontroller on PORTC.2
  I have enabled PCINT10 which works on that pin.
   
  I send some pulses on PORTC.0 and I start TIMER0 and after that ,I wait for response on PORTC.2
   
  I have an oscilloscope and I monitor the signal sent to PORTC.2
  The sensor sends the right response on that PIN. 
  When the respons comes, PCINT0 interrupt routine is served and the timer is stopped.
   
  The problem is that the timer does not report the right value.
   
  I use Timer0 at 2Mhz on Atmega162 at 16Mhz.
  The time needed to be counted, between sending and response is about 700 us.
  In timer0 interrupt routine I increment a counter that counts timer overflows.
  I have also tried with Timer1 [16 bit mode]
   
  Any ideea
   
   

 
---------------------------------
Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.

[Non-text portions of this message have been removed]

Re: And some more talking about ADC

2007-06-11 by Bruno Muswieck

Hi Hein.

I'm thinking that is two ways that you could take.

1 - You should pick an faster ADC and even that, you should use an 
integer to get less pixels so less faster should be your read from 
the camera signal.

2 - There are some equipaments that has an camera and an processor 
built-in that give to you a picture in jpeg via serial link. But 
this will be only picture.

Bruno - Brazil

--- In AVR-Chat@yahoogroups.com, "kernels_nz" <kernels@...> wrote:
>
> Hi guys, I have a curly one, any creative suggestions would be
> appreciated.
> 
> Im interested in digitzing a B/W video waveform from a standard 
CMOS
> security camera, im only really interested in one line of video but
> the conversion time of the average AVR A2D is around 13-50us but 
the
> whole video frame is around 50us. 
> 
> I know I can overclock the AVR A2D to around 1MHz, but that still
> would only give 4 conversions per video frame.
> 
> So, a few ways that I could see around the problem is:
> 
> 1. Faster external ADC -> Not ideal because it adds cost, componets
> and it's hard to get hold of Megasample ADCs. Also, having a fast
> external ADC is useless unless you can communicate with it at 
super speed.
> 
> 2. Slow down "time" somehow so that I buffer a frame of video
> "somehow" and convert it at my leasure using the inbuilt ADC. <- 
This
> method requires "magic" and im not sure what type ? maybe someone 
has
Show quoted textHide quoted text
> come across some way of doing this ?
> 
> 3. Use some of the "line" cameras that allow me to clock the video
> data out pixel by pixel. <- I can do this, and we even have the
> cameras available @ work, but I would prefer to use a off-the-shelf
> cheap video camera.
> 
> Any other ideas?
> 
> Thanks !
> 
> Hein B
> Auckland, New Zealand.
>

Re: [AVR-Chat] And some more talking about ADC

2007-06-11 by BobGardner@aol.com

> Any other ideas?



============================================

The first frame grabbers were programmed io from the parallel port.... wait for vert sync,

 wait for the line you want, grab a line. If the picture is fairly steady, should be able to

 get the next line every field... 


________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free from AOL at AOL.com.


[Non-text portions of this message have been removed]

Re: [AVR-Chat] And some more talking about ADC

2007-06-11 by Ken Holt

You may already know that almost all CMOS sensor chips and
modules provide a digital output only, through a variety of serial
I/Fs.
Ken

kernels_nz wrote:
Show quoted textHide quoted text
> Hi guys, I have a curly one, any creative suggestions would be
> appreciated.
>
> Im interested in digitzing a B/W video waveform from a standard CMOS
> security camera, im only really interested in one line of video but
> the conversion time of the average AVR A2D is around 13-50us but the
> whole video frame is around 50us.
>
> I know I can overclock the AVR A2D to around 1MHz, but that still
> would only give 4 conversions per video frame.
>
> So, a few ways that I could see around the problem is:
>
> 1. Faster external ADC -> Not ideal because it adds cost, componets
> and it's hard to get hold of Megasample ADCs. Also, having a fast
> external ADC is useless unless you can communicate with it at super speed.
>
> 2. Slow down "time" somehow so that I buffer a frame of video
> "somehow" and convert it at my leasure using the inbuilt ADC. <- This
> method requires "magic" and im not sure what type ? maybe someone has
> come across some way of doing this ?
>
> 3. Use some of the "line" cameras that allow me to clock the video
> data out pixel by pixel. <- I can do this, and we even have the
> cameras available @ work, but I would prefer to use a off-the-shelf
> cheap video camera.
>
> Any other ideas?
>
> Thanks !
>
> Hein B
> Auckland, New Zealand.
>
>

Re: [AVR-Chat] And some more talking about ADC

2007-06-11 by Samir Lohani

For an ARM based implementation using a digital still
video source, see my project "Video Frame Grabber"
among the DE entries of Luminary ARM contest.

The URL is
http://www.circuitcellar.com/designstellaris2006/winners/DE/LM1719.htm

Cheers,
Samir.

--- Jim Wagner <jim_d_wagner@applelinks.net> wrote:

> On Mon, 11 Jun 2007 02:48:22 -0000
>  "kernels_nz" <kernels@slingshot.co.nz> wrote:
> > Hi guys, I have a curly one, any creative
> suggestions
> > would be
> > appreciated.
> > 
> > Im interested in digitzing a B/W video waveform
> from a
> > standard CMOS
> > security camera, im only really interested in one
> line of
> > video but
> > the conversion time of the average AVR A2D is
> around
> > 13-50us but the
> > whole video frame is around 50us. 
> > 
> > I know I can overclock the AVR A2D to around 1MHz,
> but
> > that still
> > would only give 4 conversions per video frame.
> > 
> > So, a few ways that I could see around the problem
> is:
> > 
> > 1. Faster external ADC -> Not ideal because it
> adds cost,
> > componets
> > and it's hard to get hold of Megasample ADCs.
> Also,
> > having a fast
> > external ADC is useless unless you can communicate
> with
> > it at super speed.
> > 
> > 2. Slow down "time" somehow so that I buffer a
> frame of
> > video
> > "somehow" and convert it at my leasure using the
> inbuilt
> > ADC. <- This
> > method requires "magic" and im not sure what type
> ? maybe
> > someone has
> > come across some way of doing this ?
> > 
> > 3. Use some of the "line" cameras that allow me to
> clock
> > the video
> > data out pixel by pixel. <- I can do this, and we
> even
> > have the
> > cameras available @ work, but I would prefer to
> use a
> > off-the-shelf
> > cheap video camera.
> > 
> > Any other ideas?
> > 
> > Thanks !
> > 
> > Hein B
> > Auckland, New Zealand.
> > 
> 
> No, one video line is about 64us (very close to same
> for
> NTSC and PAL).
> 
> Philips (now NXP) makes a whole bunch of video
> ditizer ICs.
> They are very nice and do the synchronizing, etc for
> you.
> You would need a video sync detector for any
> digitizer
> solution.
> 
> The simplest, by far, would be a line sensor, I
> think.
> Within limits you can clock it at any rate you want.
> 
> 
> Jim
> 
> 
>
---------------------------------------------------------------
> The Think Different Store
> http://www.thinkdifferentstore.com/
> For All Your Mac Gear
>
---------------------------------------------------------------
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
> 
> 



       
____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

Re: And some more talking about ADC

2007-06-11 by kernels_nz

Thanks everyone for the great ideas, I will look into them, It looks
like at this stage ill buy some cheap cameras and take them apart to
try and see what type of CMOS image sensor they use and whether I can
interface to this sensor directly. The line-scan cameras we use @ work
are nice, but this project is for hobby-robotics, so I would like to
try and build the "eye" from standard off-the-shelf type sensors. a
CMOS image sensor will be great if I can interface to it manually. 

Will keep everybody up to speed on how it goes.

Thanks again
Regards
Hein B
Auckland, New Zealand.


--- In AVR-Chat@yahoogroups.com, Ken Holt <kholt@...> wrote:

> You may already know that almost all CMOS sensor chips and
> modules provide a digital output only, through a variety of serial
> I/Fs.
> Ken
> 
> kernels_nz wrote:
> 
> > Hi guys, I have a curly one, any creative suggestions would be
> > appreciated.
> >
> > Im interested in digitzing a B/W video waveform from a standard CMOS
> > security camera, im only really interested in one line of video but
> > the conversion time of the average AVR A2D is around 13-50us but the
> > whole video frame is around 50us.
> >
> > I know I can overclock the AVR A2D to around 1MHz, but that still
> > would only give 4 conversions per video frame.
> >
> > So, a few ways that I could see around the problem is:
> >
> > 1. Faster external ADC -> Not ideal because it adds cost, componets
> > and it's hard to get hold of Megasample ADCs. Also, having a fast
> > external ADC is useless unless you can communicate with it at
super speed.
Show quoted textHide quoted text
> >
> > 2. Slow down "time" somehow so that I buffer a frame of video
> > "somehow" and convert it at my leasure using the inbuilt ADC. <- This
> > method requires "magic" and im not sure what type ? maybe someone has
> > come across some way of doing this ?
> >
> > 3. Use some of the "line" cameras that allow me to clock the video
> > data out pixel by pixel. <- I can do this, and we even have the
> > cameras available @ work, but I would prefer to use a off-the-shelf
> > cheap video camera.
> >
> > Any other ideas?
> >
> > Thanks !
> >
> > Hein B
> > Auckland, New Zealand.
> >
> >
>

Re: And some more talking about ADC

2007-06-12 by Andy Clark

You could try the GameBoy camera, check out my old pages (if they still 
work) at...

http://pages.zoom.co.uk/andyc/

It has digital control but an analog output.  You can (pretty much) 
clock the data out at any rate although bear in mind that frame 
exposure is a function of clock speed - slow clock=greater exposure.

If it looks promising, Google will find sites with much better info 
than mine and you can pick up the camera from ebay for coppers.
 
At the moment I'm grabbing frames into an AT91SAM7S at 280KHz/pixel 
through the onboard adc.

Regards

Andy

Re: [AVR-Chat] Atmega162 shared interrupt PCINT10 and timer

2007-06-12 by Reza

--- Sandu Teo <teodorstv@yahoo.com> wrote:

> Hello
>    
>   I am working at a sonar sistem .
>   When the sensor detects something, a response is
> sent to the mirocontroller on PORTC.2
>   I have enabled PCINT10 which works on that pin.
>    
>   I send some pulses on PORTC.0 and I start TIMER0
> and after that ,I wait for response on PORTC.2
>    
>   I have an oscilloscope and I monitor the signal
> sent to PORTC.2
>   The sensor sends the right response on that PIN. 
>   When the respons comes, PCINT0 interrupt routine
> is served and the timer is stopped.
>    
>   The problem is that the timer does not report the
> right value.
>    
>   I use Timer0 at 2Mhz on Atmega162 at 16Mhz.
>   The time needed to be counted, between sending and
> response is about 700 us.
>   In timer0 interrupt routine I increment a counter
> that counts timer overflows.
>   I have also tried with Timer1 [16 bit mode]
>    
>   Any ideea
>    
>    
Hi;

As i understand, your main problem is to measure the
time between 
outgoing and incoming pulse with best resolution.
using a timer interrupt is something wrong because 
timer works for a period of time, in interrupt service
routine 
the timer stops and starts again, which the processing
time of
interrupt routine is not counted, except you using
timer in CTC mode.
so you need to use timer channel as a counter, and
count number of 
logical overflows happened, see the pseoudo code:

assume using 8 bits counter.

    send the out-pulse
    reset the counter
    while incoming pulse not reached
        check the counter value
        check 7th bit of counter 
        if set, increment local register counter
        and reset counter into (count & 127)
    end while
    get the counter value and combine with local
counter.

note that because this process is a time-critical
process,
you need to use an external clock like microcontroller
XTAL signal buffered using a 74HC244 buffer.
but in any cases instruction execution time must be
calculated in operations:

    clr r24        // clear variable to zero
    clr r25        // "
    cli            // no interrupts during detection
    out TCNT0,r1   // clear counter to measure time
    sbi PORTC,0    // start sonar signal
loop:
//BEGIN OF REGION #3
    sbic PORTC,2   // wait for incoming pulse
    rjmp break_loop
    sbic TCNT0,7   // check counter overflow
//END OF REGION #3 // time = 3 ticks
//BEGIN OF REGION #1
    rjmp no_overflow	// in this region (#1) rjmp
skipped, so time=1
    cbi  TCNT0,7   // reset counter overflow bit
    adiw r24,1     // increment local counter
    rjmp loop
//END OF REGION #1	// 6 ticks
no_overflow:
//BEGIN OF REGION #2
    nop
    nop
    nop
    nop
    rjmp loop
//END OF REGION #2	// 6 ticks (MUST be same as REGION
#1)
break_loop:
    in   r23,TCNT0
    sei

you should note that using timer is to implement an
asynchronous 
timing operation while other codes are executed, so we
using timer in case of a counter.

but, the timing is very important:

execution time of loop if no signals found (one
iteration) is:
   A + B + C1 + C2 - errors
   A = (execution time of either region #1 or #2 (MUST
be same))
   B = execution time of region #3

   C1, C2 are the fixed code parts between clearing
TCNT0 and setting PORTC.0
          and the time between detecting PORTC.2 to be
set and get the value of TCNT
   errors is the time which is somehow same as (C1+C2)

so for a typical AVR micro, one iteration takes 6 + 3
= 9 ticks
the overflow counting variable counts the each 128
ticks.

so entire result time could be calculated using this
formula:

   ((r25:r24)*128) + r23 ticks

which using a 16MHz signal, you can measure up to
(65535*128+127) = 8388607 ticks # 524 ms.

but if you want to set a timeout to break the loop if
sonar pulse not returned, insert your code
into region #1, and add more nop operations in region
#2 before rjmp instruction and recalculate
the measure using new times. but in this case, the
minimum detectable time is 5 ticks
( at 16MHz, less than 1/2 micro-second )

i hope this helps;
good luck;



 
____________________________________________________________________________________
Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097

Re: [AVR-Chat] Atmega162 shared interrupt PCINT10 and timer

2007-06-12 by Reza

--- Sandu Teo <teodorstv@yahoo.com> wrote:

> Hello
>    
>   I am working at a sonar sistem .
>   When the sensor detects something, a response is
> sent to the mirocontroller on PORTC.2
>   I have enabled PCINT10 which works on that pin.
>    
>   I send some pulses on PORTC.0 and I start TIMER0
> and after that ,I wait for response on PORTC.2
>    
>   I have an oscilloscope and I monitor the signal
> sent to PORTC.2
>   The sensor sends the right response on that PIN. 
>   When the respons comes, PCINT0 interrupt routine
> is served and the timer is stopped.
>    
>   The problem is that the timer does not report the
> right value.
>    
>   I use Timer0 at 2Mhz on Atmega162 at 16Mhz.
>   The time needed to be counted, between sending and
> response is about 700 us.
>   In timer0 interrupt routine I increment a counter
> that counts timer overflows.
>   I have also tried with Timer1 [16 bit mode]
>    
>   Any ideea
>    
>    
Hi;

As i understand, your main problem is to measure the
time between 
outgoing and incoming pulse with best resolution.
using a timer interrupt is something wrong because 
timer works for a period of time, in interrupt service
routine 
the timer stops and starts again, which the processing
time of
interrupt routine is not counted, except you using
timer in CTC mode.
so you need to use timer channel as a counter, and
count number of 
logical overflows happened, see the pseoudo code:

assume using 8 bits counter.

    send the out-pulse
    reset the counter
    while incoming pulse not reached
        check the counter value
        check 7th bit of counter 
        if set, increment local register counter
        and reset counter into (count & 127)
    end while
    get the counter value and combine with local
counter.

note that because this process is a time-critical
process,
you need to use an external clock like microcontroller
XTAL signal buffered using a 74HC244 buffer.
but in any cases instruction execution time must be
calculated in operations:

    clr r24        // clear variable to zero
    clr r25        // "
    cli            // no interrupts during detection
    out TCNT0,r1   // clear counter to measure time
    sbi PORTC,0    // start sonar signal
loop:
//BEGIN OF REGION #3
    sbic PORTC,2   // wait for incoming pulse
    rjmp break_loop
    sbic TCNT0,7   // check counter overflow
//END OF REGION #3 // time = 3 ticks
//BEGIN OF REGION #1
    rjmp no_overflow	// in this region (#1) rjmp
skipped, so time=1
    cbi  TCNT0,7   // reset counter overflow bit
    adiw r24,1     // increment local counter
    rjmp loop
//END OF REGION #1	// 6 ticks
no_overflow:
//BEGIN OF REGION #2
    nop
    nop
    nop
    nop
    rjmp loop
//END OF REGION #2	// 6 ticks (MUST be same as REGION
#1)
break_loop:
    in   r23,TCNT0
    sei

you should note that using timer is to implement an
asynchronous 
timing operation while other codes are executed, so we
using timer in case of a counter.

but, the timing is very important:

execution time of loop if no signals found (one
iteration) is:
   A + B + C1 + C2 - errors
   A = (execution time of either region #1 or #2 (MUST
be same))
   B = execution time of region #3

   C1, C2 are the fixed code parts between clearing
TCNT0 and setting PORTC.0
          and the time between detecting PORTC.2 to be
set and get the value of TCNT
   errors is the time which is somehow same as (C1+C2)

so for a typical AVR micro, one iteration takes 6 + 3
= 9 ticks
the overflow counting variable counts the each 128
ticks.

so entire result time could be calculated using this
formula:

   ((r25:r24)*128) + r23 ticks

which using a 16MHz signal, you can measure up to
(65535*128+127) = 8388607 ticks # 524 ms.

but if you want to set a timeout to break the loop if
sonar pulse not returned, insert your code
into region #1, and add more nop operations in region
#2 before rjmp instruction and recalculate
the measure using new times. but in this case, the
minimum detectable time is 5 ticks
( at 16MHz, less than 1/2 micro-second )

i hope this helps;
good luck;



       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

Re: And some more talking about ADC

2007-06-12 by kernels_nz

Hi Andy,

Thats awesome information, thanks heaps, I see they sell on the NZ
version of EBAY for Around US$15, cant wait to give it a go. 

For anyone following this thread, it appears that with just about any
cheap webcam or digital camera, you can extract and desolder the CMOS
sensor and interface to it via either parallel or serial, meaning you
control the data transfer speed. I have ordered some cheap as 300k
color digital cameras from my local electronics shop, will pull them
apart and have a go at interfacing to the CMOS sensor.

I have had a look at some of the cmos sensors from webcams we have at
work and if you look inside the window of the sensor with a
microscope, you can usually read the manufacturer and part number
etched into the die, very cool. Had a look inside the Elis 1024
Panavision chip and it actually has "Joe eats worms" etched on the
die, very funny.

Will keep updating this thread with my progress.

Cheers
Hein B
Auckland, New Zealand.

--- In AVR-Chat@yahoogroups.com, "Andy Clark" <andy.clark@...> wrote:
Show quoted textHide quoted text
>
> You could try the GameBoy camera, check out my old pages (if they still 
> work) at...
> 
> http://pages.zoom.co.uk/andyc/
> 
> It has digital control but an analog output.  You can (pretty much) 
> clock the data out at any rate although bear in mind that frame 
> exposure is a function of clock speed - slow clock=greater exposure.
> 
> If it looks promising, Google will find sites with much better info 
> than mine and you can pick up the camera from ebay for coppers.
>  
> At the moment I'm grabbing frames into an AT91SAM7S at 280KHz/pixel 
> through the onboard adc.
> 
> Regards
> 
> Andy
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.