Camera connection on XUPV2P

Hello,

I've some issues hooking up some external components (camera link based
cameras) to my XUPV2P board. I've built a PCB which connects the high
speed expansion port of the XUPV2P to the outputs of the National Chip
DS90CR288A. I've two cameras running simultaneously, so thats two chips on
the PCB. 

On the high speed expansion port of the XUPV2P there's a clock input, but
because I've got two external clocks (one from each chip), I decided to
attach them to the 'regular' FPGA pins. Sorry if this makes no sense! The
other high speed expansion port connections are connected to the data
signals, and data-valid signals from the chips.

I've created a peripheral which samples the camera data according to these
clock signals, and then sampled again using the Bus2IP clock. I use a
microblaze processor just to output various data. On the scope, my clock
signals seem to have a period of 16ns, is this too fast for what I want to
do? The voltage swing is about 600mV. My design doesn't seem to be working!
Just wondered if anyone had any suggestions comments on how best to debug
and proceed.

On Jan 3, 10:28 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
> Hello,
>
> I've some issues hooking up some external components (camera link based
> cameras) to my XUPV2P board. I've built a PCB which connects the high
> speed expansion port of the XUPV2P to the outputs of the National Chip
> DS90CR288A. I've two cameras running simultaneously, so thats two chips on
> the PCB.
>
> On the high speed expansion port of the XUPV2P there's a clock input, but
> because I've got two external clocks (one from each chip), I decided to
> attach them to the 'regular' FPGA pins. Sorry if this makes no sense! The
> other high speed expansion port connections are connected to the data
> signals, and data-valid signals from the chips.
>
> I've created a peripheral which samples the camera data according to these
> clock signals, and then sampled again using the Bus2IP clock. I use a
> microblaze processor just to output various data. On the scope, my clock
> signals seem to have a period of 16ns, is this too fast for what I want to
> do? The voltage swing is about 600mV. My design doesn't seem to be working!
> Just wondered if anyone had any suggestions comments on how best to debug
> and proceed.

I would first check that the clocks are being received properly by
the V2P.  Add a T flip-flop on each input clock and drive it to an
I/O or LED that is easy to scope.  Check that the frequency is
1/2 of the input frequency and that you don't get runt pulses or
other undesired behavior.

If your two input clocks are running O.K., but your data capture is
not consistent, it is possible to run standard (non-GCLK) inputs
to a DCM to adjust the clock phase.  You might need to set an
environment variable to force ISE to do this depending on the version
of ISE you run.  On my system I set:
XIL_MAP_ALLOW_ANY_DLL_INPUT = 1
But that was for a very old version of Foundation, so you may not
need this.

I'm not sure what you mean by sampling the camera data according
to these clock signals, and then sampled again using the Bus2IP
clock.  I would think you need to use a FIFO to move from the
camera clocks to the Bus2IP clock.  Camera Link places a LVAL
signal on each of the Channel-Links, so you can generate a
FIFO write signal for each link independently using its own
clock.

Hope this helps,
Gabor

On Jan 4, 1:42 am, Gabor <ga...@alacron.com> wrote:
> On Jan 3, 10:28 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
>
>
>
> > Hello,
>
> > I've some issues hooking up some external components (camera link based
> > cameras) to my XUPV2P board. I've built a PCB which connects the high
> > speed expansion port of the XUPV2P to the outputs of the National Chip
> > DS90CR288A. I've two cameras running simultaneously, so thats two chips on
> > the PCB.
>
> > On the high speed expansion port of the XUPV2P there's a clock input, but
> > because I've got two external clocks (one from each chip), I decided to
> > attach them to the 'regular' FPGA pins. Sorry if this makes no sense! The
> > other high speed expansion port connections are connected to the data
> > signals, and data-valid signals from the chips.
>
> > I've created a peripheral which samples the camera data according to these
> > clock signals, and then sampled again using the Bus2IP clock. I use a
> > microblaze processor just to output various data. On the scope, my clock
> > signals seem to have a period of 16ns, is this too fast for what I want to
> > do? The voltage swing is about 600mV. My design doesn't seem to be working!
> > Just wondered if anyone had any suggestions comments on how best to debug
> > and proceed.
>
> I would first check that the clocks are being received properly by
> the V2P.  Add a T flip-flop on each input clock and drive it to an
> I/O or LED that is easy to scope.  Check that the frequency is
> 1/2 of the input frequency and that you don't get runt pulses or
> other undesired behavior.
>
> If your two input clocks are running O.K., but your data capture is
> not consistent, it is possible to run standard (non-GCLK) inputs
> to a DCM to adjust the clock phase.  You might need to set an
> environment variable to force ISE to do this depending on the version
> of ISE you run.  On my system I set:
> XIL_MAP_ALLOW_ANY_DLL_INPUT = 1
> But that was for a very old version of Foundation, so you may not
> need this.
>
> I'm not sure what you mean by sampling the camera data according
> to these clock signals, and then sampled again using the Bus2IP
> clock.  I would think you need to use a FIFO to move from the
> camera clocks to the Bus2IP clock.  Camera Link places a LVAL
> signal on each of the Channel-Links, so you can generate a
> FIFO write signal for each link independently using its own
> clock.
>
> Hope this helps,
> Gabor

Gabor,
Which camera are you using ?
What is the source of this 16ns clock period ? (Probably from a camera
with pixel clock frequency of 60Mhz)

If it is pixel clock from a camera and the voltage swing is about
600mV, then I am afraid that the fault lies in your custom PCB.

Did you perform impedance matching for the tracks from high speed edge
connector to DS90288 Chip ?
Have you used appropriate termination resistance to differential
lines ?
What is the distance between the chip (DS90288) and edge connector ?
What is the status of power save mode pin on DS90288 Chip ?

In my experience, FVAL, LVAL and clock signals are extremely stable
signals from the output of camera. And voltage swing of clock is very
appropriate.

Try using chipscope pro to observe input signals to FPGA and perhaps
by exporting to data to a text file and using matlab try to display
resulting image.

Hope this helps.

/MH

>On Jan 4, 1:42 am, Gabor <ga...@alacron.com> wrote:
>> On Jan 3, 10:28 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
>>
>>
>>
>> > Hello,
>>
>> > I've some issues hooking up some external components (camera link
based
>> > cameras) to my XUPV2P board. I've built a PCB which connects the
high
>> > speed expansion port of the XUPV2P to the outputs of the National
Chip
>> > DS90CR288A. I've two cameras running simultaneously, so thats two
chips on
>> > the PCB.
>>
>> > On the high speed expansion port of the XUPV2P there's a clock input,
but
>> > because I've got two external clocks (one from each chip), I decided
to
>> > attach them to the 'regular' FPGA pins. Sorry if this makes no sense!
The
>> > other high speed expansion port connections are connected to the
data
>> > signals, and data-valid signals from the chips.
>>
>> > I've created a peripheral which samples the camera data according to
these
>> > clock signals, and then sampled again using the Bus2IP clock. I use
a
>> > microblaze processor just to output various data. On the scope, my
clock
>> > signals seem to have a period of 16ns, is this too fast for what I
want to
>> > do? The voltage swing is about 600mV. My design doesn't seem to be
working!
>> > Just wondered if anyone had any suggestions comments on how best to
debug
>> > and proceed.
>>

>Gabor,
>Which camera are you using ?
>What is the source of this 16ns clock period ? (Probably from a camera
>with pixel clock frequency of 60Mhz)
>
>If it is pixel clock from a camera and the voltage swing is about
>600mV, then I am afraid that the fault lies in your custom PCB.
>
>Did you perform impedance matching for the tracks from high speed edge
>connector to DS90288 Chip ?
>Have you used appropriate termination resistance to differential
>lines ?
>What is the distance between the chip (DS90288) and edge connector ?
>What is the status of power save mode pin on DS90288 Chip ?
>
>In my experience, FVAL, LVAL and clock signals are extremely stable
>signals from the output of camera. And voltage swing of clock is very
>appropriate.
>
>Try using chipscope pro to observe input signals to FPGA and perhaps
>by exporting to data to a text file and using matlab try to display
>resulting image.
>
>Hope this helps.
>
>/MH
>
>

Hi, thanks for the replies, 

I thought my PCB might be the problem. I didn't perform any impedance
matching or termination. I'm "tapping-off" the signals between the camera
and framegrabber. So i have a straight through connection - camera to
framegrabber and then "tap-off" the LVDS data-signals and clock and send
these into the DS90CR288A. This way I can setup and control the camera
using the camera software on PC, and just perform data processing on
FPGA.

I wasn't sure I needed to terminate the lines, as this would be performed
further up the line - at the framegrabber end. The pixel clock from the
camera should be 66MHz (I think), so thought I was on the right lines with
a 16ns period. The chip however is the 85Mhz version. Is this a maximum?
I'm not sure what the clock output of the chip should be - 85Mhz or
66MHz!?

I can see data on the output of the chip, LVAL and DVAL signals are
correct, not sure about the clock. As I say, the output voltage swing is
about 600mV, and looks sinusoidal in shape on the scope - Sorry for the
description! The distance between the chip and the connector is about
10mm. Do i need termination resistors across the differential lines in my
case? 

On Jan 4, 10:03 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
> >On Jan 4, 1:42 am, Gabor <ga...@alacron.com> wrote:
> >> On Jan 3, 10:28 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
>
> >> > Hello,
>
> >> > I've some issues hooking up some external components (camera link
> based
> >> > cameras) to my XUPV2P board. I've built a PCB which connects the
> high
> >> > speed expansion port of the XUPV2P to the outputs of the National
> Chip
> >> > DS90CR288A. I've two cameras running simultaneously, so thats two
> chips on
> >> > the PCB.
>
> >> > On the high speed expansion port of the XUPV2P there's a clock input,
> but
> >> > because I've got two external clocks (one from each chip), I decided
> to
> >> > attach them to the 'regular' FPGA pins. Sorry if this makes no sense!
> The
> >> > other high speed expansion port connections are connected to the
> data
> >> > signals, and data-valid signals from the chips.
>
> >> > I've created a peripheral which samples the camera data according to
> these
> >> > clock signals, and then sampled again using the Bus2IP clock. I use
> a
> >> > microblaze processor just to output various data. On the scope, my
> clock
> >> > signals seem to have a period of 16ns, is this too fast for what I
> want to
> >> > do? The voltage swing is about 600mV. My design doesn't seem to be
> working!
> >> > Just wondered if anyone had any suggestions comments on how best to
> debug
> >> > and proceed.
>
> >Gabor,
> >Which camera are you using ?
> >What is the source of this 16ns clock period ? (Probably from a camera
> >with pixel clock frequency of 60Mhz)
>
> >If it is pixel clock from a camera and the voltage swing is about
> >600mV, then I am afraid that the fault lies in your custom PCB.
>
> >Did you perform impedance matching for the tracks from high speed edge
> >connector to DS90288 Chip ?
> >Have you used appropriate termination resistance to differential
> >lines ?
> >What is the distance between the chip (DS90288) and edge connector ?
> >What is the status of power save mode pin on DS90288 Chip ?
>
> >In my experience, FVAL, LVAL and clock signals are extremely stable
> >signals from the output of camera. And voltage swing of clock is very
> >appropriate.
>
> >Try using chipscope pro to observe input signals to FPGA and perhaps
> >by exporting to data to a text file and using matlab try to display
> >resulting image.
>
> >Hope this helps.
>
> >/MH
>
> Hi, thanks for the replies,
>
> I thought my PCB might be the problem. I didn't perform any impedance
> matching or termination. I'm "tapping-off" the signals between the camera
> and framegrabber. So i have a straight through connection - camera to
> framegrabber and then "tap-off" the LVDS data-signals and clock and send
> these into the DS90CR288A. This way I can setup and control the camera
> using the camera software on PC, and just perform data processing on
> FPGA.
>

Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done
carefully
to avoid signal integrity problems at the receiver.  However if your
LVAL and DVAL signals look correct, you may have lucked out...

> I wasn't sure I needed to terminate the lines, as this would be performed
> further up the line - at the framegrabber end. The pixel clock from the
> camera should be 66MHz (I think), so thought I was on the right lines with
> a 16ns period. The chip however is the 85Mhz version. Is this a maximum?
> I'm not sure what the clock output of the chip should be - 85Mhz or
> 66MHz!?
>

Channel-Link receivers have a wide frequency range of about 20 MHz
minimum to the specified maximum (66 or 85 MHz).  66 MHz should
work fine.

> I can see data on the output of the chip, LVAL and DVAL signals are
> correct, not sure about the clock. As I say, the output voltage swing is
> about 600mV, and looks sinusoidal in shape on the scope - Sorry for the
> description! The distance between the chip and the connector is about
> 10mm. Do i need termination resistors across the differential lines in my
> case?

You may be OK with the 10mm stubs.  Definitely don't terminate them
if there is already termination at the framegrabber.  Also if you
still get a proper picture at the framegrabber, you probably
have reasonable signal integrity.  With your scope it would be
hard to look at this...

I'm going to guess that the clock is correct, too, but that your
scope is bandwidth limiting the signal to form the sine wave you
see.  What is the input bandwidth of your scope and probe?  Did
you try to implement a simple T flip-flop in the FPGA to see if
the clock is getting into the chip OK?

Regards,
Gabor

>>
>> Hi, thanks for the replies,
>>
>> I thought my PCB might be the problem. I didn't perform any impedance
>> matching or termination. I'm "tapping-off" the signals between the
camera
>> and framegrabber. So i have a straight through connection - camera to
>> framegrabber and then "tap-off" the LVDS data-signals and clock and
send
>> these into the DS90CR288A. This way I can setup and control the camera
>> using the camera software on PC, and just perform data processing on
>> FPGA.
>>
>
>Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done
>carefully
>to avoid signal integrity problems at the receiver.  However if your
>LVAL and DVAL signals look correct, you may have lucked out...
>
>> I wasn't sure I needed to terminate the lines, as this would be
performed
>> further up the line - at the framegrabber end. The pixel clock from
the
>> camera should be 66MHz (I think), so thought I was on the right lines
with
>> a 16ns period. The chip however is the 85Mhz version. Is this a
maximum?
>> I'm not sure what the clock output of the chip should be - 85Mhz or
>> 66MHz!?
>>
>
>Channel-Link receivers have a wide frequency range of about 20 MHz
>minimum to the specified maximum (66 or 85 MHz).  66 MHz should
>work fine.
>
>> I can see data on the output of the chip, LVAL and DVAL signals are
>> correct, not sure about the clock. As I say, the output voltage swing
is
>> about 600mV, and looks sinusoidal in shape on the scope - Sorry for
the
>> description! The distance between the chip and the connector is about
>> 10mm. Do i need termination resistors across the differential lines in
my
>> case?
>
>You may be OK with the 10mm stubs.  Definitely don't terminate them
>if there is already termination at the framegrabber.  Also if you
>still get a proper picture at the framegrabber, you probably
>have reasonable signal integrity.  With your scope it would be
>hard to look at this...
>
>I'm going to guess that the clock is correct, too, but that your
>scope is bandwidth limiting the signal to form the sine wave you
>see.  What is the input bandwidth of your scope and probe?  Did
>you try to implement a simple T flip-flop in the FPGA to see if
>the clock is getting into the chip OK?
>
>Regards,
>Gabor
>

Thanks again Gabor..

The system does seem to be working ok. I get the correct image at the
frame-grabber end, and all the signals do seem to be correct. The scope
I'm using says 60MHz on it, I guess this the bandwidth - in which I guess
it will struggle to observe the higher frequency signals??

I implemented a T-flip flop, and got a decent signal at half the input
frequncy across an LED on the board, so it looks like everything is ok -
probably just my VHDL letting me down! The LVAL, DVAL signals are working
as expected aswell - used the LEDs to observe these. 

Just as an aside - when I increase the precision of the camera's output 8
bit to 16 bit, the camera sends the data in two "packets". For one LVAL
pulse, the are two DVAL pulses. I think this maybe camera specific, but I
think the data may be being sent low bits (0-7) with the first DVAL pulse,
followed by high bits with the second. My camera is always is in
camera-link BASE mode. I've scoped all the data channels from the chip,
and the higher outputs are not used - apart from RxOut 27. Am I right
thinking that in base mode the data should be re-created as:

Bit(0) - RxOut 0
Bit(1) - RxOut 1
Bit(2) - RxOut 2
Bit(3) - RxOut 3
Bit(4) - RxOut 4
Bit(5) - RxOut 6
Bit(6) - RxOut 27
Bit(7) - RxOut 5

Just wondered if anyone else had any experience with 16 bit data in base
mode?

Regards

Marc.

On Jan 7, 5:50 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
> >> Hi, thanks for the replies,
>
> >> I thought my PCB might be the problem. I didn't perform any impedance
> >> matching or termination. I'm "tapping-off" the signals between the
> camera
> >> and framegrabber. So i have a straight through connection - camera to
> >> framegrabber and then "tap-off" the LVDS data-signals and clock and
> send
> >> these into the DS90CR288A. This way I can setup and control the camera
> >> using the camera software on PC, and just perform data processing on
> >> FPGA.
>
> >Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done
> >carefully
> >to avoid signal integrity problems at the receiver.  However if your
> >LVAL and DVAL signals look correct, you may have lucked out...
>
> >> I wasn't sure I needed to terminate the lines, as this would be
> performed
> >> further up the line - at the framegrabber end. The pixel clock from
> the
> >> camera should be 66MHz (I think), so thought I was on the right lines
> with
> >> a 16ns period. The chip however is the 85Mhz version. Is this a
> maximum?
> >> I'm not sure what the clock output of the chip should be - 85Mhz or
> >> 66MHz!?
>
> >Channel-Link receivers have a wide frequency range of about 20 MHz
> >minimum to the specified maximum (66 or 85 MHz).  66 MHz should
> >work fine.
>
> >> I can see data on the output of the chip, LVAL and DVAL signals are
> >> correct, not sure about the clock. As I say, the output voltage swing
> is
> >> about 600mV, and looks sinusoidal in shape on the scope - Sorry for
> the
> >> description! The distance between the chip and the connector is about
> >> 10mm. Do i need termination resistors across the differential lines in
> my
> >> case?
>
> >You may be OK with the 10mm stubs.  Definitely don't terminate them
> >if there is already termination at the framegrabber.  Also if you
> >still get a proper picture at the framegrabber, you probably
> >have reasonable signal integrity.  With your scope it would be
> >hard to look at this...
>
> >I'm going to guess that the clock is correct, too, but that your
> >scope is bandwidth limiting the signal to form the sine wave you
> >see.  What is the input bandwidth of your scope and probe?  Did
> >you try to implement a simple T flip-flop in the FPGA to see if
> >the clock is getting into the chip OK?
>
> >Regards,
> >Gabor
>
> Thanks again Gabor..
>
> The system does seem to be working ok. I get the correct image at the
> frame-grabber end, and all the signals do seem to be correct. The scope
> I'm using says 60MHz on it, I guess this the bandwidth - in which I guess
> it will struggle to observe the higher frequency signals??
>
> I implemented a T-flip flop, and got a decent signal at half the input
> frequncy across an LED on the board, so it looks like everything is ok -
> probably just my VHDL letting me down! The LVAL, DVAL signals are working
> as expected aswell - used the LEDs to observe these.
>
> Just as an aside - when I increase the precision of the camera's output 8
> bit to 16 bit, the camera sends the data in two "packets". For one LVAL
> pulse, the are two DVAL pulses. I think this maybe camera specific, but I
> think the data may be being sent low bits (0-7) with the first DVAL pulse,
> followed by high bits with the second. My camera is always is in
> camera-link BASE mode. I've scoped all the data channels from the chip,
> and the higher outputs are not used - apart from RxOut 27. Am I right
> thinking that in base mode the data should be re-created as:
>
> Bit(0) - RxOut 0
> Bit(1) - RxOut 1
> Bit(2) - RxOut 2
> Bit(3) - RxOut 3
> Bit(4) - RxOut 4
> Bit(5) - RxOut 6
> Bit(6) - RxOut 27
> Bit(7) - RxOut 5
>
> Just wondered if anyone else had any experience with 16 bit data in base
> mode?
>
> Regards
>
> Marc.

The bit assignments are all in the Camera Link Specification:

http://www.alacron.com/downloads/vncl98076xz/CameraLinkSPEC.pdf

Most Camera Link cameras use two 8-bit "ports" A & B to output
16-bits on each clock.  I'm not familiar with any cameras that
use DVAL as a pixel framing signal.  Base Camera Link supports
up to 24 bits of data per clock.

Regards,
Gabor

On Jan 8, 2:22 am, Gabor <ga...@alacron.com> wrote:
> On Jan 7, 5:50 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
>
>
>
> > >> Hi, thanks for the replies,
>
> > >> I thought my PCB might be the problem. I didn't perform any impedance
> > >> matching or termination. I'm "tapping-off" the signals between the
> > camera
> > >> and framegrabber. So i have a straight through connection - camera to
> > >> framegrabber and then "tap-off" the LVDS data-signals and clock and
> > send
> > >> these into the DS90CR288A. This way I can setup and control the camera
> > >> using the camera software on PC, and just perform data processing on
> > >> FPGA.
>
> > >Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done
> > >carefully
> > >to avoid signal integrity problems at the receiver.  However if your
> > >LVAL and DVAL signals look correct, you may have lucked out...
>
> > >> I wasn't sure I needed to terminate the lines, as this would be
> > performed
> > >> further up the line - at the framegrabber end. The pixel clock from
> > the
> > >> camera should be 66MHz (I think), so thought I was on the right lines
> > with
> > >> a 16ns period. The chip however is the 85Mhz version. Is this a
> > maximum?
> > >> I'm not sure what the clock output of the chip should be - 85Mhz or
> > >> 66MHz!?
>
> > >Channel-Link receivers have a wide frequency range of about 20 MHz
> > >minimum to the specified maximum (66 or 85 MHz).  66 MHz should
> > >work fine.
>
> > >> I can see data on the output of the chip, LVAL and DVAL signals are
> > >> correct, not sure about the clock. As I say, the output voltage swing
> > is
> > >> about 600mV, and looks sinusoidal in shape on the scope - Sorry for
> > the
> > >> description! The distance between the chip and the connector is about
> > >> 10mm. Do i need termination resistors across the differential lines in
> > my
> > >> case?
>
> > >You may be OK with the 10mm stubs.  Definitely don't terminate them
> > >if there is already termination at the framegrabber.  Also if you
> > >still get a proper picture at the framegrabber, you probably
> > >have reasonable signal integrity.  With your scope it would be
> > >hard to look at this...
>
> > >I'm going to guess that the clock is correct, too, but that your
> > >scope is bandwidth limiting the signal to form the sine wave you
> > >see.  What is the input bandwidth of your scope and probe?  Did
> > >you try to implement a simple T flip-flop in the FPGA to see if
> > >the clock is getting into the chip OK?
>
> > >Regards,
> > >Gabor
>
> > Thanks again Gabor..
>
> > The system does seem to be working ok. I get the correct image at the
> > frame-grabber end, and all the signals do seem to be correct. The scope
> > I'm using says 60MHz on it, I guess this the bandwidth - in which I guess
> > it will struggle to observe the higher frequency signals??
>
> > I implemented a T-flip flop, and got a decent signal at half the input
> > frequncy across an LED on the board, so it looks like everything is ok -
> > probably just my VHDL letting me down! The LVAL, DVAL signals are working
> > as expected aswell - used the LEDs to observe these.
>
> > Just as an aside - when I increase the precision of the camera's output 8
> > bit to 16 bit, the camera sends the data in two "packets". For one LVAL
> > pulse, the are two DVAL pulses. I think this maybe camera specific, but I
> > think the data may be being sent low bits (0-7) with the first DVAL pulse,
> > followed by high bits with the second. My camera is always is in
> > camera-link BASE mode. I've scoped all the data channels from the chip,
> > and the higher outputs are not used - apart from RxOut 27. Am I right
> > thinking that in base mode the data should be re-created as:
>
> > Bit(0) - RxOut 0
> > Bit(1) - RxOut 1
> > Bit(2) - RxOut 2
> > Bit(3) - RxOut 3
> > Bit(4) - RxOut 4
> > Bit(5) - RxOut 6
> > Bit(6) - RxOut 27
> > Bit(7) - RxOut 5
>
> > Just wondered if anyone else had any experience with 16 bit data in base
> > mode?
>
> > Regards
>
> > Marc.
>
> The bit assignments are all in the Camera Link Specification:
>
> http://www.alacron.com/downloads/vncl98076xz/CameraLinkSPEC.pdf
>
> Most Camera Link cameras use two 8-bit "ports" A & B to output
> 16-bits on each clock.  I'm not familiar with any cameras that
> use DVAL as a pixel framing signal.  Base Camera Link supports
> up to 24 bits of data per clock.
>
> Regards,
> Gabor


Hi,

Gabor is right, As an addendum to his comment, I think that some
cameras from "Basler" use DVAL as pixel framing signal. It is used
when the user want to output some selected region from CCD of camera.
If you are getting two pulses of DVAL, check your camera whether it is
operating in single or dual tap mode and what is the region of
interest in camera setting.

Hope this helps,

/MH

>Hi,
>
>Gabor is right, As an addendum to his comment, I think that some
>cameras from "Basler" use DVAL as pixel framing signal. It is used
>when the user want to output some selected region from CCD of camera.
>If you are getting two pulses of DVAL, check your camera whether it is
>operating in single or dual tap mode and what is the region of
>interest in camera setting.
>
>Hope this helps,
>
>/MH
>

Thanks, 

My camera operates in 2-taps interleaved mode. It operates as a line scan
camera, a single row value for each column of the sensor array is
calculated and read out. Therefore I don't think the ROI will come into
it, but I'm not sure what the taps refer to or their definition, and
haven't had any luck in finding out...?

On Jan 8, 8:03 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
> >Hi,
>
> >Gabor is right, As an addendum to his comment, I think that some
> >cameras from "Basler" use DVAL as pixel framing signal. It is used
> >when the user want to output some selected region from CCD of camera.
> >If you are getting two pulses of DVAL, check your camera whether it is
> >operating in single or dual tap mode and what is the region of
> >interest in camera setting.
>
> >Hope this helps,
>
> >/MH
>
> Thanks,
>
> My camera operates in 2-taps interleaved mode. It operates as a line scan
> camera, a single row value for each column of the sensor array is
> calculated and read out. Therefore I don't think the ROI will come into
> it, but I'm not sure what the taps refer to or their definition, and
> haven't had any luck in finding out...?

The term "taps" come from the CCD world, where video comes out as
a serial analog stream from the sensor.  In larger sensors, the
array was read out with more than one analog shift register or CCD
where a CCD might read out a quadrant or half of the sensor array.
Each of these output streams is called a "tap" and would be digitized
independently to provide the necessary readout bandwidth.

In some older cameras, the framegrabber would need to re-assemble
the multiple taps into an image, possibly getting data in a different
order for each tap.  One example of this is a four quadrant CCD read
out at the four corners of the array.  When shifting out the data,
you would get the four corner pixels first and scan through in
raster fashion toward the final central pixels.  In this case you
have all combinations of left-to-right, right-to-left, top-to-bottom,
and bottom-to-top scanning.  Modern cameras might use similar CCD
devices, but generally re-order the data within the camera electronics
so the output looks like a simple raster.

Interleaved tap order usually refers to odd / even pixels coming
out of two taps of the camera.  In this case each tap services
every other pixel of the entire image, so the resultant image
is formed by merging (interleaving) the two taps to form a
single raster.

For Camera Link, the number of "taps" usually refers to the number
of digitized pixels sent on each Camera Link pixel clock, regardless
of the organization of the sensor.  The same camera may operate
in 1, 2, or 4 tap modes for example using Medium camera link and
8, 16, or 32 bits per clock.

You may find more information in the technical manual of your camera.
These are usually available from the vendor's website and have more
detailed information that the user manual that ships with the camera.

HTH,
Gabor