Okay, thank you.
Although I don't understand how this could be the case, as the only other
images I could have had on that particular PC were ones retrieved by UHD
release 3.10. (So they would have been *older*, not newer.)
Buut in the future I'll make sure to double check the compabilities.
On
Hello,
Yes, that is the purpose of the set_time_next_pps function. When combined
with common 10 MHz and 1 PPS references this allows for stable time
synchronization of 1 sample clock cycle, 5 ns at 200 MS/s. I recommend
reading through the examples which show using all these commands and others
re
We built an FPGA version off of the radio_block, re-using the registers as:
SR_BASE = 160
SR_DB_GPIO= SR_BASE + 8’d32 = 192
SR_THRESHOLD =SR_BASE + 8'd40;
...etc
RB_MISC_IO = RB_BASE + 0;
RB_SPI = RB_BASE + 1;
RB_LEDS = RB_BASE + 2;
..etc
But now I'm having a real to
Sam,
Sorry I haven't gotten back -- it sounds like you're doing everything
right. The usual quick fixes probably don't apply here. I haven't had time
to look more in depth into it, or to try to replicate it on my own hardware.
Marcus is right -- the E3xx uses an idle image in order to reduce powe
Hey Nick
Thanks for taking some time to help with this. Our CPU is an AMD Ryzen 7
1700X Eight-Core Processor. I tried UHD 3.9-LTS and I get some interesting
results. I got much more lates on TX and nothing looked correct on the
scope until I used a minimum of 50ms delay in the future. The UHD
appl
You're going to have to ask a better question than that. Please provide the
following:
* What you are trying to accomplish
* What hardware you are using
* What UHD and Gnuradio version you are using
* The approach you followed
* The result you expected
* The result you actually got
* A flowgraph w
And I was able to solve my own problem after I got over the fear of
bricking. :)
Yes, sr_write writes, while user_reg_read reads, and the offset is totally
dependent upon the FPGA implementation. (Noted for future people searching).
On Fri, Mar 9, 2018 at 8:55 AM, Taliver Heath wrote:
> We buil
Hey Nick,
No prob blew at all. The flag “no_reload_fpga” seems to work for that. The
bigger problem is that each time the fpga image is loaded on the e3xx, the
relative path delays between the RXA and RXB channels changes randomly as seen
by the sample group jumps in the image I originally atta
One thing that struck me: I don't think you should have to disable the
streamer to switch between cal and radio channels. Just for experiment's
sake, try leaving both channels active in the streamer. You can pull
samples from both channels in your recv() command, and just use the channel
you're int
Thanks for the reply and sorry for not providing much information. My case
is that I want to do a relay transmission with the setup: USRP 1 transmits
--> USRP 2 receives and retransmits with a shifted fc --> USRP 3 receives.
The problem is in USRP 2, as you pointed out in your post. I'm testing on
Are you using a custom FPGA image? What happens if you just omit the DMA
FIFO?
Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600
is a good start.
Nick
On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen
wrote:
> Thanks for the reply and sorry for not providing much information.
Hi
Here is the situation of my Octoclock-G.
When I connect the power cable to it, four LEDs of "INTERNAL", "EXTERNAL",
"STATUS" and "POWER" lit for about 5 seconds and then only "POWER" remains
on , others become off. It seems there is nothing in operation, because I
can't feel it vibrating when I
Thanks. After setting spp=600 and omit the DMA FIFO, it doesn't raise the
errors anymore and I can run the flowgraph without having to power cycle. I
think that is because the flow doesn't go through the host anymore. But
it's weird that after stopping the flowgraph the RX and TX lights are still
o
Hi Nick,
I can try this, but the reason I disable one or the other streamer is so that I
can sample at the full 50MHz. Running both streamers cuts the sample rate in
half and I am only using the cal channel to measure/correct the random LO phase
offset.
In this switching mode, the data always
Hello,
I have had this issue and may be able to help. I believe that is because the rx
packet headers need to be modified before the radio will transmit them. I would
suggest looking at the siggen block and making a new ‘relay’ noc block between
the rx and tx in the fpga that modifies headers a
The lights are on because the device isn't instructed to stop streaming on
program stop, and it will continue loopback operation after the host has
closed the program. You can manually issue a stream command to stop the
stream before program stop if you want to change this behavior.
Kei, why would
On 03/09/2018 03:23 AM, Derek Kozel via USRP-users wrote:
Hello,
Yes, that is the purpose of the set_time_next_pps function. When
combined with common 10 MHz and 1 PPS references this allows for
stable time synchronization of 1 sample clock cycle, 5 ns at 200 MS/s.
I recommend reading through
Sorry I mean the lights were on when I closed the program.
Thanks Sam for the suggestion I will try to take a look into it.
On Fri, Mar 9, 2018 at 2:02 PM, Nick Foster wrote:
> The lights are on because the device isn't instructed to stop streaming on
> program stop, and it will continue loopbac
On 03/09/2018 01:22 PM, Nick Foster wrote:
One thing that struck me: I don't think you should have to disable the
streamer to switch between cal and radio channels. Just for
experiment's sake, try leaving both channels active in the streamer.
You can pull samples from both channels in your recv
If the lights are on, the device is streaming, guaranteed. At this point,
make sure your frequencies, gains, and antenna selections are correct.
Nick
On Fri, Mar 9, 2018 at 11:19 AM Kei Nguyen
wrote:
> Sorry I mean the lights were on when I closed the program.
> Thanks Sam for the suggestion I
Hello,
I am using the USRP2/N-Series and trying to receive a simply signal with
Gnuradio.
I have this error but I don't know how to resolve it.
::
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609;
Boost_105800; UHD_3.11.0.0-0-g13c32cef
[32;1m[INFO] [USRP2] [39;0mOpening a US
Dear Sailor Jerry,
I'm not sure I'm following here: The 10 MHz connector is hardware-wise
connected only to inputs, not to anything that can output anything;
compare the schematic[1] on page 1. So, I'm pretty certain your device
can't be condigured to have the 10 MHz connector be an output for
any
HI Marcus, I see your point and also saw the schematic. The previous owner
told me that this particular board was modified to have 10 MHz be brought
out to the outside connector. I did verify it with the scope and indeed saw
the 10 MHz coming out. I don't know if it's one of the standard factory
op
On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
HI Marcus, I see your point and also saw the schematic. The previous
owner told me that this particular board was modified to have 10 MHz
be brought out to the outside connector. I did verify it with the
scope and indeed saw the 10 MHz
It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1 and
3? Remove it, and you'll return the B210 to factory standard.
Assuming no other modifications have also been made. =)
Nick
On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrot
On 03/09/2018 08:11 PM, Nick Foster wrote:
It's a slick mod though. See the zero-ohm resistor bridging U103 pins
1 and 3? Remove it, and you'll return the B210 to factory standard.
Assuming no other modifications have also been made. =)
Nick
Your eyes are much better than mine
On Fri,
Would be happy to restore it to original condition :-)
I'm using the uhd_rx_cfile to capture the data. How do I control U103 from
this app? I don't see any command line arguments for that? Do I need to
rebuild it?
On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
usrp-users@lists.
On 03/09/2018 11:25 PM, Sailor Jerry wrote:
Would be happy to restore it to original condition :-)
I'm using the uhd_rx_cfile to capture the data. How do I control U103
from this app? I don't see any command line arguments for that? Do I
need to rebuild it?
You'd have to add that, inserting a
Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The B200
and B210 cannot support an external 10 MHz reference if a GPSDO is already
present on the motherboard. If an external 10 MHz is to be used, the GPSDO
needs to be physically removed from the device beforehand."?
On Fri, Ma
On 03/09/2018 11:44 PM, Sailor Jerry wrote:
Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
B200 and B210 cannot support an external 10 MHz reference if a GPSDO
is already present on the motherboard. If an external 10 MHz is to be
used, the GPSDO needs to be physically re
That sort of defeats the purpose of U103, doesn't it?
On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech wrote:
> On 03/09/2018 11:44 PM, Sailor Jerry wrote:
>
> Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
> B200 and B210 cannot support an external 10 MHz reference if a GP
I uh what? I don't see why that would be the case. The whole reason U103
exists is to switch between a GPSDO (if present) and an external reference.
You might wait for the official Ettus response for this if you don't want
to take responsibility for blowing it up, but I drew the schematic and I
sa
That would explain it , thanks :-)
On Fri, Mar 9, 2018 at 9:07 PM Nick Foster wrote:
> I uh what? I don't see why that would be the case. The whole reason U103
> exists is to switch between a GPSDO (if present) and an external reference.
>
> You might wait for the official Ettus response for thi
Guys, thank you so much for your support, you are awesome!
Now I feel myself as complete idiot. I removed GPSDO. Disconnected the
10MHz clock, by USRP is still working and it seems to be on more or less
correct correct frequency. I clearly can see the input tone on fft utility.
Is there some othe
Without an external reference, the onboard 40MHz VCTCXO will handle
creating a decent reference without the benefit of the PLL locking it to a
10MHz reference. Wouldn't be much use otherwise.
On Fri, Mar 9, 2018, 9:46 PM Sailor Jerry
wrote:
> Guys, thank you so much for your support, you are awe
Thanks a lot Nick, is there way to find out if the PLL is locked or not?
Can it be done via SW or I need to probe MUXOUT of U101. What should I see
there?
The reason I need to know it, I want to make sure I'm locked to external 10
MHz. Now for some reasons I see the input tone few tens of KHz off
On 03/10/2018 12:59 AM, Sailor Jerry wrote:
Thanks a lot Nick, is there way to find out if the PLL is locked or
not? Can it be done via SW or I need to probe MUXOUT of U101. What
should I see there?
The reason I need to know it, I want to make sure I'm locked to
external 10 MHz. Now for some
Awesome, thanks a lot!
On Fri, Mar 9, 2018 at 10:46 PM Marcus D. Leech wrote:
> On 03/10/2018 12:59 AM, Sailor Jerry wrote:
>
> Thanks a lot Nick, is there way to find out if the PLL is locked or not?
> Can it be done via SW or I need to probe MUXOUT of U101. What should I see
> there?
>
> The r
Hi
The problem of my last e-mail "Problem of Octoclock" has been solved.
That is, I can see my Octoclock-G using "uhd_find_devices" and
"uhd_usrp_probe".
I follow the instructions as the link to update EEPROM.
https://files.ettus.com/manual/page_octoclock.html
Then I run "uhd_usrp_probe" again, a
39 matches
Mail list logo
