Lamar Owen wrote:
> On Thursday 23 June 2005 14:13, n4hy wrote:
>
>>Make sure that you get the "latest and greatest and needed for DBS_RX"
>>usrp_fpga.rbf
>>from Matt if you get the DBS_RX.
>
>
> What's different in the new fpga stuff for DBS_RX? Hmm, I guess I have to
> recursive diff usrp-0.
It is not. Matt sent the file to me after he sent the DBS_RX for my GPS
and AMSAT-NA
prototype transponder plans needed a platform. He sent the file saying
"Ooops, you need this".
Anyone who has a DBS_RX and does NOT have
usrp_std_clock_on_0.rbf
send me a note and I will send you a buzz bal
On Thursday 23 June 2005 14:13, n4hy wrote:
> Make sure that you get the "latest and greatest and needed for DBS_RX"
> usrp_fpga.rbf
> from Matt if you get the DBS_RX.
What's different in the new fpga stuff for DBS_RX? Hmm, I guess I have to
recursive diff usrp-0.8 against the CVS, assuming the
Make sure that you get the "latest and greatest and needed for DBS_RX"
usrp_fpga.rbf
from Matt if you get the DBS_RX.
Bob
Robert McGwier wrote:
I have not seen this message once on mine.
Bob
Marcus D. Leech wrote:
Matt likely isn't back from his trip to Green Bank yet, but I've
obse
I have not seen this message once on mine.
Bob
Marcus D. Leech wrote:
Matt likely isn't back from his trip to Green Bank yet, but I've observed that
with
the DBS_RX, using dbs_debug, that it complains whenever you go to set a
frequency
that "VCO failed to lock at x" appears.
Since th
Matt likely isn't back from his trip to Green Bank yet, but I've observed that
with
the DBS_RX, using dbs_debug, that it complains whenever you go to set a
frequency
that "VCO failed to lock at x" appears.
Since that particular operation is the only one that seems to get actively
tested f
