usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsUHD problems under WinXP
Hello,
I am currently developing a receiver application using USRP1+WBX and
UHD. This application should run under
Linux and Windows. I am using UHD version 003.000.001 for both Linux and
Windows.
I tested my program under Ubuntu Lucid without problems but under
Windows XP I still have 2 problems.
My application starts receiving samples from USRP this way:
buff = boost::shared_array<float>(new float[ 2 * blockSize ]);
sdev->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
while (condition)
counter = dev->recv(buff.get(), blockSize, md,
uhd::io_type_t::COMPLEX_FLOAT32, uhd::device::RECV_MODE_ONE_PACKET);
sdev->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
I need to be able to start, stop and restart IQ sampling and this works
properly under Ubuntu Lucid.
Under Windows XP (compiled using VC2010), I can start and stop the
receiver, but when I restart it I get this message:
Error (recv): recv buffer smaller than vrt packet offset
printed on the console just after the recv function is called. The
rx_metadata_t struct (called md in my code) has ERROR_CODE_BAD_PACKET
in the error_code field. I checked the allocated buffer (buff), and it
is properly allocated and the application can read/write it.
Does someone have any idea what is causing this problem?
I also have another problem, related to the path of the USRP image
files. I manually set in the Path environment variable the path to the
uhd.dll file and fpga image files in the UHD directory but I always get
this error message:
Creating the usrp device with: ...
Warning:
Could not locate USRP1 firmware.
Please install the images package.
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
while if I copy the image files in the working directory, everything is
fine. I get the same error even if I run the examples .exe files in UHD
distribution.
Thanks for the help,
Stefano Speretta
--
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands
Phone: +31(0)15 256 9018
Fax: +31(0)15 257 3969
E-mail: s.speretta@isispace.nl
Web: www.isispace.nl
I also have another problem, related to the path of the USRP image
files. I manually set in the Path environment variable the path to the
uhd.dll file and fpga image files in the UHD directory but I always get
this error message:
Creating the usrp device with: ...
Warning:
Could not locate USRP1 firmware.
Please install the images package.
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
while if I copy the image files in the working directory, everything is
fine. I get the same error even if I run the examples .exe files in UHD
distribution.
When the install path is something other than c:/program files
(x86)/uhd, the UHD_IMAGE_PATH needs to be set.
http://www.ettus.com/uhd_docs/manual/html/images.html#archive-install
Future installers will set this automatically, and have an option to
append to the system %PATH%
-Josh
I need to be able to start, stop and restart IQ sampling and this works
properly under Ubuntu Lucid.
Under Windows XP (compiled using VC2010), I can start and stop the
receiver, but when I restart it I get this message:
Error (recv): recv buffer smaller than vrt packet offset
printed on the console just after the recv function is called. The
rx_metadata_t struct (called md in my code) has ERROR_CODE_BAD_PACKET
in the error_code field. I checked the allocated buffer (buff), and it
is properly allocated and the application can read/write it.
Does someone have any idea what is causing this problem?
Thats interesting. I guess this highlights little differences between
libusb over linux/windows. Since there is not real VRT packet on USRP1,
I think this is a case of an empty bulk transfer.
I have a few suggestions:
- After stopping streaming, flush any queued up buffers by calling
recv() exhaustively. (this may flush out the bad packet)
or *) After getting the bad packet, can you continue to receive normally?
-Josh
Thanks, now the examples work OK under winXP.
Regards,
Stefano Speretta
On 4/22/2011 5:58 PM, Josh Blum wrote:
I also have another problem, related to the path of the USRP image
files. I manually set in the Path environment variable the path to the
uhd.dll file and fpga image files in the UHD directory but I always get
this error message:
Creating the usrp device with: ...
Warning:
Could not locate USRP1 firmware.
Please install the images package.
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
while if I copy the image files in the working directory, everything is
fine. I get the same error even if I run the examples .exe files in UHD
distribution.
When the install path is something other than c:/program files
(x86)/uhd, the UHD_IMAGE_PATH needs to be set.
http://www.ettus.com/uhd_docs/manual/html/images.html#archive-install
Future installers will set this automatically, and have an option to
append to the system %PATH%
-Josh
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands
Phone: +31(0)15 256 9018
Fax: +31(0)15 257 3969
E-mail: s.speretta@isispace.nl
Web: www.isispace.nl
Thats interesting. I guess this highlights little differences between
libusb over linux/windows. Since there is not real VRT packet on USRP1,
I think this is a case of an empty bulk transfer.
I have a few suggestions:
- After stopping streaming, flush any queued up buffers by calling
recv() exhaustively. (this may flush out the bad packet)
or *) After getting the bad packet, can you continue to receive normally?
When I am stopping the receiver I am issuing these commands:
sdev->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
while(counter = dev->recv(buff.get(), blockSize, md,
uhd::io_type_t::COMPLEX_FLOAT32, uhd::device::RECV_MODE_ONE_PACKET))
{
/* NOP */
};
to flush eventual packets left in the queue. Anyway, every time I call
recv after stopping the streaming
I get ERROR_CODE_TIMEOUT and no further packet is fetched under both
windows and Linux.
If I keep instead calling recv after the first error I always get
ERROR_CODE_BAD_PACKET.
The only way to receive again data is to close the application and
restart it.
If needed I can recompile UHD with some debug cout, but I would need
some hints about where to put them and what to print.
Regards,
Stefano Speretta
--
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands
Phone: +31(0)15 256 9018
Fax: +31(0)15 257 3969
E-mail: s.speretta@isispace.nl
Web: www.isispace.nl
When I am stopping the receiver I am issuing these commands:
sdev->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
while(counter = dev->recv(buff.get(), blockSize, md,
uhd::io_type_t::COMPLEX_FLOAT32, uhd::device::RECV_MODE_ONE_PACKET))
{
/* NOP */
};
to flush eventual packets left in the queue. Anyway, every time I call
recv after stopping the streaming
I get ERROR_CODE_TIMEOUT and no further packet is fetched under both
windows and Linux.
Ok, that is the correct behavior. A call to receive after all data is
flushed should return 0 and have md.error_code == ERROR_CODE_TIMEOUT
If I keep instead calling recv after the first error I always get
ERROR_CODE_BAD_PACKET.
This behaviour is unexpected. I will try to replicate it on a win7
machine. I suspect it to be a zero length or timed-out libusb LUT.
The only way to receive again data is to close the application and
restart it.
So, in the same application, if you call start streaming again, and then
recv(), data will not be produced?
sdev->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
Thanks,
-Josh
So, in the same application, if you call start streaming again, and then
recv(), data will not be produced?
sdev->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
Yes, exactly.
Regards,
Stefano Speretta
--
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands
Phone: +31(0)15 256 9018
Fax: +31(0)15 257 3969
E-mail: s.speretta@isispace.nl
Web: www.isispace.nl
Actually after some testing I managed to understand the problem. I am
posting the solution in
case somebody ends up in the same situation.
My software war running the data reception in a separate thread, which
was terminated
after stopping the receiver; when the receiver was then started again
the thread was restarted.
But as specified here
http://www.ettus.com/uhd_docs/manual/html/general.html#thread-safety-notes
the fast loop should run inside the same thread context.
My software was running fine under linux but not under Windows (XP and
7). After putting everything
under the same thread, the software runs without problems under linux
and windows (both XP and 7).
Regards
Stefano Speretta
--
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands
Phone: +31(0)15 256 9018
Fax: +31(0)15 257 3969
E-mail: s.speretta@isispace.nl
Web: www.isispace.nl
I have an N210 with WBX boards (4 actually and they behave the same). With a 50ohm terminator on the RX2 input I am getting a spike at my center frequency. That is, I call:
set_rx_freq(347500000)
set_rx_rate(10000000)
I have an strong PSD line at 350MHZ which moves as I change the rx_freq value. I'm assuming that it's picking up the local oscillator. By strong, I mean that the it is 10's of db's higher than the noise floor and the raw values coming out of the box are around 70 with the gain set to 32 and around 20 with the gain set to 0.
Should there be that much leakage?
Matt Singer
On 05/12/2011 07:53 AM, Matthew Singer wrote:
I have an N210 with WBX boards (4 actually and they behave the same).
With a 50ohm terminator on the RX2 input I am getting a spike at my
center frequency. That is, I call:
set_rx_freq(347500000) set_rx_rate(10000000)
I have an strong PSD line at 350MHZ which moves as I change the
rx_freq value. I'm assuming that it's picking up the local
oscillator. By strong, I mean that the it is 10's of db's higher than
the noise floor and the raw values coming out of the box are around
70 with the gain set to 32 and around 20 with the gain set to 0.
Should there be that much leakage?
There are 2 things to consider here:
-- First, what is the actual effective power you are seeing?
You didn't use a calibrated power reference, so I will estimate. The
thermal noise floor is about -174 dBm/Hz. The N210+WBX has a noise
figure around 4 dB, so the noise floor is -170 dBm/Hz. You have a 10
MHz bandwidth, but you didn't say how many bins are in your FFT. I will
assume the default of 1024, which gives you roughly 10 kHz per bin. 10
kHz is 40 dB-Hz, and -170 dBm/Hz + 40 dB-Hz = -130 dBm of noise per bin.
Saying it is "tens" of dB worse is ambiguous, but let's say it is 30 dB.
That would give you an effective feedthrough of -100 dBm, which is
actually quite good -- remember that the LO is on the same board at a
level of +5 dBm, so the isolation would be around 105 dBc.
-- Second, what you are seeing is more likely to be a digital artifact
which has been discussed before. If you add 0.5 + 0.5i to your signal
it would likely disappear. We are working on integrating that into the
FPGA right now.
Matt