Menu
▾
▴
libusb-devel
|
From: jan v. k. <j.v...@gm...> - 2012-07-28 08:27:41
|
Hello I have an sdr application, developed under Linux, that uses the rtl2832 stick as radio. Control data is regularly sent to the device (i.e. to change tuning frequency), while a stream of data is read using bulk transfer. The application works fine under Linux. I cross compile using Mingw64 for windows (W7). When starting the application under windows the initial frequency setting is working well, data is coming from the device, however when I want to change the selected frequency while receiving data (i.e. sending control info), either nothing happens or the application breaks down. Is it possible (for Windows) to do simultaneous reading using bulk transfer from the device, sending control data (i.e. is the problem caused by a program error on my side), or should I stop the bulk transfer, send some command to the device and restart the bulk transfer again (which seems to be doable) any help/suggestion is appreciated -- Jan van Katwijk +31 (0)15 3698980 +31 (0) 628260355 |
|
From: Xiaofan C. <xia...@gm...> - 2012-07-28 09:24:48
|
On Sat, Jul 28, 2012 at 4:27 PM, jan van katwijk <j.v...@gm...> wrote: > Hello > > I have an sdr application, developed under Linux, that uses the rtl2832 > stick as radio. > Control data is regularly sent to the device (i.e. to change tuning > frequency), while a stream of data is read using bulk transfer. > > The application works fine under Linux. I cross compile using Mingw64 for > windows (W7). When starting the application under windows > the initial frequency setting is working well, data is coming from the > device, however when > I want to change the selected frequency while receiving data (i.e. sending > control info), either nothing happens or the application breaks down. > > Is it possible (for Windows) to do simultaneous reading using bulk transfer > from the device, sending control data (i.e. is the problem > caused by a program error on my side), or should I stop the bulk transfer, > send some command to the device and restart > the bulk transfer again (which seems to be doable) > > any help/suggestion is appreciated Your report is rather vague. What version of libusb are you using? What is the error message? Could you post the code snippets which cause the problem? -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2012-07-28 13:41:36
|
Please reply to the list. Thanks.
On Sat, Jul 28, 2012 at 6:53 PM, jan van katwijk <j.v...@gm...> wrote:
> Thanx
>
> The problem is that there is no error message, often just hanging of the
> whole system.
>
> The libusb-1.-9 version I am using has as its last entry in the changelog
> april 20.
>
> The main issue was whether behaviour under windows wrt simultaneously
> receiving data using bulk transfer
> (asynchronous API) while sending control bits, should be expected the same
> as under Linux.
> If so, I should instrument the code and see where I made an error, if
> behaviour can be different I should
> find a different programmatic solution.
>
> In detail: I have a Qthread for handling the asynchronous libusb interface
> (i.e. catching the events), this thread
> continues to deliver data on the required speed. It seems pretty standard
> code, based on some examples
> I found on the net and on the code in the osmocom library for the rtl, but
> then adapted for use with Qt
>
> void RTL2832U::run (void) {
> int32_t i;
> struct timeval tv = {1, 0};
>
> rtl_is_running = true;
> while (rtl_should_run) {
> while (TheDevice -> async_status == RTLSDR_INACTIVE)
> msleep (1);
>
> // fprintf (stderr, "off we go\n");
> if (!resetBuffer ())
> fprintf (stderr, "failed to reset\n");
> //
> // could have been done on init
> for (i = 0; i < (int)(TheDevice -> xfer_buf_num); i ++) {
> libusb_fill_bulk_transfer (TheDevice -> xfer [i],
> TheDevice -> devh,
> 0x81,
> TheDevice -> xfer_buf [i],
> TheDevice -> xfer_buf_len,
> _libusb_callback,
> (void *)TheDevice,
> BULK_TIMEOUT);
> libusb_submit_transfer (TheDevice -> xfer [i]);
> }
> while (TheDevice -> async_status != RTLSDR_INACTIVE) {
> libusb_handle_events_timeout (TheDevice -> ctx, &tv);
>
> if (TheDevice -> async_status == RTLSDR_CANCELING) {
> TheDevice -> async_status = RTLSDR_INACTIVE;
>
> if (TheDevice ->xfer == NULL)
> break;
>
> for (i = 0; i < (int)(TheDevice -> xfer_buf_num); i ++) {
> if (TheDevice -> xfer [i] == NULL)
> continue;
>
> if (TheDevice -> xfer [i] -> status ==
> LIBUSB_TRANSFER_COMPLETED) {
> libusb_cancel_transfer (TheDevice -> xfer [i]);
> TheDevice -> async_status = RTLSDR_CANCELING;
> }
> }
>
> }
> }
> }
>
>
> Another thread (the main thread in the Qt application) calls on the libusb
> interface for setting and reading control data
> all using constructs like
> r = libusb_control_transfer (TheDevice -> devh, CTRL_IN, 0, addr,
> index, array,
> len, CTRL_TIMEOUT);
>
> I do have another radio through the usb gate connected, and control works
> fine. The problem starts
> as said above when sending control messages while the bulk transfers are on,
> but again, only
> windows. No problem whatsoever in Linux (Fedora 17 64 bits, fedora 16 64
> bits, ubuntu 12.04 64 bits).
>
> If behaviour SHOULD be exactly the same under windows and linux, then
> apparently I am making some programming
> error, which can be as simple as an unitialized variable. Then I need to set
> up a debugging environment for
> use with Mingw64 and reinspect all elements of my code.
>
> anyway, thanx so far
You may want to use libusb.git since libusb-1.0.9 has serious bugs
under Windows. Or you can use libusbx-1.0.12.
http://git.libusb.org/?p=libusb.git
http://libusbx.org/
--
Xiaofan
|
|
From: jan v. k. <j.v...@gm...> - 2012-07-28 17:44:43
|
Installing libusbx-1.012 seems to solve the problem.
Thanx for the excellent work in developing interfaces for true portability.
all the best
jan
2012/7/28 Xiaofan Chen <xia...@gm...>
> Please reply to the list. Thanks.
>
> On Sat, Jul 28, 2012 at 6:53 PM, jan van katwijk <j.v...@gm...>
> wrote:
> > Thanx
> >
> > The problem is that there is no error message, often just hanging of the
> > whole system.
> >
> > The libusb-1.-9 version I am using has as its last entry in the changelog
> > april 20.
> >
> > The main issue was whether behaviour under windows wrt simultaneously
> > receiving data using bulk transfer
> > (asynchronous API) while sending control bits, should be expected the
> same
> > as under Linux.
> > If so, I should instrument the code and see where I made an error, if
> > behaviour can be different I should
> > find a different programmatic solution.
> >
> > In detail: I have a Qthread for handling the asynchronous libusb
> interface
> > (i.e. catching the events), this thread
> > continues to deliver data on the required speed. It seems pretty standard
> > code, based on some examples
> > I found on the net and on the code in the osmocom library for the rtl,
> but
> > then adapted for use with Qt
> >
> > void RTL2832U::run (void) {
> > int32_t i;
> > struct timeval tv = {1, 0};
> >
> > rtl_is_running = true;
> > while (rtl_should_run) {
> > while (TheDevice -> async_status == RTLSDR_INACTIVE)
> > msleep (1);
> >
> > // fprintf (stderr, "off we go\n");
> > if (!resetBuffer ())
> > fprintf (stderr, "failed to reset\n");
> > //
> > // could have been done on init
> > for (i = 0; i < (int)(TheDevice -> xfer_buf_num); i ++) {
> > libusb_fill_bulk_transfer (TheDevice -> xfer [i],
> > TheDevice -> devh,
> > 0x81,
> > TheDevice -> xfer_buf [i],
> > TheDevice -> xfer_buf_len,
> > _libusb_callback,
> > (void *)TheDevice,
> > BULK_TIMEOUT);
> > libusb_submit_transfer (TheDevice -> xfer [i]);
> > }
> > while (TheDevice -> async_status != RTLSDR_INACTIVE) {
> > libusb_handle_events_timeout (TheDevice -> ctx, &tv);
> >
> > if (TheDevice -> async_status == RTLSDR_CANCELING) {
> > TheDevice -> async_status = RTLSDR_INACTIVE;
> >
> > if (TheDevice ->xfer == NULL)
> > break;
> >
> > for (i = 0; i < (int)(TheDevice -> xfer_buf_num); i ++)
> {
> > if (TheDevice -> xfer [i] == NULL)
> > continue;
> >
> > if (TheDevice -> xfer [i] -> status ==
> > LIBUSB_TRANSFER_COMPLETED) {
> > libusb_cancel_transfer (TheDevice -> xfer [i]);
> > TheDevice -> async_status = RTLSDR_CANCELING;
> > }
> > }
> >
> > }
> > }
> > }
> >
> >
> > Another thread (the main thread in the Qt application) calls on the
> libusb
> > interface for setting and reading control data
> > all using constructs like
> > r = libusb_control_transfer (TheDevice -> devh, CTRL_IN, 0,
> addr,
> > index, array,
> > len, CTRL_TIMEOUT);
> >
> > I do have another radio through the usb gate connected, and control works
> > fine. The problem starts
> > as said above when sending control messages while the bulk transfers are
> on,
> > but again, only
> > windows. No problem whatsoever in Linux (Fedora 17 64 bits, fedora 16 64
> > bits, ubuntu 12.04 64 bits).
> >
> > If behaviour SHOULD be exactly the same under windows and linux, then
> > apparently I am making some programming
> > error, which can be as simple as an unitialized variable. Then I need to
> set
> > up a debugging environment for
> > use with Mingw64 and reinspect all elements of my code.
> >
> > anyway, thanx so far
>
> You may want to use libusb.git since libusb-1.0.9 has serious bugs
> under Windows. Or you can use libusbx-1.0.12.
> http://git.libusb.org/?p=libusb.git
> http://libusbx.org/
>
> --
> Xiaofan
>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
From: Xiaofan C. <xia...@gm...> - 2012-07-28 23:41:11
|
On Sun, Jul 29, 2012 at 1:44 AM, jan van katwijk <j.v...@gm...> wrote: > Installing libusbx-1.012 seems to solve the problem. > Thanx for the excellent work in developing interfaces for true portability. > all the best Thanks for the report. Now probably is the time for Peter to release libusb-1.0.10 to address the serious Windows backend bug which has already been fixed quite some time ago in libusbx release. -- Xiaofan |
Thanks for helping keep SourceForge clean.
X