|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.apo.nmsu.edu/35m_operations/agile/TimerCard.html
Дата изменения: Sat Dec 10 00:58:20 2011 Дата индексирования: Sat Apr 9 23:20:40 2016 Кодировка: Поисковые слова: п п п п р п р п р п р п р п р п р п р п |
The Agile ICC computer (nimble) contains a high-accuracy GPS-synchronized timer card that emits pulses that trigger readout of the Agile camera when run in external synch mode.
The card is a PCI-SyncClock32 with the DIVGATE option and BCD time. The recommended configuration for Agile has no GPS receiver (see 1 PPS Vs. The Built-In GPS Receiver below). We bought the card from Brandywine Communications. Technical support has been from John Kates of jxi2, so I assume jxi2 makes the card.
The DIVGATE option is necessary to start a pulse sequence at a known time. This allows the heartbeat counter (and other outputs driven by the dividers 0-2) to be synched to the integer second.
Without the DIVGATE option, starting a pulse sequence involves sending a "rejam" to configure the new pulse rate. Rejam resets the whole timer card, so it temporarily loses track of time and the new pulse sequence will not start at a predictable time. You can also get spurious extra pulses.
The heartbeat output of the timer card is connected to the external synch input of the Agile camera. Pulses are output using heartbeat mode, in which the timer card outputs pulses at a fixed rate indefinitely (until the heartbeat is turned off or the rate is changed). The heartbeat pulse mode is DP_ctl_mode2: the output is normally high, but goes low for each pulse for one clock cycle, which is 10 milliseconds. This is crucial because if the output is still low when the Agile camera has finished reading the exposure, it will read another exposure (despite the fact that the Agile sync pulse is advertised as being edge triggered; don't you just love Princeton Instruments?).
The timer card is configured for slow heartbeat: clock ticks are 10 milliseconds long. This offers a nice balance of long maximum exposure time and good resolution. The alternative is fast heartbeat: 0.333... microsecond clock ticks, which would give a maximum exposure time that is too short to be useful.
An alternative design is to schedule each pulse individually. The advantage is you don't have to reconfigure the card at all (so the DIVGATE option is not required) and you don't have to guess when the pulse train starts, since each tick comes exactly when you command it. However, it is intrinsically a bit fragile because it requires the software to reliably configure each pulse; if your code is late for some reason then you will miss an exposure.
We have had some trouble with the card failing to start a new pulse sequence correctly. The card cannot see heartbeat pulses at all, but the camera seems to see a fast stream of pulses and so the exposure sequence fails right away. It was a very intermittent problem so I put in some print statements to document exactly what calls we were making to the timer card drivers (to have something concrete to send to tech support), but when I added those print statements the problem went away. So it is most likely a timing issue, e.g. not waiting long enough between two operations.
If the problem does occur, use the program setheartbeat (an example in my syncclock package) followed by stopheartbeat to start and stop a timing sequence. That always seems to get the card running again. Simply commanding another exposure does not, unfortunately, fix the problem.
We bought a card that has an on-board GPS receiver (so that Agile could be run standalone, e.g. as a visiting instrument at other observatories), with the understanding that we could choose to either use GPS or synchronize the card with an external 1 PPS pulse or IRIG. Unfortunately that turned out to be false.
As it turns out, the built-in GPS receiver drives the 1 PPS line. Thus you must not feed 1 PPS in as long as the built-in GPS receiver is connected. To disconnect the built-in GPS receiver, do either of:
Notes:
Unlike 1 PPS, IRIG-B (and other encoded time) *can* be used with the onboard GPS receiver. If no GPS satellites are seen then the IRIG-B will be used. I don't know what happens if both are coming in at the same time.
Our card came with an EPROM labelled:
7130A OCD9
We were sent a special EPROM that allows the 1 PPS to work (if the GPS clock is removed). It is labelled:
6812A 79B9
We then ordered a special -DIVGATE modification (see Rejam oddities above) and were sent two more EPROMS:
GPS with -DIVGATE option:
7130A E343
No GPS (allows 1 PPS input) with -DIVGATE option:
6812A 8114
EPROMs must be installed such that the text is "right side up" when the card has the connectors at the top:
BNC BNC high-density D26 ------------------------ | | | | | EPROM | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------
We bought a card that encodes time as binary-coded decimal (BCD). This turned out to be a bit of a problem because the registers only have room to store two digits for the year. (It is also annoying because it is more work to decode the time.)
Because the timer card cannot keep all 4 digits of the year, I do not even bother to set time on the the timer card at all. I rely on it only to get the correct fraction of a second (and to output a steady rate of pulses); I get the rest of the time information from the computer's own clock (which is synchronized to NTP).
If I was starting over I would buy the version that encodes time as binary instead of BCD. The binary version has room for all 4 digits of the year. One could then set the timer card and read time directly from it (if desired). Or better yet, synch it to IRIG-B and don't worry about setting it.