This loads a font easier to read for people with dyslexia.
This renders the document in high contrast mode.
This renders the document as white on black
This can help those with trouble processing rapid screen movements.

Re: Tidbinbilla digital VLBI backend with Mark5C

From: Jamie McCallum <Jamie.McCallum_at_email.protected>
Date: Mon, 21 Oct 2013 11:51:00 +1100

Hi Shinji,
        The quick answer for UTas/AuScope compatibility is that if the VDIF
data format is ok for DiFX, it should be fine for us. I have a question
about the DVP though - With the DDC mode, are you able to select a
subset of the 32 USB/LSB channels to be recorded or will it always
produce a 32 channel stream? I know that the latter is the case for the
DBBC using the Fila10G.
        One other thing with the diskpacks - the Mark5C uses the same diskpacks
as the mark5B systems and the recorded files can be read back on a
mark5B+ using fuseMk5. I was able to record at 2 Gbps onto a single
diskpack (normally rated at 1 Gbps) without problems though this isn't
recommended, especially for long scans. I haven't tried dual-bank mode
with the mark5 units yet, and I'm not sure if the read-back is compatible.
Cheers,
Jamie



On 16/10/13 14:09, Horiuchi, Shinji wrote:
> Dear LBA observers,
>
> At Tidbinbilla we’ve recently installed a new JPL built VLBI digital
> backend called the Deep Space Station VLBI Processor (DVP). The new
> system is adopting CASPER/ROACH and Mark5C, similar to the NRAO/Haystack
> model, and is able record data up to 2Gbps. We succeeded to detect
> fringes for VLBI experiments within DSN at 1 and 2 Gbps recording rates
> using this system. Now JPL wants to remove the existing Mark5A recorder
> at Tid after the next 6 month ‘soaking’ period from now to convert it to
> a Mark5C as a spare across DSN.
>
> Then the questions for you are:
>
> 1)Should the new DVP/Mark5C system be sufficient/compatible to observe
> some of LBA observations at Tid using Mark5A, such as the v271 series
> for Leonid and some others, e.g. for Yuri Kovalev, Oleg Titov, and
> Michael Bietenholz as we did in the past? With the DVP we can record up
> to 2Gbps, so we can increase sensitivity if we establish the use of the
> new system for LBA. We need a fringe test if we decide it’s feasible. In
> that case, can anyone provide us a Mark5C diskpack to be used for LBA?
>
> 2)If we should keep the existing Mark4-DAT & Mark5A backend for LBA
> experiments, is anyone able to provide us an unused Mark5A module? Do
> you think it’s worthwhile?
>
> 3)If none of Mark5C and Mark5A options as mentioned above is possible,
> how bad is living only with the LBA-DR at Tid for the next several
> years? We can record fine up to 512Mbps, which I think the maximum data
> rate for any LBA stations to support. Perhaps only issue for Tid with
> only the LBA-DR is limited number of IFs for experiments that require
> wide frequency ranges.
>
> For your information, attached is a VLBI2010 Receiver Back End
> Comparison written by Bill Petrachenko and distributed earlier this year
> to the IVS community (see the part for ‘JPL DBE’) .
>
> Tips for DVP Data Format: We don’t support Mark5B-emulated data. We
> write VDIF format to the Mark5C disk packs. We can output 16 Complex
> I/Q Channels, or 32 USB/LSB channels. Each data packet contains data
> from all channels. We can record up to 2 Gb/sec on one disk pack.
>
> Any your feedback would be appreciated!
>
> Chris and Cormac, I expect your inputs from correlators perspective.
>
> People from U-Tas, what about the case also for the
> Tid-AuScope/Hobart/Ceduna alone VLBI?
>
> Regards,
>
> Shinji.
>
> ------------------------------------------------------------------------
> *Note:*
> If you received this email in error, please notify the sender
> immediately and delete the email and attachments. This email may contain
> private or sensitive information. Any forwarding or dissemination of
> information, other than by entities directly addressed in this email is
> prohibited. The views expressed in this email do not necessarily reflect
> the views of CDSCC or its business partners. The organisations accept no
> responsibility for any virus that potentially could be transmitted in
> this email, however all email is scanned prior to being transmitted.
Received on 2013-10-21 11:51:24