12 Jan
2013
12 Jan
'13
4:03 p.m.
I have installed these using the procedures shown in the wiki. I didn’t see
any errors during the installation. The packages are on the computer but
they are not listed amongst the sources on GNU Radio Companion.
If I type in the terminal rtl_test –t I get:
Found 1 device(s):
0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
usb_open error -3
Failed to open rtlsdr device #0
Any suggestions?
Many thanks,
Al
22 Jan
22 Jan
6:24 p.m.
New subject: mingw32
Hi,
Attempts to link librtlsdr and libusb-1.0 with my project
Linrad gives these warning messages:
Warning: .drectve `-aligncomm:"__poll_fd",5 ' unrecognized
Warning: .drectve `-aligncomm:"_poll_fd",5' unrecognized
Warning: .drectve `-aligncomm:"_htab_filled",2 ' unrecognized
Warning: .drectve `-aligncomm:"_htab_size",2 ' unrecognized
Warning: .drectve `-aligncomm:"_timer_tp",2 ' unrecognized
Warning: .drectve `-aligncomm:"_autoclaim_lock",2 ' unrecognized
Warning: .drectve `-aligncomm:"_hires_ticks_to_ps",3 ' unrecognized
Warning: .drectve `-aligncomm:"_hires_frequency",3' unrecognized
I get an executable and it runs OK until to rtlsdr_read_async(....)
is called from a separate thread.
Once async read is running the calls to libusb no longer work OK.
Windows crashes on call to libusb_control_transfer.
By issuing a wait in the thread that calls rtlsdr_read_async
I can assure that no calls will be made to libusb_control_transfer
after async is started.
The call to libusb_handle_events_timeout returns -1 which is
LIBUSB_ERROR_IO about 3 times more often than it returns zero.
By ignoring this error I have a running system, it receives
the antenna signal fine from the dongle.
BUT if I try to change frequency or gain Windows crashes. Also
if I try to exit. It seems one must not call anything
else in libusb-1.0 after having started read.
I have used mingw32, the standard install under Ubuntu.
I was unable to use the configure script but made a simple
script to compile with /usr/bin/i586-mingw32msvc-gcc
and then create the library and install like this:
/usr/bin/i586-mingw32msvc-ar rc librtlsdr.a librtlsdr.o tuner_tuner_fc0013.o
tuner_fc2580.o tuner_r820t.o
/usr/bin/i586-mingw32msvc-ranlib librtlsdr.a
cp librtlsdr.a /usr/i586-mingw32msvc/lib
The libusb-1.0.a file is from the MinGW32 directory
in libusbx-1.0.14-win.7z
What can I do to fix the problem?
Regards
Leif
26 Jan
26 Jan
5:44 a.m.
New subject: mingw32
Leif Asbrink wrote:
Attempts to link librtlsdr and libusb-1.0 with my
project
Please note that libusbx is not libusb. I'm the maintainer of libusb
at libusb.org and libusbx is a fork with some good additions but more
notably an overwhelming amount of questionable practises and changes,
by basically one developer who refuses to work with me. (He banned me
from the libusbx mailing list when I wrote that some of his code
which is both in libusb and libusbx had a bug.)
While I do pay attention to what happens in libusbx I don't know
exactly what the state is of that code. I haven't tested libusbx-1.0.14
in a while, and in particular not on Windows, where libusbx has crazy
changes compared to the original libusb-1.0 from libusb.org. (That's
the platform the main developer works on.)
I know of others who have had strange issues with libusbx-1.0.14,
while the latest libusb.git source code from libusb.org instead
worked as expected.
Please grab the latest code from http://git.libusb.org/libusb.git
and see if it works any better.
BUT if I try to change frequency or gain Windows
crashes. Also
if I try to exit. It seems one must not call anything
else in libusb-1.0 after having started read.
That would be a bug in the implementation. The API design very much
allows mixing sync and async transfers, and it works fine in
libusb-1.0.
I have used mingw32, the standard install under
Ubuntu.
Ok.
I was unable to use the configure script
This is a HUGE alarm bell for me. Especially if you are just starting
out with learning cross-compiling it is critical that you make things
work exactly the way they are supposed to, or you are just setting
yourself up for endless unneccessary trouble.
If you tried to use configure and it did not work then why don't you
show what went wrong?
Please show the configure command that you ran, along with the
complete output that it produced. I assume that there were some
errors in the end, make sure to include those of course, and ideally
also attach the complete config.log file. Feel free to send that in
an email directly to me if the mailing list thinks that the
attachments are too large. Make sure to send the log file as plain
text, ie. either inline in the email, or attached with text/plain
MIME type.
but made a simple script to compile with
/usr/bin/i586-mingw32msvc-gcc
and then create the library and install like this:
/usr/bin/i586-mingw32msvc-ar rc librtlsdr.a librtlsdr.o tuner_tuner_fc0013.o
tuner_fc2580.o tuner_r820t.o
/usr/bin/i586-mingw32msvc-ranlib librtlsdr.a
cp librtlsdr.a /usr/i586-mingw32msvc/lib
It's a bad idea to store librtlsdr in the toolchain lib dir. The
correct approach is to use a so-called prefix directory, which as
it happens is taken caren of automatically by the configure script.
What can I do to fix the problem?
I'm happy to help you sort things out with libusb-1.0, but you'll
have to work with the code from libusb.org.
configuring and building libusb with that ubuntu cross-compiler
should work without any issues..
git clone git://git.libusb.org/libusb.git && \
cd libusb && \
./autogen.sh --host=i586-mingw32msvc --prefix=$(pwd)/../winlibs && \
make install && \
cd .. && \
git clone git://git.osmocom.org/rtl-sdr && \
cd rtl-sdr && \
autoreconf -fi && \
PKG_CONFIG_LIBDIR=$(pwd)/../winlibs/lib/pkgconfig \
./configure --host=i586-mingw32msvc --prefix=$(pwd)/../winlibs && \
make install && \
cd .. && \
ls -l winlibs/bin winlibs/lib
..builds libusb and rtl-sdr using the cross-compiler and installs the
built files into the winlibs/ directory wherever you copypaste the
above commands.
But, I don't know if the rtl-sdr configure.ac works so well for
cross-compiling for Windows. The last time I tried to cross-compile
rtl-sdr for Windows I used cmake, and I had to work around several
issues to make that work.
If you want to focus on the USB communication then you can of course
continue bypassing the build system for rtl-sdr, but if it has
actually been fixed since I tried to cross-compile then you should
really use it.
The libusb that gets built above includes very verbose debug logging,
and will output lots of lines of useful information when you run a
program which uses it. When there are no more bugs to deal with you
will rebuild libusb without that debug logging:
cd libusb && \
./configure --host=i586-mingw32msvc --prefix=../winlibs \
--disable-debug-log && \
make install && \
cd ..
I hope you already see the pattern for how configure works.
If something doesn't work, please send complete information to get a
useful response.
//Peter
2:25 p.m.
New subject: mingw32
Hello Peter,
This may not be the appropriate forum for libusb-1.0 discussions,
but since the library is essential for rtlsdr users I take the
liberty to post my findings here.
I already solved the problems when your posting appeared.
I will try the proper configure commands. That would make
things easier of course.
I am not a programmer. There is a lot of terminology that
I do not understand. I am limited to a small sub-set
of regular C and I am too old to learn big volumes of
new things. My interest is radio and signal processing.
The RTL dongle is a marvellous thing (with the e4k tuner)
and I want to make people aware of how it can be used.
Having to worry about drive routines is frustrating but
necessary for performance reasons.
I have been using simple hand-written Makefiles to
compile and create the libraries. I will try the commands
that you have supplied to see what happens, but first
I will make a new version of Linrad available that will
use rtlsdr properly under Windows.
First of all, the Debian versions of mingw32 are broken. There
are two alternative (mutually excluding) mackages.
The package gcc-mingw32 runs the first step and produces
an assembly file that contains errors causing the second
step to fail. (do not remember what routine)
The package mingw32 does compile but the linker can not
find the entry for vprintf. There are several .a files
containing a reference to it, if should be located
in libmingwex but it is not there.
The mingw package (5.1.6) for Windows works however so I can
compile on an XP platform.
I have tested http://git.libusb.org/libusb.git (today, Jan 26)
As it turns out I have to make a couple of changes to allow
compilation. Those are:
--------------------------- core.c -----------------------------
/* Offset between 1/1/1601 and 1/1/1970 in 100 nanosec units */
// #define _W32_FT_OFFSET (116444736000000000)
// Jan 26 2013 Leif _sbrink SM5BSZ
// mingw32 does not accept this. Integer constant too large.
// define in 100 millisecond units.
// The routine is rewritten in a simple-minded fashion
#define _W32_FT_OFFSET (11644473600.0)
int usbi_gettimeofday(struct timeval *tp, void *tzp)
{
unsigned __int64 *ns100; /*time since 1 Jan 1601 in 100ns units */
FILETIME ft;
ns100=(__int64*)&ft;
if(tp)
{
GetSystemTimeAsFileTime (&ft);
tp->tv_usec=(long)((ns100[0] / 10) % 1000000 );
ns100[0]/=10000000;
ns100[0]-=_W32_FT_OFFSET;
tp->tv_sec= (long)ns100[0];
}
/* Always return 0 as per Open Group Base Specifications Issue 6.
Do not set errno on error. */
return 0;
}
// end of modified code Jan 26 2013
--------------------------------------------------------------------
----------------------- threads_windows.c ----------------------
// Jan 26 2013 Leif _sbrink SM5BSZ Line changed to coply with mingw
// static int __inline usbi_cond_intwait(usbi_cond_t *cond,
static __inline int usbi_cond_intwait(usbi_cond_t *cond,
--------------------------------------------------------------------
The resulting library does not work however. It returns -12
to librtl during the initial setup.
I have also compiled libusb-1.0.9 which needed the same
modifications. The library runs, but behaves as all precompiled
versions available on the Internet. Crashes on a frequency change.
Having the library running from my own source code
allowed tracing the crash that occurs when the frequency
is changed while the callback is running. The culpit
is the call usbi_warn(NULL,.... that is issued when
something belonging to another thread is detected.
I have commented out all such calls and now libusb-1.0.9
runs fine on my Windows machine:-)
I have verified that usbi_warn is ok if a context is supplied.
Regards
Leif
On Sat, 26 Jan 2013 05:44:56 +0100
Peter Stuge <peter(a)stuge.se> wrote:
Leif Asbrink wrote:
Attempts to link librtlsdr and libusb-1.0 with my
project
Please note that libusbx is not libusb. I'm the maintainer of libusb
at libusb.org and libusbx is a fork with some good additions but more
notably an overwhelming amount of questionable practises and changes,
by basically one developer who refuses to work with me. (He banned me
from the libusbx mailing list when I wrote that some of his code
which is both in libusb and libusbx had a bug.)
While I do pay attention to what happens in libusbx I don't know
exactly what the state is of that code. I haven't tested libusbx-1.0.14
in a while, and in particular not on Windows, where libusbx has crazy
changes compared to the original libusb-1.0 from libusb.org. (That's
the platform the main developer works on.)
I know of others who have had strange issues with libusbx-1.0.14,
while the latest libusb.git source code from libusb.org instead
worked as expected.
Please grab the latest code from http://git.libusb.org/libusb.git
and see if it works any better.
BUT if I try to change frequency or gain Windows
crashes. Also
if I try to exit. It seems one must not call anything
else in libusb-1.0 after having started read.
That would be a bug in the implementation. The API design very much
allows mixing sync and async transfers, and it works fine in
libusb-1.0.
I have used mingw32, the standard install under
Ubuntu.
Ok.
I was unable to use the configure script
This is a HUGE alarm bell for me. Especially if you are just starting
out with learning cross-compiling it is critical that you make things
work exactly the way they are supposed to, or you are just setting
yourself up for endless unneccessary trouble.
If you tried to use configure and it did not work then why don't you
show what went wrong?
Please show the configure command that you ran, along with the
complete output that it produced. I assume that there were some
errors in the end, make sure to include those of course, and ideally
also attach the complete config.log file. Feel free to send that in
an email directly to me if the mailing list thinks that the
attachments are too large. Make sure to send the log file as plain
text, ie. either inline in the email, or attached with text/plain
MIME type.
but made a simple script to compile with
/usr/bin/i586-mingw32msvc-gcc
and then create the library and install like this:
/usr/bin/i586-mingw32msvc-ar rc librtlsdr.a librtlsdr.o tuner_tuner_fc0013.o
tuner_fc2580.o tuner_r820t.o
/usr/bin/i586-mingw32msvc-ranlib librtlsdr.a
cp librtlsdr.a /usr/i586-mingw32msvc/lib
It's a bad idea to store librtlsdr in the toolchain lib dir. The
correct approach is to use a so-called prefix directory, which as
it happens is taken caren of automatically by the configure script.
What can I do to fix the problem?
I'm happy to help you sort things out with libusb-1.0, but you'll
have to work with the code from libusb.org.
configuring and building libusb with that ubuntu cross-compiler
should work without any issues..
git clone git://git.libusb.org/libusb.git && \
cd libusb && \
./autogen.sh --host=i586-mingw32msvc --prefix=$(pwd)/../winlibs && \
make install && \
cd .. && \
git clone git://git.osmocom.org/rtl-sdr && \
cd rtl-sdr && \
autoreconf -fi && \
PKG_CONFIG_LIBDIR=$(pwd)/../winlibs/lib/pkgconfig \
./configure --host=i586-mingw32msvc --prefix=$(pwd)/../winlibs && \
make install && \
cd .. && \
ls -l winlibs/bin winlibs/lib
..builds libusb and rtl-sdr using the cross-compiler and installs the
built files into the winlibs/ directory wherever you copypaste the
above commands.
But, I don't know if the rtl-sdr configure.ac works so well for
cross-compiling for Windows. The last time I tried to cross-compile
rtl-sdr for Windows I used cmake, and I had to work around several
issues to make that work.
If you want to focus on the USB communication then you can of course
continue bypassing the build system for rtl-sdr, but if it has
actually been fixed since I tried to cross-compile then you should
really use it.
The libusb that gets built above includes very verbose debug logging,
and will output lots of lines of useful information when you run a
program which uses it. When there are no more bugs to deal with you
will rebuild libusb without that debug logging:
cd libusb && \
./configure --host=i586-mingw32msvc --prefix=../winlibs \
--disable-debug-log && \
make install && \
cd ..
I hope you already see the pattern for how configure works.
If something doesn't work, please send complete information to get a
useful response.
//Peter
4:05 a.m.
New subject: librtlsdr.c suggestions
Hi All,
In case buffer allocation fails there will be a crash.
I suggest something like this in rtlsdr_read_async:
if(_rtlsdr_alloc_async_buffers(dev) < 0)
{
_rtlsdr_free_async_buffers(dev);
return -1;
}
The function _rtlsdr_alloc_async_buffers needs tests for
malloc returning NULL with an appropriate return of an
error code to make the above work.
Immediately below the suggested change it may be a good idea
to introduce a small delay. Without this delay
libusb-1.0 crashes under Windows if the sampling rate is high
and the computer is a bit slow:
for(i = 0; i < dev->xfer_buf_num; ++i) {
#ifdef _WIN32
Sleep(1);
#else
usleep(1000);
#endif
libusb_fill_bulk_transfer(dev->xfer[i],
dev->devh,
0x81,
A little further down one more change is desireable:
/*fprintf(stderr, "handle_events returned: %d\n", r);
if (r == LIBUSB_ERROR_INTERRUPTED || r==-1) /* stray
The error code -1 occurs frequently but the data supplied to
the application callback is perfectly OK. On faster computers
there is never any error, but with a Centrino Duo at 900 kHz
there are 2 or 3 errors (-1) for each proper return in case
small buffers are selected.
Regards
Leif
4116
days inactive
4130
days old
4 comments
3 participants
participants (3)
-
Leif Asbrink -
Peter Stuge -
tokens＠myranch.com