windows vs linux behaviour: question

[jan van katwijk]

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


[phone]
[phone]

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Sat, Jul 28, 2012 at 4:27 PM, jan van katwijk <[hidden email]> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

Please reply to the list. Thanks.

On Sat, Jul 28, 2012 at 6:53 PM, jan van katwijk <[hidden email]> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[jan van katwijk]

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 <[hidden email]>

Please reply to the list. Thanks.

On Sat, Jul 28, 2012 at 6:53 PM, jan van katwijk <[hidden email]> 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


[phone]
[phone]

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Sun, Jul 29, 2012 at 1:44 AM, jan van katwijk <[hidden email]> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel