quot;
Take care,
Glenn
On Thu, Sep 14, 2023, 06:02 Jason Ray wrote:
Hi All,
I have a question about our simulink libraries at GBO. The
backstory is
that we installed a version (casper_astro_soak_test for Xilinx
14.7) of
the casper tools many years ago during VEGAS develo
Hi All,
I have a question about our simulink libraries at GBO. The backstory is
that we installed a version (casper_astro_soak_test for Xilinx 14.7) of
the casper tools many years ago during VEGAS development. It has always
worked fine until sometime in the past year or so, I can't seem to l
Morag,
Although not currently in service, for completeness "GUPPY" was actually
spelled "GUPPI"
Thanks,
Jason
On 8/31/2022 6:53 AM, Morag Brown wrote:
Ciao dalla Sardegna, collaborati!
I'm hoping to put together a more up-to-date list of instruments that
have been built using CASPER hardwa
Hi All,
Does anyone know what the fault led and/or shutdown thresholds are for
the roach2 board?
I found this table for roach1:
https://casper.berkeley.edu/wiki/Roach_monitor_and_management_subsystem
But I can't find anything similar for roach2.
Also, does anyone know if there's a log kept o
John,
We use these picoPSU modules exclusively for powering our roach2
systems. They have 120W capacity and are powered from +12VDC.
http://www.mini-box.com/s.nl/it.A/id.417/.f
So far they've been great.
Good luck!
Jason
On 12/8/2017 1:18 PM, John D. Sahr wrote:
I have an application for
Hi Glenn,
A while back, I repaired a roach2 problem that had similar symptoms.
Its probably not terribly likely that yours has the same problem, but I
thought I'd share in case...
The short story is that a capacitor (C163) failed and I could measure
~220ohms across it. This particular cap
> Thanks for all the help
>
> Heystek
>
> On Wed, Mar 22, 2017 at 9:23 PM, Jason Ray mailto:j...@nrao.edu>> wrote:
> Heystek,
>
> Is this a known good roach1 board? Could it have been
bri
s a 'digital
finger' that emulated the pressing of the power button on the chassis itself.
Our ROACH board at LoFASM-II at the LWA North Arm is configured this way.
Best of luck,
L
Sent from my iPhone
On Dec 3, 2014, at 18:42, Jason Ray wrote:
All,
We're having an issue with
All,
We're having an issue with a roach1 in GB where we can't access the xport.
It doesn't seem to respond using a web browser to the default IP of
192.168.20.4. We also had our sys admin add an entry for its MAC address
to our DHCP server and we still cannot communicate with it.
As far as
Hi Sara,
This sounds like a failure mode with the roach in which the 1V supply is
disabled, due to a failed mosfet (Q13) on the board. We've seen this
problem several times and can repair them in Green Bank. We repaired
this exact problem on one of the mustang 1.5 roaches for Justus about a
All,
We have a student (Devin Cody, who just signed up for the casper list)
working at NRAO-Green Bank this summer and he is working on implementing
the offset/gain/phase, INL, etc calibration routines for the ADC083000.
There's been quite a bit of work on these calibrations for the ADC5G,
b
Hi Richard,
Do you have the USB cable connected & a terminal program running, where
you can watch it boot up?
If so, once you hit any key to interrupt the boot, you type:
setenv bootcmd run netboot
saveenv
That should do it.
Jason
On Fri, 21 Mar 2014, Richard Black wrote:
Hi all,
I'm
Hi Alec,
I'm using a windows XP laptop with hyperterminal. This is the same
setup I've used in the past for doing the xmodem transfer.
Maybe I should gather up another machine and try it...?
Thanks,
Jason
On 3/20/2014 11:26 AM, Alec Rust wrote:
Hi Jason, this is a tricky problem! What progr
All,
I'm currently troubleshooting a bad roach1 board, and I thought I'd ask
for some advice about the problems I'm seeing.
The board seems to be bricked. It doesn't do anything on power up. So,
I attached our wiggler and it appears to successfully run the macro
loadram_rinit_auto.mac. How
data and measurements.
were your temperature measurements in the
standard roach2 enclosure?
i think the VEGAS SFP+ PHY's are mounted
differently and have different cooling than the
standard roach2 enclosure.
best wishes,
dan
On Fri, Dec 6, 2013 at 9:53 AM, Jason Ray
<<mailto:j.
Hi Rich,
So far we haven't had any trouble with the SFP+ boards (8 total) in
our vegas machine. I guess they've been powered up continuously and
in use for around a year now.
We were concerned about how warm the PHY chips run so I spent a
little time looking into it. The datasheet says:
All,
Occasionally I've noticed (maybe a handful of times over the past few
months) that progdev will fail with our roach2 boards. After working
fine for long periods, it will fail to program out of nowhere and the
only fix is to reboot the roach2.
I copied/pasted the python error dialog bel
On Tue, 25 Jun 2013, David Saroff wrote:
Casper fellow-travelers,
When I run casper_xps from the matlab command prompt a lot happens that
produces a .bof file that works. I'm curious about the EDK/ISE reports,
timing in particular. The Casper XPS window with the big "Run XPS" button,
has a "Vie
design
I can tell you that it only just fits in a 1U case, with about 1mm
to spare above the DRAM DIMM after it's mounted on standoffs.
Jason
On 23 Aug 2012, at 16:37, Jason Ray wrote:
> All,
>
> Does anyone have a mechanical drawing of the roach 2
board? Mainly the bo
All,
Does anyone have a mechanical drawing of the roach 2 board? Mainly
the board dimensions and mounting hole locations.
I'll also need to know the approximate overall height of the board
assembly with the tallest mezzanine board (CX4 or SFP+?) installed.
Thanks in advance!
Jason
ded.
>
> I had a thought that we should check the serial numbers and see if they
> are from the same batch. Maybe some bad parts or ESD damage?
>
> John
>
>> Thanks,
>> Glenn
>>
>> On Tue, Jun 19, 2012 at 9:52 AM, Jason Ray wrote:
>>> The first ti
ut in dmesg gave
> non-sense readings.
>
> In any event, the cause was traced to the +1 volt supply MOSFET switch.
> Replacing that mosfet fixed both roaches. Kudos to Jason Ray for finding
> the problem originally.
>
> John
>
>
>
Dangit... typo. That 3rd sentence should've said "combinations
of the bof file, py file, and mdl file that DO NOT work directly.
Thanks,
Jason
At 11:31 AM 4/25/2012, Jason Ray wrote:
All,
I recently tried to use tutorial 2 to do some troubleshooting of
10GbE ports on a coup
All,
I recently tried to use tutorial 2 to do some troubleshooting of
10GbE ports on a couple roaches. I found a few inconsistencies in
the file links that I thought I would point out.
Mainly, there seems to be several combinations of the bof file, py
file, and mdl file that work directly.
e the
linear dimension tool. I have a new
machine and don't have Allegro up yet,
but will be glad to walk through it if
Jason has a working setup.
DAN
On Mon, 20 Dec 2010 10:59:01 -0500, Jason Ray wrote:
> Thanks Dan!
>
> Jason
>
> At 11:13 AM 12/17/2010, Dan Werthimer wrot
Thanks Dan!
Jason
At 11:13 AM 12/17/2010, Dan Werthimer wrote:
hi jason,
i'm forwarding your request to dan burke,
who designed the bee2 enclosure and power supply.
dan b. might have a drawing that shows the bee2 board
mounting holes???
best,
dan
On 12/17/2010 7:52 AM, Jason Ray
All,
Does anyone have a mechanical drawing that depicts the dimensions of
the BEE2 mounting holes?
Thanks,
Jason
At 09:16 PM 9/29/2010, Suraj Gowda wrote:
At 3 Gs/s, the FPGA clock rate is 187.5 MHz. Is this in range of the
DRAM clock?
Maybe you could describe what the output is and/or how it's incorrect?
It's been a while since I attempted to use that interface.
We had a 200 MHz sine wave input to the
, extra transfers are inserted
into the data stream. Etc.
I will get Jason Ray or Randy to send you our synchronizer model file,
which is implemented in an extra FPGA on the BEE2.
We fought this problem for many months. It is indeed real...
Agreed!
Randy & I are both out of the office today
On Fri, 28 Aug 2009, Richard Armstrong wrote:
This week I've been trying to clock the BEE2 off an IBOB-generated clock
with an LVTTL-to-LVPECL clock driver. I changed the BEE2 design and changed
a jumper to select user-clock on the BEE2 board. Unfortunately, this doesn't
seem to help much (altho
All,
Randy and I are working on a low resolution version of our GUPPi DSP
designs. Basically, we want to take our existing (and widely used)
2048 channel design and reduce it to 128 channels, for the sake of
faster readout times. We did this by simply changing the mask
parameters of the PFB
1
and 3 but I can't remember right now).
Perhaps you can solve your problem as simply as not allowing reads from the
XAUI until after say 32 clocks from when the iBOB begins transmitting,
to allow the buffers to fill up a little.
Glenn
On 7/21/08, Jason Ray wrote:
All,
As some of you may
All,
As some of you may know, Randy & I have been working on getting
reliable data transmission across the inter-chip connections on the
BEE2. We managed to get that working reliably and have moved on to
the next problem that has reared its ugly head.
Once we got back to the point of lookin
All,
As some of you know, Randy and I have been recently working on trying
to get the interchip connections to work properly, utilizing the
packed registers, phase delays, etc to get synchronized data into
FPGA2. We have a question regarding the build times for BEE2 designs
that use these in
All,
Randy and I are closing in one completing phase 1 of our pulsar
machine. We have two iBOB samplers streaming samples over XAUI into
the BEE2's FPGA1 and FPGA3, where the pfb & fft take place. Then
we're using the inter-chip connections to pass the FFT bin values
over to FPGA2 where the
35 matches
Mail list logo
