Bitcraze Forums

Posted: **Tue Feb 25, 2020 6:42 pm**

Basically if I start with PRX, switch to PTX and send a message and then switch back to PRX I get a "sending control message failed error" if I didn't receive any messages in PRX mode. If I do receive messages it works fine. (firmware compiled from the github code, though I did that a year or so ago)

I have tried to reduce it to the necessary components to get the error:

Code: Select all

radio = Crazyradio()
radio.set_mode(Crazyradio.MODE_PRX)

a=radio.receive(50)
time.sleep(0.5)
radio.set_mode(Crazyradio.MODE_PTX)
header = ((10 & 0x0f) << 4 | 3 << 2 |
					   (0 & 0x03))
res = radio.send_packet(struct.pack('<BBB', #sets expected format
	header,
	1,
	1),False)
time.sleep(0.5)
radio.set_mode(Crazyradio.MODE_PRX)

radio.close()

error:

Code: Select all

Traceback (most recent call last):
  File "normalmode.py", line 20, in <module>
    radio.set_mode(Crazyradio.MODE_PRX)
  File "./lib\crazyradio.py", line 231, in set_mode
    _send_vendor_setup(self.handle, SET_MODE, mode, 0, ())
  File "./lib\crazyradio.py", line 323, in _send_vendor_setup
    wIndex=index, timeout=1000, data_or_wLength=data)
  File "C:\Users\Bernd\AppData\Local\Programs\Python\Python35\lib\site-packages\usb\core.py", line 1043, in ctrl_transfer
    self.__get_timeout(timeout))
  File "C:\Users\Bernd\AppData\Local\Programs\Python\Python35\lib\site-packages\usb\backend\libusb0.py", line 593, in ctrl_transfer
    timeout
  File "C:\Users\Bernd\AppData\Local\Programs\Python\Python35\lib\site-packages\usb\backend\libusb0.py", line 431, in _check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] b'libusb0-dll:err [control_msg] sending control message failed, win error: Der E/A-Vorgang wurde wegen eines Threadendes oder einer Anwendungsanforderung abgebrochen.\r\n\n'

Am I doing something wrong?

Posted: **Mon Mar 02, 2020 2:53 pm**

Hi!

It is a bit difficult for us to see what the problem is. The error message is in german but the problem seems to be in libusb.

1- Are you sure you have rights to the USB device?
2- Have you installed the driver for windows according: https://www.bitcraze.io/docs/crazyradio ... sbwindows/ ?

Posted: **Thu Mar 05, 2020 4:33 pm**

Ah didn't think of the german part at the end it means "The I / O operation was canceled due to an end of thread or an application request. " And yeah have tried both drivers suggested.

I should probably go into more detail what I am trying to do. I mostly want to listen to peer to peer communication between crazyflie and log them, but I also need to send a few control messages at the beginning and the end. Only broadcasts no acks. It works in general I can send messages when I start with PTX, I can receive the messages in PRX. And I can interrupt that to send some more control messages (though I am not sure whether it actually properly switches back to PTX or just sends them as ack payloads or something). But if I am receiving no messages from the CF and switch from PRX to PTX send a message and try switching back to PRX it tends to end in the error mentioned and I have to reconnect the radio.

I am using this https://github.com/bitcraze/crazyradio- ... zyradio.py with 2 changes I added this

Code: Select all

    def set_ack_enable(self, enable):
        """ Set the radio datarate to be used """
        _send_vendor_setup(self.handle, ACK_ENABLE, enable, 0, ())

Which if I am understandig stuff correctly should allow setting it so that in PRX mode it doesn't wait for an ack (I am only sending and receiving broadcasts) and modified the send command accordingly to not fetch an ack

Code: Select all

 def send_packet(self, dataOut,ack=True):
        """ Send a packet and receive the ack from the radio dongle
            The ack contains information about the packet transmition
            and a data payload if the ack packet contained any """
        ackIn = None
        data = None
        try:
            if (pyusb1 is False):
                self.handle.bulkWrite(1, dataOut, 1000)
                if(ack):
                    data = self.handle.bulkRead(0x81, 64, 1000)

            else:
                self.handle.write(endpoint=1, data=dataOut, timeout=1000)
                if(ack):
                    data = self.handle.read(0x81, 64, timeout=1000)
                
        except usb.USBError:
            pass

        if data is not None:
            ackIn = _radio_ack()
            if data[0] != 0:
                ackIn.ack = (data[0] & 0x01) != 0
                ackIn.powerDet = (data[0] & 0x02) != 0
                ackIn.retry = data[0] >> 4
                ackIn.data = data[1:]
            else:
                ackIn.retry = self.arc

        return ackIn

Hmm looking at the firmware the description for cmd_run "/* Command mode, the bulk usb packets contains both data and configuration in a
* command string. The host can, and should, run TX and RX in different threads.
*/" sounds like maybe I should be using it instead but I have trouble finding documentation for it?

Posted: **Fri Mar 06, 2020 9:55 am**

Ahh oke, so to be exact, you want to make a radio 'sniffer' that receives all the packages that are on the same channel as the peer to peer on the crazyflies?

In general that would be difficult to do on the crazyradio since that is based on another nrf chip (see this old forumpost about that: viewtopic.php?f=11&t=2662&p=13553&hilit ... dio#p13553). But if you have maybe an BBC microbit lying around, you can turn that very easily to a sniffer with https://bitbucket.org/bitcraze/ebl_sniffer to read out the peer to peer messages, since that has exactly the same nrf chip as the crazyflie. If you change the datarate and channel in the main.c, and you can than get the messages through picocom /dev/ttyACM1 -b 460800

If this doesn't work out for you, than we probably would have to look into it further, since we never got the sniffer to work on the crazyradio before.

Posted: **Tue Mar 10, 2020 3:31 pm**

It works fine as a sniffer for me actually (though I use my own peer to peer implementation since the nrf firmware changes weren't out when I started with it so the package size is limited to what the crazyradio can handle and it uses timeslot to avoid collisions).

If crazyflie are turned on I can broadcast a message from the pc to make them start communicating, log the messages between them, then broadcast a message to make them start flying and at the end broadcast to make them stop. Their p2p communication is successfully logged during this. This works for me.

The error that bothers me is only in a specific scenario. Basically doing the same as above leads to trouble if all crazyflie are turned off. When I do the above and the crazyflie are off and the pc has started to listen but then I temporarily try switching to sending, the radio crashes if I switch back to listening. And then only reinserting the radio helps.
(The code I posted is basically the minimum to cause the error since my normal code is a bit long.)

But I suppose I could just use two antennas and separate listening and sending. Or just avoid causing it, now that I know when it happens, it isn't hard to avoid.

Posted: **Thu Mar 12, 2020 9:44 am**

This sounds very much as a FW issue in the Crazyradio, probably some state issue or similar. Can't find anything obvious in the code but then I'm not so experienced with it. I got a feeling it is related to USB handling, but that is just a feeling. To bad the nRF24LU1 is so hard to debug. Could you post your initial post as a issue on github in the crazyradio-firmware repo?

Bitcraze Forums

Switching between PRX and PTX trouble when not receiving messages

Switching between PRX and PTX trouble when not receiving messages

Re: Switching between PRX and PTX trouble when not receiving messages

Re: Switching between PRX and PTX trouble when not receiving messages

Re: Switching between PRX and PTX trouble when not receiving messages

Re: Switching between PRX and PTX trouble when not receiving messages

Re: Switching between PRX and PTX trouble when not receiving messages