Software example for USB communication with a PC

[Alessio]

Hi,

looking for some examples I found this ticket but links inside seem not working.
https://devzone.nordicsemi.com/f/nordic-q-a/146/example-software-for-usb-communication-of-nrf24lu1p

I was looking for some example on how to interface a PC software with the USB dongle nRF24LU1P.
I'm trying to interface using winusbnet on a WPF application.
Thanks.

[ovrebekk]

Hi Alessio

Any particular reason you are using the nRF24LU1+, and not one of our newer parts such as the nRF52840 or the nRF52833?

The nRF24L series is very old at this point, and is not recommended for new designs. 

In the mean time I will check if we are able to dig out some of the old examples for the nRF24LU1+.  

Best regards
Torbjørn

[Alessio]

Hi Torbjørn

We've choose the nRF24 because it's not based on Bluetooth. Once nRF24 is configured, after switching devices on it just work . With Bluetooth there are compatibility issues, pairing procedures and so on.

[Alessio]

Regarding the main topic, the actual problem is at driver level where we're trying to prepare a inf file for deploing a winusb driver. But it doesn't work. If you have some example or guide on how to deploy USB driver even for similar devices I think it will help.

Thanks.

[ovrebekk]

Hi Alessio

You could have a look at an old snifferdemo that I made for the LU1+ back in the day:
https://github.com/NordicPlayground/nrf24lu1p-snifferdemo

It uses the Winusb/libusb driver, and the inf file is included in the repo. 

As far as I remember it was possible to manually edit the .inf file to allow you to change the PID/VID etc. 

Best regards
Torbjørn

[Alessio]

Hi Torbjørn,

thanks for your support.

As you probably know I opened another case on a similar topic. We found that there is a way where Windows can automatically install Winusb driver for a device relying on descriptors that are provided by the device. We prefer to choose that way instead of dealing with driver signature and installation. The link you provided can be useful anyway.

Best regards.

[ovrebekk]

Hi Alessio

Thanks for the information, I must admit I was not aware of this. 

After getting USB support back in the nRF52 series (the nRF51 series did not support it) most of the examples have been based on the CDC class, since this USB class doesn't require manual driver installation on most platforms, and provides functionality very similar to Winusb. Also, since a CDC device looks like a normal comport on the host side it is often easier to integrate with it from an application developer point of view (most development environments have some kind of serial class). 

Best regards
Torbjørn

[Alessio]

Hi Torbjørn,

we've finally implemented USB descriptors on the device so it is recognized as a WINUSB compatible device and driver is automatically provided by Microsoft.

Regarding new devices of the nRF52 series are they going to replace the nRF24? The new devices can be used to obtain the same features of nRF24 with "static pairing" between multiple transmitters and a receiver with USB interface?

Thanks

[ovrebekk]

Hi Alessio

Good to hear you found a solution. 

The nRF52 series is definitely considered a replacement of the nRF24L series, yes. It supports most features of the nRF24L series, and a host of new features. 

When you refer to "static pairing" do you mean static pairing of devices over ESB or Gazell?

Best regards
Torbjørn

[Alessio]

Hi Torbjørn,

for static pairing, yes, it's over ESB or Gazell in a manner that there are up to 3-4 transmission device sending data to an USB receiver that is plug and play, without configuration. Addresses should be stored in the uC of the receiver and in the uC of each device.

You said "It supports most features of the nRF24L series", is there a list of which features are supported and which are dropped?

Best regards,

Alessio

[ovrebekk]

Hi Allesio 

Alessio said:

for static pairing, yes, it's over ESB or Gazell in a manner that there are up to 3-4 transmission device sending data to an USB receiver that is plug and play, without configuration. Addresses should be stored in the uC of the receiver and in the uC of each device.

Thanks for the clarification. The nRF52 devices will all support this. 

The main challenge in implementing a system like this is on the management side, how to assign the keys in production and ensure that you bundle the devices accordingly, but this is obviously not dependent on which Nordic device is used.  

Alessio said:

You said "It supports most features of the nRF24L series", is there a list of which features are supported and which are dropped?

There is no singular list for this, no. 

The main missing feature in the nRF52 series is the proprietary 250kbps on air datarate mode, which was deprecated because it didn't really provide any better performance in the nRF52 devices (the 1M mode in the nRF52 is comparable to the 250kbps mode in the nRF24L series, which basically made the 250kbps mode useless unless you needed to be compatible with existing devices running at this rate). 

There are also some configurations of ESB involving the legacy ShockBurst mode (EN_AA disabled in the nRF24L) that can not be supported on the nRF52, if you need to support an application using multiple pipes with EN_AA disabled and varying payload lengths. If you use ESB mode (EN_AA = 1) then there is no such limitation, and the nRF52 is on par with the nRF24L series in terms of ESB features. 

To summarize I would say the only situation where the nRF52 would not be a suitable replacement for the nRF24L is if you need to be backwards compatible with existing nRF24L based products using one of the two features I mentioned above. 

Best regards
Torbjørn

[Alessio]

Thanks for the clarification.

[ovrebekk]

You welcome Alessio