GHilton@southampton.oilfield.slb.com (Graeme Hilton) wrote:
>
> It goes something like this:
> 0us Trigger
> 0us pulse of light (200ns long) down fibre
> 58uS reflection from end of fibre starts (detected at input end)
> 59uS reflection from end of fibre ends
> 100us Trigger, ad infinitum
>
> In VEE I cannot tell the scope to begin re-acquiring until I have
> downloaded the data, i.e. I have 40us between end of capture and needing to
> issue the "DIG" command to get the scope armed for the next trigger.
Fundamentally you are trying to solve a real-world hardware problem
with software. That's generally a losing battle.
With timings like that you should be using real-world trigger signals
and not relying on any external software. Arm the scope with
a TTL (or whatver is needed) signal, not software. No software
running on a general purpose OS connecting to your scope via HPIB
is going to give you the determinancy that you need, but it should
be trivial in the real world.
Once your sequence is finished and data is stored on the scope
then of course VEE would be of great use in transfering and analyzing
your data.
I run into the issue whenever I teach VEE to hardware designers.
There;s always someone who wants to trigger real-world events via
VEE. It is very tempting to want to do so, of course, given "trigger"
inputs in the drivers and the like, just like it is very tempting
to want to take the "output" from a source ( say a sig gen) and
connect it to the "input" of a receiver (say a scope).
But remember that everything in VEE is software sitting inside an OS
connected to an instrument via HPIB or the like, and represents
data as measured from the real world by that instrument. Real-world
signals do not exist in the software, but off in a piece of coax.
Same goes for the trigger signals. Latency of OS, software, GPIB,
instrument firmware, etc. simply do not allow anything approaching
real-time triggering.
You might stand a chance with a real-time OS and a connection
to the box with low latency and high bandwidth ( not ethernet for instance
since it doesn;t have low latency), but again- you'd be much better off
using real-world solution for the timing then software later for
the analysis phase.
Stan
--------------------------------------------------------------------------
Stan Bischof Agilent Technologies 707-577-3994 stan_bischof@agilent.com
--------------------------------------------------------------------------
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
>
> It goes something like this:
> 0us Trigger
> 0us pulse of light (200ns long) down fibre
> 58uS reflection from end of fibre starts (detected at input end)
> 59uS reflection from end of fibre ends
> 100us Trigger, ad infinitum
>
> In VEE I cannot tell the scope to begin re-acquiring until I have
> downloaded the data, i.e. I have 40us between end of capture and needing to
> issue the "DIG" command to get the scope armed for the next trigger.
Fundamentally you are trying to solve a real-world hardware problem
with software. That's generally a losing battle.
With timings like that you should be using real-world trigger signals
and not relying on any external software. Arm the scope with
a TTL (or whatver is needed) signal, not software. No software
running on a general purpose OS connecting to your scope via HPIB
is going to give you the determinancy that you need, but it should
be trivial in the real world.
Once your sequence is finished and data is stored on the scope
then of course VEE would be of great use in transfering and analyzing
your data.
I run into the issue whenever I teach VEE to hardware designers.
There;s always someone who wants to trigger real-world events via
VEE. It is very tempting to want to do so, of course, given "trigger"
inputs in the drivers and the like, just like it is very tempting
to want to take the "output" from a source ( say a sig gen) and
connect it to the "input" of a receiver (say a scope).
But remember that everything in VEE is software sitting inside an OS
connected to an instrument via HPIB or the like, and represents
data as measured from the real world by that instrument. Real-world
signals do not exist in the software, but off in a piece of coax.
Same goes for the trigger signals. Latency of OS, software, GPIB,
instrument firmware, etc. simply do not allow anything approaching
real-time triggering.
You might stand a chance with a real-time OS and a connection
to the box with low latency and high bandwidth ( not ethernet for instance
since it doesn;t have low latency), but again- you'd be much better off
using real-world solution for the timing then software later for
the analysis phase.
Stan
--------------------------------------------------------------------------
Stan Bischof Agilent Technologies 707-577-3994 stan_bischof@agilent.com
--------------------------------------------------------------------------
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
> A faster download could be effected by using the BYTE format
> for transfer, but VEE doesn't seem able to handle the 8-bit
> signed integers. Any ideas on that one?
Do you need to process this real time, or just record and process
later? A byte is a byte, no matter if it's signed, unsigned or char.
Just get the data as a UINT8 array and convert this later. Something
like: bitAnd(x,127)-bitAnd(x,128)*1 may work. (The *1 kicks the UINT8
into a signed variable.)
But still, 40us?
Les Hammer
Partner
Complete Test
720 SW 14th St.
Loveland, CO. 80537
Les.Hammer@CompleteTest.com
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Send your favorite VEE example to "VRF-EXAMPLES@agilent.com" for possible inclusion in VEE 7.0!