Gentlemen,
Attached is the updated VSI-H specified, upgraded from 'draft' to
'proposed' (that's a step in the right direction!). I want to thank
everyone who participated in yesterday's telecon. I *believe* that we
came to agreement on all open issues. Below I have summarized the action
taken on each of the agenda items, which are now hopefully reflected in the
updated spec.
Please respond to me within the next week with any problems or
errors you may find in the attached version so that I may correct them and we
can arrive at the final version soon. I will then distribute the 'final'
version for approval and ask the members of the format VSI committee to send me
an e-mail with approval so that (hopefully) we may declare the VSI-H project finished
and move on to VSI-S.
The membership of the formal VSI committee is:
Wayne Cannon, Crestech
Brent Carlson, DRAO
Dick Ferris, CSIRO
Dave Graham, MPIfr
Nori Kawaguchi, NAO
Tetsuro Kondo, CRL
Sergei Pogrebenko, JIVE
Misha Popov, ASC
Jon Romney, NRAO
Ralph Spencer, Jodrell
Alan Whitney, Haystack
-
Attendees at 10 May 2000 2200UT telecon:
Wayne Cannon, George Feil, Sasha Novikov, Paul Newby, Crestech
Dick Ferris, CSIRO
Tetsuro Kondo, Junichi Nakajima, Hitoshi Kiuchi, Yashuhiro Koyama, Mamoru
Sekido, CRL
Nori Kawaguchi, NRO
Jon Romney, George Peck, NRAO
Sergei Pogrebenko, JIVE
Will Aldrich, Alan Whitney, Haystack
-
The following issues were discussed and decided:
1. LVDS Connector Pinout
Issue: Dick Ferris has suggested a pinout different from the 9 Feb
draft document. This new suggested pinout is based on the use of a specific
LVDS device. The Japanese group have already begun implementation of the 9 Feb
pinout.
Discussion: Although Dick's is more optimal for a specific LVDS
interface device, the 9 Feb pinout has been chosen to be generically 'good' in
a general engineering sense, is likely to be workable, and does not constrain
the use of future LVDS interface devices. The fact that the Japanese group has
already partially or fully implemented the 9 Feb pinout makes a change painful.
04 May Draft: I have been won over by Dick's arguments in his 3 May
e-mail. Though I know this may not please everyone, I think the long term
benefits are clear. Please read Dick's e-mail carefully.
Telecon Discussion: Kawaguchi-san suggested adding signal to MDR-14
connector with IRIG-B timing code. After much discussion, it was clear
that a strong majority favored the existing draft specification which suggests
PDATA for the use of a 'hardware' timing code to the DIM. The primary
reason is that PDATA is defined as a standard serial ASCII data stream which is
very flexible and can be used for other purposes as well.
Decision: No change
-
2. Bi-directional LVDS Signals
Issue: In his notes of 3 Mar 00, Dick Ferris has suggested the use
of reverse-channel functions. The 9 Feb draft specifies only unidirectional
signals on LVDS cables.
Discussion: The possible use of bi-directional signals on the LVDS
cables was a *major* discussion item at the Haystack meeting in late January.
In the end we agreed that the signals on each LVDS cable would be
uni-directional. That is *the* reason that DPS1PPS and DPSCLOCK are on a
separate cable to the DOM. Despite the fact that reverse-channel signals do
provide some possible advantages, I think we must stick to the January
agreement for the base VSI specification. As Rick points out in his note below,
a reverse-channel capability could still be built into the DIM/DOM using
bi-directional driver/receiver chips, but that they must be configurable to meet
the uni-directional VSI-H specification.
04 May Draft: I apologize that I did not fully understand Dick's
proposal to make bi-directional signals entirely optional in a manner that does
not in any way violate the uni-directional decision of the January meeting. I
have since studied his proposal much more careful, believe that it is good, and
have basically incorporated it. Please read this part of the draft very
carefully.
Telecon Discussion: No disagreement
Decision: No change
-
3. Delay in DOM/DIM
Issue: A delay option in the DOM was suggested in the 9 Feb draft
after some discussion at the January meeting. It was probably my fault that it
was vaguely defined, which left the issue rather unclear. Since then, there
have been various opinions expressed regarding its implementation, and Rick
suggests adding a 'delay' option to the DIM, as well.
Discussion: Adding a fixed delay capability is clearly useful to help in
the case of limited size of correlator input buffers. Anything fancier, such as
delay tracking, has very correlator-specific requirements that are very
difficult to accomodate.
04 May Draft: For *storage-based* DPS systems (i.e. tape, disc, any
transportable media), the required delay range is +/-0.5*ROT1PPS. Dick points
out, correctly, that for *direct-transmission* systems, the required delay is
highly dependent on antenna-location geometry and could place undo requirements
on a DTS system; I feel that, in this case, that VSI-H mandate no delay-offset
requirements and assume that the DPS will implement whatever is necessary.
Telecon Discussion: After short discussion, agreement.
Decision: No change
-
4. Bit-stream selection and re-ordering
Issue: We have agreed that any 2**n input bit-streams at the input
to the DIM can be selected for transmision to the DOM. In addition, we have
agreed that arbitrary bit-stream re-ordering at the DOM output is necessary.
Dick Ferris has also suggested re-ordering in the DIM.
Discussion: The benefit of re-ordering in the DIM is not clear to me.
Arbitrary bit-stream re-ordering at the DOM output is sufficient to cover all
bases. The 9 Feb draft comments that DOM-output re-ordering can be effectively
achieved in a separate box between the DOM and DPS. Dick Ferris comments that a
separate box makes it difficult to define a standard software protocol.
04 May Draft: I feel the only real requirement is that any active DIM
input can be mapped to any DOM output. And that is it. How that is implemented
is up to the designer. Re-ordering at the DIM might add some features and
conveniences, but I don't think it belongs in the specification; I did add a
footnote in Section 13.4 in this regard.
Telecon Discussion: Dick Ferris noted that it would be advantageous to
do signal switching at the DIM so that default ordering at DOM output matches
DPS expectations. Alan Whitney suggested that putting switching in both
DIM and DOM presented opportunities for more mistakes and confusion. In
any case
Decision: Add footnote to Section 9.1 indicating that signal switching
in DIM may have some advantages, but is optional.
-
5. LVDS Cable Specs
Issue: The detailed specification of cable is very complicated.
Discussion: Dick has done a very admirable job of creating a suggested
cable spec, but the Japanese point out the difficulties of making objective
measurements of some parameters.
04 May Draft: I have lifted the basic cable specifications from one of
Dick's memo's and made some general remarks. There may still be a bit of work
to do here if people feel it is incomplete, misleading or inaccurate.
Telecon Discussion: General agreement
Decision: No change
-
6. LVDS Electrical Specs
Recommendation: Adopt the detailed specification given by Dick. This
is more detailed and complete than the 9 Feb draft.
04 May Draft: Done
Telecon Discussion: None
Decision: No change
-
7. Validity per bit stream
Issue: The 9 Feb draft proposed a extension using bi-phase code for
validity per bit stream. Dick Ferris points out that this introduces many
complications.
04 May Draft: The whole validity-per-bit-stream issue has been relegated
to 'Other Notes and Comments' so that we don't forget about it, but there is
nothing in the spec about it.
Telecon discussion: Jon Romney was note entirely happy that this issue
was relegated to a miscellaneous item in the spec, but said he understands.
Decision: No change
-
8. Serial control port spec
Issue: The 9 Feb draft proposed is not fully internally consistent in the
specification standards.
Discussion: Dick makes the point that RS-223 is probably not the proper
spec. Count me guilty in that regard. At the January meeting we had agreed to
use RJ-45 type connectors with the pin-out specified in Table 12 with only
XON/XOFF handshaking specified. Dick points out that the specified pinout does
not follow the relevant EIA-561 standard, and that the specified pinout is bad
in terms of crosstalk when using standard CAT-5 cables. The problem is that
none of the major manufacturers (Cisco, Lantronix at least) use the EIA-561
spec. They use the Table 12 pinout in spite of the problems mentioned by Dick;
the advantage of this pinout is that its trivial to create either a
straight-through or null modem cable by simply flipping over the RJ-45
connector on one end. Dick also suggests allowing DB-9 and DB-25 connectors as
well, plus RTS/CTS flow control.
04 May Draft: Consensus seems to be to adopt DB-9 rather than RJ-45.
This both eliminates any possible confusion between the RS-232 and Ethernet
connectors and puts the pin-out issue to rest (I trust!).
Telecon Discussion: George Feil suggested that RS-232 software
handshaking should be part of VSI-S, not VSI-H.
Decision: Remove Xon/Xoff handshaking specification; specify only
software handshaking (details to be in VSI-S)
-
9. Proposal for P/QDATA format
Recommendation: Leave this issue for VSI-S spec
04 May Draft: Done
Telecon Discussion: None
Decision: No change
-
10. TVG
Issue: The example TVG circuit diagram may not exactly reflect TVG
intentions and may cause confusion.
Discussions: The TVG timing relationships are specified in Figure 4. If
Figure 4 is used a guide along with the TVG diagram and the listing of the
first few bits of each TVG output, I hope that things will be sufficiently
clear.
04 May Draft: I have tried to clarify this area.
Telecon Discussion: Kashima group asked Crestech if they might be able
to provide designs for TV-related circuits. Wayne Cannon agreed to act on
this request.
Decision: No impact on spec, but additional checking of spec accuracy
needs to be done.
-
11. Test Vector Receiver
Issue: Whether TVR should be able to 'untangle bit-stream mix-ups'
Discussion: Dick points out that untangling bit-stream mix-ups has no
role in ordinary testing of interfaces since there is no mechanism for
bit-stream mix-ups to occur, and that a significant piece of hardware would be
necessary (in particular, a 32*32 correlator) to fully meet this requirement.
If there is a mix-up, it can be easily untangled by examining the first few
bits of each sequence and comparing against Table 13.
04 May Draft: No requirement, but a footnote to the effect that this
capability might be nice.
Telecon Discussion: Agreement
Decision: No change
-
12. LVDS Receiver
Issue: Dick Ferris suggests that a receiver with no input should
fail-safe to logic '1'. Other suggest that the fail-safe state should simply be
a stable '0' or '1', with no preference.
04 May Draft: Fail-safe to logic '1', which is actually part of the
TIA/EIA-644 standard, as Dick points out.
Telecon Discussion: Agreement
Decision: No change
-
13. TTL Monitor Ports
Issue: The 9Feb draft specified TTL monitor ports should be designed
to drive into 50-ohm load. Dick Ferris suggests that, if the ports are only for
occasional scope monitoring, that a better way is to use a 50-ohm 'back
termination' by placing a series 50-ohm resistor on the TTL driver.
04 May Draft: 50-ohm back termination. We can argue about this if you
want.
Telecon Discussion: Agreement
Decision: No change
-
14. New Item: Connector Lockdowns
Decision: Specify 4-40 lockdown screws on MDR-80 connector and
spring latch on MDR-14 connector.
-
15. New Item: ROT1PPS
Issue: George Feil suggested that the ROT1PPS signal from the DOM
may not be necessary and might simplify DOM design. Alan Whitney
indicated that some earth-centered correlators need a signal such as ROT1PPS or
else must reconstruct it internally. After short discussion, agreement
was reached to keep ROT1PPS.
Decision: No change
-
16. Forgotten Item: QDATA Framing (not discussed)
Issue: I apologize for neglecting to mention this issue during the
telecon. As indicated in Section 14.2, QDATA can be quite useful to
transmit model data. In an earth-centered correlator, which are the
majority these days, this means (for some correlators, at least) that QDATA
should be framed by ROT1PPS instead of 1PPS. I suggest that that the DOM be
able to frame QDATA either with 1PPS or ROT1PPS to accomodate that need.
Hopefully this is a minor issue that will not cause disagreement. I have
added this requirement to the proposed spec at the suggestion of Dick
Ferris. Let me know if you disagree.
Action: I have added this to the spec in Section 10.4
-
I invite (ask) everyone to read the attached spec carefully and respond with
any concerns or problems. I would like to create a final version at the
end of next week for approval by the VSI committee.
-
Thanks again to everyone for their participation and hard work on the VSI-H
specification.
-
Regards and thanks, Alan