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: Horiuchi, Shinji <shoriuchi_at_email.protected>
Date: Wed, 26 Feb 2014 15:14:36 +1100

Hi Chris, Jamie and all,

I am coming back to this old sled. We've heard great news last week that
Bonn DiFX Correlator found first fringes for data with
Tidbinbilla70m-DVP and Hobart/Hart. This was recorded for the 16ch,
16MHz, 2bit mode. I think this would support the case that we can get
rid of Tid Mark5A recorder as far as LBA is concerned. There are a few
issues to consider before doing that.

1. As pointed out by Chris, we should still be able to send modules to
Parkes to copy off from the Mark5B+ there. The email from Jamie suggest
Mark5C data can be read on Mark5B if recorded to Mark5B module. We might
have to test that for reasonably long duration data. Would the situation
be the same for Parkes and Hobart? What about Curtin or other LBA hub?

2. LBA experiments at Tid with Mark5A have been for 8ch, 16MHz, 2bit, at
half Gbps that can be supported with DVP. An inconvenient thing with DVP
is it always records 32channels, i.e. 2Gbps for this mode.

3. VSOP mode with 4ch x 16MHz may also be supported with DVP, but
2ch(or4ch) x 64MHz would be not so easy and practical. But we hopefully
can still use LBA-DR for normal LBA experiments that include
RadioAstron. .

Any comments?

Cheers,
Shinji.

-----Original Message-----
From: Jamie McCallum [mailto:Jamie.McCallum_at_email.protected
Sent: Monday, 21 October 2013 11:51 AM
To: Horiuchi, Shinji; vlbiobs_at_email.protected
yyk_at_email.protected
Subject: Re: Tidbinbilla digital VLBI backend with Mark5C

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.
################################################################
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 2014-02-26 15:14:40