OK, since I threw out the webcam idea --  a few notes.

1) Webcams only send a bitmap picture to the PC.  It's up to the 
software on the PC what to do next.  And typically most of these pgms do 
a compression such as JPG or other for transmission over the web.  It is 
not compressed coming from the camera other than realizing there may be 
amplitude compression of highlights clipped due to the typical 8 bit 
(256 levels) of the A/D process in the camera chip or the submersion of 
the picture information in the noise floor due to inadequate light.  
Some chips have variable aperture (akin to an old time camera shutter 
time) times to help with this problem.  The video rate is not due to the 
typical TV standard of 30 frames a second of 60 interlaced fields a 
second (US standard. NTSC that is, 50 and 100 respectively in Britain 
and many other places.)  Earlier webcams couldn't even hit 30 frames a 
second and they didn't have a field rate as they don't interlace because 
they're just sending bitmap pictures anyway.  (Interlace is a solution 
to a very old problem that started with analog TV picture tubes combined 
with the retrace (flyback) times associated with the magnetic scanning 
of the picture tube.) That being said, optical mice hit higher update 
rates mainly because they're working with smaller images and not sending 
that data to the PC. (See the next item: 2).

2) The optical mouse idea has shown up before in conjunction with a 
colleague of Randall Peters.  I have discussed it a bit.  I feel it has 
a couple of problems and I have not heard back on those objections.
A) The sensor in a mouse is typically only from about 16x16 to 30x30 
pixels.  A webcam is around 640x480 -- a big difference that plays into 
your eventual sensitivity and range.  I argue that if you're using a 
webcam that digitizes to 8 bits you will also be able to improve the 
position resolution beyond the 640x480 in the same way the optical mouse 
does -- do a centroid calculation on the dot in the image.
B) I'm only aware of a few early HP sensors that also allowed a jumper 
configuration that would allow you to view through the USB interface 
what the sensor was seeing.  A very necessary condition in light of the 
next comment.
C) The experiments I did on optical mice showed that the centroid 
calculation had "slippage".  I.e., you place the mouse on a surface and 
move it back and forth across the surface to a hard stop point.  The 
zero will drift indicating that the centroid calculation is apparently 
rounding off some data and gradually moving the starting data point.  
This centroid calculation of the hills and valleys of the roughness of 
the surface is converted to a distance moved number that is added or 
subtracted to the running total.  That movement number is then sent to 
the PC, not the actual picture data.  Since you have a larger sensor in 
the webcam, you can constrain the centroid calculation to an absolute 
position and this drift is not a factor.  Actual physical drift of the 
seismic sensor will still exist, but the integration of the physical 
sensor zero can be set to hours in the PC calculation with no problem 
until the laser dot drifts off the optical sensor.

3) The original post of this question had a link to a video that showed 
significant movement (noisy ground floor in the signal processing 
sense?).  That being true, the movement was more than sufficient to move 
across the laser dot across the surface of an optical sensor in a webcam 
(some 8x6 mm).  That then being said, the webcam sensor is sufficient to 
work with the source of the dot.  Whether the dot is of any use in a 
seismic sense is an entirely different question and was not the thrust 
of this answer.  (I'm not trying to start a flame war here, I'm just 
trying to contain the scope of the discussion to the original question 
of, "..how to digitized the dot's position?").  If it's of interest we 
can start another discussion about the ultimate possible sensitivity of 
such a scheme by noting the conversion factor of the physical sensor in 
converting physical ground motion to light beam displacement and 
multiplying it by the number of pixels per mm (approximately 80/mm.)

4) And as to the starting from ground zero I might suggest this link for 
a possible starting point:
http://www.codeproject.com/Articles/125478/Versatile-WebCam-C-library
It gets you past the USB and menus and allows you direct access to the 
returned image for follow-on processing of the image.

Regards,
Charles R. Patton



On 3/27/2013 5:28 AM, Brett Nordgren wrote:
> The only problem I can see is that the sensitivity you typically find 
> in a good instrument may be somewhat higher than what you are 
> considering.  For example, with the FBV instruments being operated by 
> Dave Nelson, a 2 Hz sinusoidal ground motion which registers 10 counts 
> peak-peak on Larry's A/D would represent a ground motion of ~8nm p-p 
> or about 18x the 0.44nm diameter of a large atom (Potassium).  So one 
> A/D count at 2Hz represents a motion of about 1.8x an atomic 
> diameter.  And most seismic observatories using 24-bit A/Ds are about 
> 5x more sensitive.
>
> For a really good instrument, one needs to be thinking in terms of 
> devices which can detect very small motions, though, in practice, an 
> instrument's true sensitivity will be determined by its internal 
> noise, not simply its bit-resolution.
>
> Regards,
> Brett
>
> At 06:47 PM 3/26/2013, you wrote:
>> On 26/03/13 23:56, Geoff wrote:
>>> I like the idea of using a WEBcam or something to look at the red dot
>>> then use a custom program to read the video and turn the graphic data
>>> into rectangular coordinates of a standard four quadrant graph
>>> with the point resting in the center of the graph
>>> But to do this in near real time may not be possible for myself to do.
>>> The max rate will be like 30Hz to 60Hz which is a video frame rate.
>>> Video is usually encoded and needs to be uncompressed.
>>> Uncompressing video takes lots of time to do so like a
>>> series of BMP captures at whatever rate would be the thing to do.
>>> You would take screenies at like 30 per second in a modulo fashion
>>> then save all after an alarm and the series of like
>>> 108000 BMP images would be decoded into a series of (X,Y) 
>>> coordinates ??
>>
>> This sounds a bit like a modified optical mouse.
>>

__________________________________________________________

Public Seismic Network Mailing List (PSNLIST)

To leave this list email PSNLIST-REQUEST@.............. with 
the body of the message (first line only): unsubscribe
See http://www.seismicnet.com/maillist.html for more information.