Tomorrow some of us are meeting with Sandy Weinreb and Steve Smith to
talk about a wideband, channelized down-converter. Ultimately we want
to be able to down-convert and digitize 14 - 26Ghz simultaneously.
Sandy's GAVRT design was based on the 2 Gsamp/s CASPER iADCs. Using
that approach,
cannot cover
the whole 17-27 GHz band but we could break it into two.
Jouko's recommendation seems like a good idea. Fiber cables are cheap.
If I understand it correctly, the single mode fibers will support analog
if we need to go that way.
Best regards
Tom
Best Wishes,
Dan
Tom
John Ford wrote:
We've decided (Maybe prematurely?) that wide-band analog links are not the
way to go, for single-dish, at least. The stability we need was not there
the last time I looked, when you factor in the twisting of the fibers, the
diurnal temperature variations, etc. Can you give me
I'm trying to scope the hardware required for SERENDIP-type science
piggy-backing on DSN down-link (passive, no transmitter) tracks.
As a baseline, I'm assuming one ROACH per antenna per activity.
Possible activities would be:
* searching for pulsars and transient pulses
* SETI
*
Mark Wagner wrote:
I have recently tried to install Xilinx 11.4 and have run into a
standard exception error involving the System Generator generated perl
script MasterScriptXXX.pl. This error has occurred on Ubuntu 8.04,
9.10 and Fedora 12. Xilinx support would not answer questions until I
not to.
Cheers
Tom
Scott Ransom wrote:
On Wednesday 10 February 2010 09:00:59 am Tom Kuiper wrote:
For reasons that are implicit in this finding, I suggest that if you
have a lot of locally developed software running under a Debian-like
distribution, that you buy a new computer dedicated
Mark Wagner wrote:
2. Getting the python stuff setup on RHEL5 IS a headache. I would
prefer Ubuntu
as well, but unfortunately Xilinx doesn't support that.
Maybe Xilinx might be willing to reconsider. Companies like Red Hat
because they can have a service level agreement and guaranteed
Dan Werthimer wrote:
I'm very sad to report that Don Backer died this afternoon.
Don collapsed just outside his home, probably from a heart attack.
Thank you, Dan, for letting us know. What dismal news with which to
start the week. He was such a brilliant, inspiring and vital person.
I'm
Greetings everyone!
Steve and I are trying to get the SETI spectrometer ready to go to
Goldstone. We put it in its (hopefully) final configuration but are not
getting meaningful data now. I imagine that it has something to do with
this self-test output.
Reading SNAP_CT_IN
CH -
On 06/01/2011 11:19 AM, John Ford wrote:
I'd like to know more about this ADC on the hardware wiki page under
KatADC:
Dual 8-bit 2.0GSPS (or Single 8-bit 4.0GSPS), National Semiconductor
ADC08D1520/S7002396 ADC, RF Front-End
However, the KatADC page doesn't seem to have any information about
On 02/17/2012 04:01 PM, Andrew Lutomirski wrote:
At MIT, we mostly use Fedora. It seems to work, horror stories
notwithstanding. Just don't ask for support.
There are also tools like schroot that can help with running old
distros inside a modern distro.
Thank you, Andy. I didn't know
On 03/02/2012 05:43 PM, Tom Kuiper wrote:
On 03/02/2012 04:49 PM, Dan Werthimer wrote:
if you are using kat-ADC's, you'll need to change
the adc yellow block in the tutorial.
OK. In that case I think there's some text somewhere that I read that's
misleading. I'll try to find
I would like to test a set-up that I've just configured. I've got a
KatADC in Z-Doc 0 of a ROACH-1. The signal is going into IF 0. Pretty
much anything will do, though. It's easy to swap Z-Docs and IF inputs,
so that's not a constraint.
Even the first stage of a FX correlator would be
, at 21:38, Tom Kuiper wrote:
I would like to test a set-up that I've just configured. I've got a
KatADC in Z-Doc 0 of a ROACH-1. The signal is going into IF 0.
Pretty much anything will do, though. It's easy to swap Z-Docs and
IF inputs, so that's not a constraint.
Even the first stage
little instrument.
On 04 Mar 2012, at 21:38, Tom Kuiper wrote:
I would like to test a set-up that I've just configured. I've got a
KatADC in Z-Doc 0 of a ROACH-1. The signal is going into IF 0.
Pretty much anything will do, though. It's easy to swap Z-Docs and
IF inputs, so that's
I'm trying to run the initialization script for the KAT 16K
spectrometer. I get FFT overflow even though all the shift bits are
set. How is this possible? Here's the transcript:
$ ./rfi_init.py
Connecting to ROACH... done.
Programming FPGA... done
Checking clocks...
On 08/27/2012 08:49 AM, Marc Welz wrote:
Apologies, my previous email contains errors, I didn't realise that you
were using two hops to get to the roach.
I was just replying to that when I got this :-)
However, it still seems reasonable to use the ssh port, when using separate
commands
It appears that there is something I don't understand about memory
mapped IO.
I'm trying to write directly to a firmware register. I have tried in
Python in binary mode with various options regarding buffering. I have
also tried the command line 'echo 1 register'. Whatever I try, the
On 08/28/2012 10:22 AM, Adam Barta wrote:
If you are running tcpborphserver2 on the roach then you can use the
following commands to write and read from registers through the tcp
interface on port 7147.
?wordwrite register-name word-offset payload
?write register-name register-offset payload
On 08/28/2012 10:45 AM, Adam Barta wrote:
Yes its the trailing newline i think so
echo -en \xFF
would work
Yes, thanks for the -n tip. Here's what I get.
root@roach1:/proc/1174/hw/ioreg# echo -en \x01\x00 trig_adc0
root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd
78 30 31 78
Aha!
root@roach1:/proc/1174/hw/ioreg# echo -en \xFF\xFF trig_adc0
root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd
ff ff 46 78 |..Fx|
0004
Tom
On 08/28/2012 10:48 AM, Tom Kuiper wrote:
On 08/28/2012 10:45 AM, Adam Barta wrote:
Yes its
On 08/28/2012 11:05 AM, Patrick Brandt wrote:
Tom Kuiper wrote:
It appears that there is something I don't understand about memory
mapped IO.
I'm trying to write directly to a firmware register. I have tried in
Python in binary mode with various options regarding buffering. I
have also
||
0004
root@roach1:/proc/1221/hw/ioreg# ls -l
total 0
-r--r--r-- 1 root root 4 Jul 28 02:13 acc_cnt
...
-rw-rw-rw- 1 root root 0 Jul 28 02:21 sys_scratchpad
-rw-rw-rw- 1 root root 4 Jul 28 02:13 trig_adc0
On Tue, Aug 28, 2012 at 7:48 PM, Tom Kuiper kui...@jpl.nasa.gov
mailto:kui
On 08/28/2012 03:11 PM, Tom Kuiper wrote:
I have the feeling that the file length going to zero on a simple
write is unintended and been lurking in the borph code since no one
ever tried such a simple OS-level write. I'm guessing that the file
pointer, which is reset to zero before the write
On 08/28/2012 03:54 PM, David MacMahon wrote:
On Aug 28, 2012, at 3:39 PM, Tom Kuiper wrote:
I don't know how to get Python to read more than teh nominal file size if it is
supposed to look like a file.
If you want to read the register value a second time, you need to seek
the file and before reading. Still get 0 bytes back.
I'm not having much luck in finding a way to change the file size.
There is a 'truncate' method that will do it but Linux will zero fill an
extended file.
Cheers
Tom
On Wed, Aug 29, 2012 at 1:00 AM, Tom Kuiper kui...@jpl.nasa.gov
mailto:kui
Thanks for that, Jason! It is very timely. The reason I went down this
path is because I have a spectrometer design, by Joseph Trinh, which
takes a slightly different approach to bram access and so I could not
use the katcp_wrapper which I'd been using with your 16K spectrometer.
He'd
, you should be able to get at least twice the channel
resolution. If there's BRAM left over, you should be able to get even more.
I forgot to mention that we need a bandwidth of at least 640 MHz.
Tom
Jason
On 29 Aug 2012, at 11:19, Tom Kuiper wrote:
Thanks for that, Jason
:32, Tom Kuiper wrote:
On 08/29/2012 02:30 AM, Jason Manley wrote:
If you take a look at the pocket correlator design (tutorial 4), you'll find
that it does four inputs of 400MHz bandwidth (800Msps). I think it has 4-tap
PFBs with 1024 channels by default, which fits into a ROACH-1
For the many of us who haven't been to South Africa yet, we can at least
have a little flavour of it. In a British shop in Santa Monica I came
across Karoo Farmstyle Apricot cooking sauce. It turned a pound of
leftover beef into a delicious meal. Bledie Lekker! Here's a website
from the
On 10/02/2012 12:03 AM, homin wrote:
We have been using Scientific Linux for a while. It have been working
well so far basically. But we never compiled 8K point FFT, and we
experienced strange behavior at the very beginning.
Is it possible to have one host dedicated to the toolflow and do
I have two KATADCs, one each in ZDOC0 of two ROACH-1 boards (named
roach1 and roach2). It appears that the attenuator for input 0 of the
KATADC in roach2 is at 0 dB for whatever attenuation setting command is
sent to it. The other three inputs respond as I expect. I assume that
this is some
On 12/20/2012 01:33 PM, Larry D'Addario wrote:
I suggest that you swap the KATADC boards between roach1 and roach2.
Does the problem stay with roach2 or does it move with the KATADC board?
I'm pretty sure that I know how that would turn out. Unfortunately, I'm
at home in West LA, 30 min with
Can someone point me to the documentation about the KATADCs
self-calibration function?
Is there a discussion somewhere about the optimum r.m.s. voltage for the
sampler input?
Thanks,
Tom
I have two designs I'm playing with. I find that if I run the
KAT_rfi_sys 16K spectrometer, then after that I can control the RF
attenuators with corr.katadc.rf_fe_set(). However, if I load another
design developed here (kurtspec) into a cold ROACH (i.e. after power
cycling)
should have made that explicit.
Apologies. I guess, pending a resolution of this issue, I can try a
work-around in which I first load KAT_rfi_sys and then replace it with
kurtspec. Not elegant but ...
Thanks and Happy New Year to all
Tom
Jason
On 29 Dec 2012, at 05:03, Tom Kuiper wrote
On 12/29/2012 09:19 AM, Tom Kuiper wrote:
I guess, pending a resolution of this issue, I can try a work-around
in which I first load KAT_rfi_sys and then replace it with kurtspec.
Not elegant but ...
Yup! That works.
Thanks for the explanation, Jason.
Tom
If there is a boffile running on a ROACH-1 PPC, does it have to be
killed explicitly before borphserver will load another one? Or can you
just replace the running boffile with a new one?
fpga = corr.katcp_wrapper.FpgaClient()
fpga.progdev(bitstream)
Hm! I just noticed an fpga.stop(). Do
On 01/02/2013 10:12 PM, Jason Manley wrote:
No, you should be able to just do the new progdev.
If you do want to explicitly deprogram, do progdev with a null string argument:
fpga.progdev(None) or fpga.progdev('').
fpga.stop() kills katcp comms (used for link teardown before exiting your
Thanks, Steve.
Tom
Original Message
Subject:Re: Fwd: Fwd: [casper] IQ Mixing Below 1 GHz
Date: Wed, 24 Apr 2013 10:44:03 -0700
From: Steve Smith ste...@caltech.edu
To: Tom Kuiper kui...@jpl.nasa.gov, manuel.m.fra...@jpl.nasa.gov
Hittite has IQ mixers
On 06/19/2013 05:16 PM, Gary, Dale E. wrote:
I would like to get a ROACH1 to netboot on the same network as our
ROACH2s, but I am not sure how to specify two different directories
from which to serve uImages to different machines. Is it possible? I
am using the Ubuntu tftp server, whose
Greetings all!
The ActelFusion MMS subsystem on the ROACH-1 boards has a power up on
reset option. During some testing a week or so ago, this option was
turned off on one of our ROACHes. So I was not surprised that I could
not program the FPGA with firmware. However, I was surprised to see
://casper.berkeley.edu/wiki/Projects
--
http://www.linkedin.com/pub/tom-kuiper/50/ba5/264
sample values?
If you swap ADCs, does the same input signal show the same skewness?
Thanks. The problem is solved and the explanation to embarrassing to
relate here. If you offer me a beer...
Cheers
Tom
--
http://www.linkedin.com/pub/tom-kuiper/50/ba5/264
I'm interested in experience people have had using the same equipment
installed on a telescope for different projects using different firmware
and software. Have there been issues with firmware swapping? Are there
software issues that cannot be managed by using a different control
computer
What situations could cause est_brd_clk() to give the wrong answer?
I have two ROACH1s and a Valon 5007. Every time we check the Valon it
puts out the required clock frequency, 1020 MHz, at about +7 dBm.
When I initialize the ROACHs (roach1, roach2) from an ipython command
line,
On 04/18/2018 10:53 AM, Gary, Dale E. wrote:
What digitizer are these using? We have had issues with the KATADC on
ROACH2, which turns out to need some register initializations in order
to function properly, and the symptom is a bad est_brd_clk() result.
Hey, wow, Dale! That was fast. Yes,
On 04/19/2018 11:20 AM, Jack Hickish wrote:
The clock should trigger capture of the values on the data lines when
they are stable, so putting the clock edges out of phase with the data
transitions makes sense. Having said that, the controller HDL may or
may not mess with the relative phases of
On 04/19/2018 03:18 PM, Jack Hickish wrote:
If this is the case I would imagine that you see est_brd_clk taking
varying amounts of time to return -- just so this doesn't keep me
awake at night, is that the case?
Sleep well tonight. I see all kinds of numbers between and 300 and 480
but
spectra. I think there is something in est_brd_clk() that makes
an assumption about timing that is not valid in this situation.
Regards
Tom
On 04/19/2018 02:59 PM, Tom Kuiper wrote:
On 04/19/2018 11:52 AM, Jack Hickish wrote:
Thinking about this a moment longer -- I don't think an incorrect
This is probably aimed at Jack now but someone else may have an answer
to the question below.
On 04/18/2018 11:33 AM, Gary, Dale E. wrote:
This sounds like the problem we had until Matt Dexter and Dave
MacMahon determined that some KatADC registers need to be set for
correct ADC operation.
On 04/19/2018 11:52 AM, Jack Hickish wrote:
Thinking about this a moment longer -- I don't think an incorrect
clock phase will be related to reported board clock problems. You can
completely mangle the clock phase wrt to data lines, and the FPGA
should still correctly lock onto the clock and
52 matches
Mail list logo
