Return-Path: Received: from cernmxlb.cern.ch (cernmx06.cern.ch [137.138.166.160]) by beam.beamnet (8.13.6/8.13.4) with ESMTP id k5FFmJ6x020030 for ; Thu, 15 Jun 2006 16:48:19 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=cern.ch; q=dns; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding; b=g+aNpjjYBOt6XGe+8YsA19xXF6RoFIlb+YeDAj7Po6PkhpV1S0JUJzKxf1uKBY096cU1qPvbEHpC/sjHXjVnUJSYgm4OFT9bFvrk+CbsK3UdlUWM+n39WHfVZaxGFTUC; Keywords: CERN SpamKiller Note: -51 Charset: west-latin X-Filter: CERNMX06 CERN MX v2.0 051012.1312 Release Received: from cernfe03.cern.ch ([137.138.28.244]) by cernmxlb.cern.ch with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 17:48:17 +0200 Received: from [137.138.172.100] ([137.138.172.100]) by cernfe03.cern.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 17:48:17 +0200 Message-ID: <44918141.7010705@cern.ch> Date: Thu, 15 Jun 2006 17:48:17 +0200 From: Jeroen Belleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Red Hat/1.7.12-1.1.3.2.SL3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Terry Barnaby CC: Uli Raich Subject: Re: Technical Specification for a new trajectory measurement system for the CERN Proton Synchrotron References: <44912136.8020204@beam.ltd.uk> In-Reply-To: <44912136.8020204@beam.ltd.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 15:48:17.0681 (UTC) FILETIME=[1EBB2010:01C69093] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on beam.beamnet X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.4 Status: RO X-UID: 1141409 Content-Length: 6775 X-Keywords: NonJunk Terry Barnaby wrote: > > I have looked through the Tender documents, including the Technical > specification, and I have a few initial questions. Would it be possible > for you or someone else to answer them ? Hi Terry, Excuse me for the delay, but I've been away on business for a few days. Let's go though the questions: > > 1. The system will be controlled and data accessed via a TCP/IP based > protocol. Has this protocol been designed or would it be > our responsibility to design the protocol ? > If we design the protocol would you require us to provide > an API library as well as documentation for the separate > control system and if so what is that system ? This part of the design is not very well defined. A lot depends on the architecture of the acquisition hardware. The hub computer in Fig.8 of the specs would interface to our control system and that software is our problem. Of course we *do* need to access the data acquired, which may imply some form of API or a simple network protocol. If indeed such an API is needed, then yes, we will ask you to provide it, with documentation allowing us to use it. > 2. Will the system have, via the Base-T Ethernet TCP/IP network, access > to a date/time reference (NTP) and perhaps other network > resources ? If such services are needed, they should probably be provided by a server running on the hub computer. My current thinking is to put all acquisition modules on a private network, with the hub computer the only path to the rest of the world. Then again, I'm no network specialist. > 3. The three analogue inputs are stated as having a 1 V peak signal. > What is the impedance of these lines and are they fed as a > balanced line signal ? What size/type cable is used and is > there any special requirement as to connector type ? The 1Vp is a ballpark figure, we could go up to about 2Vp, if so required, but beyond that, distortion is likely to become a problem. The signals are single-ended, on 50 Ohm coax, and must be terminated into 50 Ohms. Preferred connector types are BNC if space allows, or LEMO-00 otherwise. Other connector types can be considered. > 4. It is stated that the analogue inputs need to be sampled to give an > effective 10.5 bits. In order to achieve this with a 12bit ADC > the input levels will need to accurately controlled [...] > should we provide a controllable gain stage before the ADC's ? There is no need for controllable gain stages. The pick-up pre-amplifiers have that already. The resolution specs assume optimal filling of the ADCs, but I recognise that in practice, this is not likely to be always the case. Resolution will be measured in the lab with optimal and clean signals. I'd say that beyond that, it's our problem. > 5. Do we need to implement any anti-aliasing filters or any other > analogue signal conditioning or is this all handled > by the remote pre-amplifier ? The remote amplifier has a O(5) Bessel roll-off, with -3dB @ 35MHz , but that comes from a filter at its input. So from the perspective of noise, an anti-aliasing filter may be beneficial, but it should not mess up the pulse response. Since further processing involves numerical integration, which is effectively yet another lowpass filter pole, I think we can do without. > 6. It is not clear to me what external analogue/digital timing signals > will be available to the system. This is what I understand: > > a. TTL 50ohm 10MHz master clock for synchronisation of ADC's > etc. > b. /TTL 50ohm C-Timing 1ms clock > c. /TTL 50ohm Injection start signal > d. /TTL 50ohm Ejection signal > e. Analogue 50ohm Fref signal simulating PU beam amplitude for > initial internal synchronisation (Or is this a digital > stream ?) > > Is this correct ? > Would we just get a single feed from each synchronisation source > and have to buffer and distribute the timing signals to each of > processing engines or can you provide multiple timing signals ? I'll deal with that question tomorrow. > 7. For performing basic system tests at our site and at CERN, is there > an analogue test signal and digital timing signal generator > available that would simulate the Proton Synchrotron or should > we cost in the design/build of this item ? I have a box that simulates pick-up signals at a fixed amplitude and frequency, for my own use. I'm not willing to lend it to anyone. I can provide a CD with acquired PU signals which could conceivably be used to program an AWG. The CD also contains some C source code as a proof-of-principle of the algorithms. Let me know if you want it. > 8. As the system would be based on FPGA's this allows CERN to modify > the hardware algorithms used as mentioned in the technical > specification. Are there any ideas on extra algorithms that > the system may need to perform in the future ? > Also should we cost in and supply an FPGA Development system > for CERN's use ? At this time, I do not foresee any future algorithms to be added. (Or I would have tried to deal with them right away.) But we are a research institute and the machines are in constant evolution. We expect you to provide enough documentation and training to allow us to apply modifications. We have site licenses to several FPGA development tools, so you shouldn't include that unless you require the use something exotic. > 9. We are considering an number of possible implementation methods. > One will use multiple FPGA's controlled by multiple CPCI host > controllers. Another will have autonomous FPGA engines > connected via the Base-T Ethernet. It is possible that the > autonomous FPGA engines could be situated close to the > PU units rather than at a central location. Would the > later method be of interest to CERN or would you rather > keep the equipment centralised ? Believe me, you want as little electronics as possible close to the PUs. Radiation kills electronics too. All signals are already brought together in one place. > 10. It is stated that information on the software to be used for > documentation is in "Annex 1". We don't appear to have > "Annex 1", is this available ? Yes, Annex 1 seems to be missing. I've never seen it myself. I'll find out where it is. > 11. For remote monitoring, support and maintenance would a secure > shell based Internet connection to the trajectory measurement > system be available ? We'll consider. For the time being, better assume that such access will only be allowed from inside the CERN network. I hope this clears things up a bit. Feel free to ask for more. Best regards, Jeroen Belleman