Hi Dave,
Yes, I am using the ultra rapid data, and have taken the other issues you
mention into account (not necessarily correctly...but I try). I am not
familiar with NOVAS, but just looked it up on the usno pages. I will look at
it more carefully, since it is the XYZ coordinates that I worr
Jason,
The parts both looked fine, they just didn't turn on. No indication
of heat damage on the part, board, or traces.
The first roach we found this on is SN 020145 and the second one is SN 030191.
Thanks,
Jason
At 01:16 PM 6/19/2012, Jason Manley wrote:
Thanks for the feedback!
I'd al
Hi, Dale,
On Jun 19, 2012, at 7:14 AM, Gary, Dale wrote:
> Does anyone know an accurate way to find the location of GPS satellites? I
> wrote software to calculate this, nominally to an accuracy of a few meters
> for the satellites, but I never succeed in getting steady phases after
> correct
Thanks for the feedback!
I'd also like to understand this problem a little better.
Q13 sits on the 5V rail and the P-channel MOSFET is rated at -11A with a 13mohm
on resistance. That's good for over 50W. Was there any indication of heat
damage on the failed parts (due to overloading or maybe th
Hi andrew thanks a lot for your answer.
I have some more questions.
- According to your answer, all the computation in order to get the time
delay between signals is made by software and off line, instead of
calculating that delay in the FPGA and in Real Time.
So first, ¿how do you get the numb
> Jason R. and John,
> Was the roach running a particularly intensive design at the time
> around the failure? Just wondering why this part would be failing. Is
> the current limit somehow being exceeded?
We don't know about the first one, because it came to us from Socorro, but
the second roach w
Jason R. and John,
Was the roach running a particularly intensive design at the time
around the failure? Just wondering why this part would be failing. Is
the current limit somehow being exceeded?
Thanks,
Glenn
On Tue, Jun 19, 2012 at 9:52 AM, Jason Ray wrote:
> The first time I was troubleshooti
The first time I was troubleshooting this problem, I did see a fault
on the 1V supply with roach_monitor.py. I didn't check
roach_monitor.py on the second roach because the problem was so fresh
in our mind we just jumped to the finish line and checked the mosfet
with a meter, then replaced it.
Hi Dale
> On another topic, Andrew, you state that we can calculate the delays since we
> know the position of the antennas and source.
> Does anyone know an accurate way to find the location of GPS satellites? ...
Our system is not being used for satellites and I assume that stars have
bette
On 06/19/2012 03:45 AM, Andrew Martens wrote:
We recently found a bug in the FFT for a specific parameter set that
causes data corruption that includes overflows. If you use 'embedded' as
your multiplier implementation of choice you may have this bug.
Thank you, Andrew and Jason, for that advice.
> Might make for a useful tutorial session? It's actually really easy to run
> lots of ROACH boards on a network.
I think this would be great. I'll put it in the program somewhere!
John
>
> Of the people attending from SKA-SA, I don't think any of us are planning
> to talk about this in our mai
Hi Jesus,
If you are interested, you can see a video of a three-antenna, single-pol
correlator in action doing exactly this, at
http://www.ovsa.njit.edu/expansion/assets/IMG_0485.MOV (this is just a movie
capture with my iPhone). The bandwidth of the correlator is 500 MHz, but in
the video th
Hi All,
We are working on a correlator design for a 16-antenna, dual pol system based
on eight ROACH-2 boards. I am confident we can make the digital hardware work,
but the network setup, boot process, and control of these 8 boards is a total
mystery to me. I wonder if someone could give a su
Yeah, this works well! For those running dual ROACH-1 and ROACH-2 setups
side-by-side, it's useful to have your DHCP server be able to hand out
different boot configurations for the two board types based on MAC addresses.
Jason
On 19 Jun 2012, at 15:22, Vacaliuc, Bogdan wrote:
> How about sett
Good sleuthing!
FWIW, roach_monitor.py is supposed to be able to pull the log out of the Actel
Fusion, which should have logged a fault on the 1V rail before shutting-down
the board. This should work independent of PPC or dmesg states. I'm afraid I
have little faith in the Fusion/Xport combo t
How about setting the DHCP server to statically bind an IP based on the
MAC it receives from the client?
Best Regards,
-bogdan
On 6/19/12 7:24 AM, "Jason Manley" wrote:
>>BTW, is there a solution for the DHCP client not renewing its lease when
>>eth0 is configured during boot time?
>
>Our work
Hi all. We've had a couple of ROACH failures with identical causes.
Maybe some of you have seen this, but it's worth keeping in mind in case
you have a problem.
The symptom is that the ROACH would sort of power on, but then turn off
spontaneously. On one, as soon as the bof was loaded the roach
> BTW, is there a solution for the DHCP client not renewing its lease when eth0
> is configured during boot time?
No... Marc can comment further but I believe the problem is two-fold:
*) Firstly, when using netboot, the IP address is passed to the kernel at boot
time. This is then static until
> I'm not sure this is a bug. Each user will need to configure
> /etc/network/interfaces, /etc/resolv.conf, /etc/hostname etc according to
> their specific network configurations. Most people with larger systems run
> an NFS root filesystem along with DHCP, so this gets configured
> automatically o
Hey Tom
We recently found a bug in the FFT for a specific parameter set that
causes data corruption that includes overflows. If you use 'embedded' as
your multiplier implementation of choice you may have this bug.
Basically, in the twiddle_general_dsp48e block, the slice blocks are
configured in
20 matches
Mail list logo
