BitCatcher ZigBee Network Analyzer

Go To Last Post
30 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Luxoft BitCatcher ZigBee Network Analyzer is a simple and powerful tool for analyzing wireless transmissions in ZigBee based networks. This tool is extremely useful for engineers working on products with ZigBee connectivity and can be used during the complete development process to:

    -Observe real-time packet exchange, create and view sniffer logs -Quickly identify the reasons behind connectivity issues
    -Verify communication side of the application behavior

The main part of the Luxoft BitCatcher ZigBee Network Analyzer tool is a PC application that provides a user with a graphical interface for protocol analysis. The package also contains a set of protocol description files in XML format. Necessary PC drivers and a number of firmware files for supported hardware platforms are included as well.

The main features of the Luxoft BitCatcher ZigBee Network Analyzer tool are:

    - Windows and Linux support - Support of various 802.15.4 frequency bands: 2.4 GHz, 868 MHz and 915 MHz
    - Native ZigBee and Light Link specific security schemes support
    - Simple management of security keys - key type auto detection
    - Flexible extension of supported protocols at any level
    - Daintree(c) compatible Sniffer logs format

Luxoft BitCatcher ZigBee Network Analyzer tool parses and displays packet information based on their description in the protocol description files. A user can modify them to extend the existing protocols or to create new ones. By default, the tool is able to parse the following wireless protocols:

    - IEEE 802.15.4 MAC - ZigBee PRO (Network, ZDO and APS layers)
    - ZigBee Smart Energy
    - ZigBee Light Link

Supported hardware includes:

    - Atmel AVR RZUSBSTICK - Dresden Elektronik deRFusb-23E00 (2.4GHz)
    - Dresden Elektronik deRFusb-13E00 (Sub-GHz)

BitCatcher can be downloaded from http://www.luxoft.com/embedded-systems-development/bitcatcher/.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Last Edited: Fri. Oct 16, 2015 - 12:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a sample log in case you don't have the hardware, but want to see how the software works. There is no useful information in the log, just something I had on my drive.

Attachment(s): 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for linking to this Alex!

Anyone know what firmware/driver combo I need to run this on windows 8 with a RZUSBSTICK? Neither the factory firmware nor the one that comes with the app shows the serial port in the sniffer app. I was able to get a serial port with Ubuntu 12.04 by loading the usbserial driver using the RZUSBSTICK factory firmware but the sniffer app was never able to open the port (even running it with sudo).

Sorry if this is a dumb question.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

W8 is a pain. Try this .inf file file and see if it works.

You need to run with the firmware in the package.

Attachment(s): 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Alex!

If I understand things correctly, LwMesh uses 802.15.4 physical frames but is not 802.15.4 MAC compliant. The conclusion is that BitCatcher can not track/show frames in a LwMesh network.

Correct?

(And a bit of a pity if so, but I guess one never can get it all..)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
If I understand things correctly, LwMesh uses 802.15.4 physical frames but is not 802.15.4 MAC compliant.
It uses subset of 802.15.4 MAC (only Data and Ack frames).

JohanEkdahl wrote:
The conclusion is that BitCatcher can not track/show frames in a LwMesh network.
It actually can. By default it will try to decode MAC payload as ZigBee, but it is fixable with the attached archive.

Archive contains "plugins" and "protocols" directories. Just replace the original ones (may be back them up first) and BitCatcher will decode LwMesh properly. No security decryption though, since it can not be fixed be simply substituting a bunch of XML files.

JohanEkdahl wrote:
(And a bit of a pity if so, but I guess one never can get it all..)
Sure one can :)

Attachment(s): 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex, I bow in your general direction! :D

I realize that I am asking you to shoot yourself in your own foot, but do you know if BitCatcher handles Contiki/uIPv6 frames? Ignore if you feel your feet are too dear to you. And sorry if this is mainstream knowledge - I am still a true beginner when it comes to this wireless stuff.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have nothing against Contiki/uIPv6, but there is no support, since I have not done any development for them.

It should be relatively easy to create XML protocol descriptions if needed.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wireshark can import byte separated data if you add 0000 to the beginning of each line, e.g. the first few lines of the above data become

0000 63 88 63 a1 41 00 00 62 10 04 ff ff
0000 02 00 63 ff ff
0000 61 88 64 a1 41 00 00 62 10 48 00 00 00 62 10 0a be 40 01 01 00 01 00 01 00 01 02 80 98 69 11 00 00 01 00 62 10 00 00 00 01 00 00 00 02 a1 41 19 00 00 d0 ba 01 0c 1b 00 00 00 19 00 00 00 8e 02 00 00 ff ff
0000 02 00 64 ff ff
0000 63 88 65 a1 41 00 00 62 10 04 ff ff
0000 02 00 65 ff ff

The trailing ff ff are apparently dummy checksums, so I imported them as "IEEE 802.15.4 Wireless PAN" including checksum (Wireshark then reports the checksum is bad). But it will dissect ipv6 packets and many other protocols, the output in this case being

No.     Time        Source                Destination           Protocol Length Info
      1 0.000000    0x1062                0x0000                IEEE 802.15.4 12     Data Request, Bad FCS

Frame 1: 12 bytes on wire (96 bits), 12 bytes captured (96 bits)
    Arrival Time: Mar 11, 2013 16:32:41.000000000 Eastern Daylight Time
    Epoch Time: 1363033961.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 12 bytes (96 bits)
    Capture Length: 12 bytes (96 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan]
IEEE 802.15.4 Command, Dst: 0x0000, Src: 0x1062, Bad FCS
    Frame Control Field: Command (0x8863)
        .... .... .... .011 = Frame Type: Command (0x0003)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = Intra-PAN: True
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
        ..00 .... .... .... = Frame Version: 0
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
    Sequence Number: 99
    Destination PAN: 0x41a1
    Destination: 0x0000
    Source: 0x1062
    Command Identifier: Data Request (0x04)
    FCS: 0xffff (Incorrect, expected FCS=0x749a
    [Expert Info (Warn/Checksum): Bad FCS]
        [Message: Bad FCS]
        [Severity level: Warn]
        [Group: Checksum]

No.     Time        Source                Destination           Protocol Length Info
      2 0.000000                                                IEEE 802.15.4 5      Ack, Bad FCS

Frame 2: 5 bytes on wire (40 bits), 5 bytes captured (40 bits)
    Arrival Time: Mar 11, 2013 16:32:41.000000000 Eastern Daylight Time
    Epoch Time: 1363033961.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 2
    Frame Length: 5 bytes (40 bits)
    Capture Length: 5 bytes (40 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:data]
IEEE 802.15.4 Ack, Sequence Number: 99, Bad FCS
    Frame Control Field: Ack (0x0002)
        .... .... .... .010 = Frame Type: Ack (0x0002)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .0.. .... = Intra-PAN: False
        .... 00.. .... .... = Destination Addressing Mode: None (0x0000)
        ..00 .... .... .... = Frame Version: 0
        00.. .... .... .... = Source Addressing Mode: None (0x0000)
    Sequence Number: 99
    FCS: 0xffff (Incorrect, expected FCS=0xe425
    [Expert Info (Warn/Checksum): Bad FCS]
        [Message: Bad FCS]
        [Severity level: Warn]
        [Group: Checksum]

No.     Time        Source                Destination           Protocol Length Info
      3 0.000000    0x1062                0x0000                ZigBee   68     Data, Dst Endpt: 1, Src Endpt: 1, Bad FCS

Frame 3: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
    Arrival Time: Mar 11, 2013 16:32:41.000000000 Eastern Daylight Time
    Epoch Time: 1363033961.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 3
    Frame Length: 68 bytes (544 bits)
    Capture Length: 68 bytes (544 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:zbee.nwk:zbee.aps:data]
IEEE 802.15.4 Data, Dst: 0x0000, Src: 0x1062, Bad FCS
    Frame Control Field: Data (0x8861)
        .... .... .... .001 = Frame Type: Data (0x0001)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = Intra-PAN: True
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
        ..00 .... .... .... = Frame Version: 0
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
    Sequence Number: 100
    Destination PAN: 0x41a1
    Destination: 0x0000
    Source: 0x1062
    FCS: 0xffff (Incorrect, expected FCS=0xab89
    [Expert Info (Warn/Checksum): Bad FCS]
        [Message: Bad FCS]
        [Severity level: Warn]
        [Group: Checksum]
ZigBee Network Layer Data, Dst: 0x0000, Src: 0x1062
    Frame Control Field: Data (0x0048)
        .... .... .... ..00 = Frame Type: Data (0x0000)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 01.. .... = Discover Route: Enable (0x0001)
        .... ...0 .... .... = Multicast: False
        .... ..0. .... .... = Security: False
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...0 .... .... .... = Extended Source: False
    Destination: 0x0000
    Source: 0x1062
    Radius: 10
    Sequence Number: 190
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x00)
        .... 00.. = Delivery Mode: Unicast (0x00)
        ..0. .... = Security: False
        .1.. .... = Acknowledgement Request: True
        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: Power Configuration (0x0001)
    Profile: Unknown ZigBee Standard (0x0001)
    Source Endpoint: 1
    Counter: 0
Data (41 bytes)

0000  01 02 80 98 69 11 00 00 01 00 62 10 00 00 00 01   ....i.....b.....
0010  00 00 00 02 a1 41 19 00 00 d0 ba 01 0c 1b 00 00   .....A..........
0020  00 19 00 00 00 8e 02 00 00                        .........
    Data: 0102809869110000010062100000000100000002a1411900...
    [Length: 41]

No.     Time        Source                Destination           Protocol Length Info
      4 0.000000                                                IEEE 802.15.4 5      Ack, Bad FCS

Frame 4: 5 bytes on wire (40 bits), 5 bytes captured (40 bits)
    Arrival Time: Mar 11, 2013 16:32:41.000000000 Eastern Daylight Time
    Epoch Time: 1363033961.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 4
    Frame Length: 5 bytes (40 bits)
    Capture Length: 5 bytes (40 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:data]
IEEE 802.15.4 Ack, Sequence Number: 100, Bad FCS
    Frame Control Field: Ack (0x0002)
        .... .... .... .010 = Frame Type: Ack (0x0002)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .0.. .... = Intra-PAN: False
        .... 00.. .... .... = Destination Addressing Mode: None (0x0000)
        ..00 .... .... .... = Frame Version: 0
        00.. .... .... .... = Source Addressing Mode: None (0x0000)
    Sequence Number: 100
    FCS: 0xffff (Incorrect, expected FCS=0x909a
    [Expert Info (Warn/Checksum): Bad FCS]
        [Message: Bad FCS]
        [Severity level: Warn]
        [Group: Checksum]

No.     Time        Source                Destination           Protocol Length Info
      5 0.000000    0x1062                0x0000                IEEE 802.15.4 12     Data Request, Bad FCS

Frame 5: 12 bytes on wire (96 bits), 12 bytes captured (96 bits)
    Arrival Time: Mar 11, 2013 16:32:41.000000000 Eastern Daylight Time
    Epoch Time: 1363033961.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 5
    Frame Length: 12 bytes (96 bits)
    Capture Length: 12 bytes (96 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan]
IEEE 802.15.4 Command, Dst: 0x0000, Src: 0x1062, Bad FCS
    Frame Control Field: Command (0x8863)
        .... .... .... .011 = Frame Type: Command (0x0003)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = Intra-PAN: True
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
        ..00 .... .... .... = Frame Version: 0
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
    Sequence Number: 101
    Destination PAN: 0x41a1
    Destination: 0x0000
    Source: 0x1062
    Command Identifier: Data Request (0x04)
    FCS: 0xffff (Incorrect, expected FCS=0x692b
    [Expert Info (Warn/Checksum): Bad FCS]
        [Message: Bad FCS]
        [Severity level: Warn]
        [Group: Checksum]

No.     Time        Source                Destination           Protocol Length Info
      6 0.000000                                                IEEE 802.15.4 4      Ack, Bad FCS

Frame 6: 4 bytes on wire (32 bits), 4 bytes captured (32 bits)
    Arrival Time: Mar 11, 2013 16:32:41.000000000 Eastern Daylight Time
    Epoch Time: 1363033961.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 6
    Frame Length: 4 bytes (32 bits)
    Capture Length: 4 bytes (32 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:data]
IEEE 802.15.4 Ack, Sequence Number: 101, Bad FCS
    Frame Control Field: Ack (0x0002)
        .... .... .... .010 = Frame Type: Ack (0x0002)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .0.. .... = Intra-PAN: False
        .... 00.. .... .... = Destination Addressing Mode: None (0x0000)
        ..00 .... .... .... = Frame Version: 0
        00.. .... .... .... = Source Addressing Mode: None (0x0000)
    Sequence Number: 101
    FCS: 0xff65 (Incorrect, expected FCS=0x33b0
    [Expert Info (Warn/Checksum): Bad FCS]
        [Message: Bad FCS]
        [Severity level: Warn]
        [Group: Checksum]
Data (1 byte)

0000  ff                                                .
    Data: ff
    [Length: 1]
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
W8 is a pain. Try this .inf file file and see if it works.

You need to run with the firmware in the package.

I loaded up the firmware from the sniffer package (embedded folder) and installed the driver you attached (more below). Device Manager shows "Other devices -> Atmel RZUSBStick Sniffer" as driverless. Attempts to update or find a driver fail. I tried the driver from the sniffer package as well, no luck :(

Has anyone got this working on Windows 8 yet?

Installing unsigned drivers on Windows 8

To install the INF (both what you attached and the VCP driver from the sniffer package) you need to jump through some hoops. Normally, W8 will not let you install unsigned drivers. To install it anyway you need to do the following:

Open the right-side menu (whatever it is called), click "power" and then click "Restart" menu item while holding down the SHIFT key. This presents a series of screens:

1. Choose "Troubleshooting" from the first screen
2. Choose "Advanced Options" from the second screen
3. Click Restart on the third screen.

After restart, but before W8 boots, you will see a menu screen. Press '7' to disable signature checking for drivers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fixed!

There is a mistake in the driver\Atmel_AVR_RZUSBSTICK\6119_VCP.inf file:

Product ID is 2115 not 6119!

Change line 36: Replace '...&PID_6119' with '...&PID2115'

if your are running x86_64 Windows 8.

Reinstall the modified INF and the device is recognized right away.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cthree87 wrote:
Product ID is 2115 not 6119!
And this should be fixed in the file I've attached earlier.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
Luxoft BitCatcher Network Analyzer is great.
But it seams not to report 802.15.4 frames above a certain length (126 bytes I think). I can see that the DeRF dongle properly transmit these long packets over the serial USB port (using Portmon.exe), but nothing appears under the Bitcatcher GUI.

I asked the support, but got no answer so far.
Did anyone notice this and do you think there could be a workaround ? (This makes this sniffer useless for me)
Thks,
Pierre.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've noticed the same. I don't know what the problem is, but it does not indicate full payload frames. I don't have a solution for this.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Alexru !
I also noticed that the frame time was not correct on Bitcatcher (going way too fast as compared to PC clock).
Anyway, I like the tool (better than Microchip Zena, which I also use), and I really would like to find a way to make Bitcatcher receive all frames.
I think I could use a zigbit dongle of mine and write my own firmware to forward frames to the serial port using the same protocol (and truncate larger frames so they are displayed by bitcatcher). This way I can also use large gain antenna and sniff everything..
If someone has a link to this protocol details, it would save me some time probably.
Regards,
Pierre

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Supposedly it uses Perytons protocol, but I'm not sure if it is public.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Received my RZUSB stick from mouser this morning and can not get it work, it shows up as RZUSB (jungo device) but their is no virtual com port attached to it. The PID = 0x210a and not 0x2115 - any ideas what I need to do to get it to work

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need to program the HEX file that comes with BitCatcher, default firmware will not work.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suppose I need a programmer for that, pity it is not really properly documented anywhere, so I could have selected a stick that doesn't require changed firmware.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For BitCatcher all of them will require change of the firmware.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, got it, what programmer do I need to flash the new firmware to the rz usb stick, any suggestions ?? you help is very much appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any that will program AT90USB1287.

The most capable current programmer is [url=http://store.atmel.com/PartDetail.aspx?q=p:10500375#tc:description]Atmel ICE[/url]. If you plan to develop using Atmel MCUs, I'd suggest it. It is a good investment.

Cheaper version of the same device is available as a [url=http://store.atmel.com/PartDetail.aspx?q=p:10500376#tc:description]kit[/.... But this will require cables and that extra stuff. And cables for those small pitch connectors are surprisingly expensive.

Also, I'm not sure if standalone boards come with the small JTAG connector soldered or not, but you will need that as well.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, found [url=http://store.atmel.com/PartDetail.aspx?q=p:10500269;c:100112#tc:inboxdes... one [/url] on stock @ mouser, has an Adapter kit consisting of 10-pin 100 mil, 6-pin 100 mil, and 6-pin 50 mil … that should do it (and yet another programmer will be added to my collection)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That will work too, but it is more expensive and less capable that Atmel-ICE.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I finally got 6119_VCP to install on Windoze 8.1 and appear in Device Manager as RZUSBstick Sniffer. Changing PID to 2115 seems to have affected this result. BitCatcher still does not find the device... any idea what to do now? I tried the other driver mentioned above. Windoze "installed" it without complaining, but Device Manager showed it as having no driver... why is it so ridiculously difficult to install a VCP? I have never had this kind of trouble with FTDI or SiLabs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FTDI and SiLabs are not VCP devices, they use proprietary protocols and drivers.

 

I have no idea how to deal with the actual problem though. I've never used or seen W8.
 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FTDI and SiLabs most certainly are VCP devices, I have both installed on my machine and they work.  I guess I should have just bought a Zena in the first place.  Apparently Atmel is not interested in making this paperweight functional.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FWIW, the 6119_VCP.inf (with corrected PID) seems to work with Atmel Wireshark Interface Sniffer and Wireshark.  This is after I re-flashed the dongle with the hex file contained in Wireshark download from Atmel Gallery.  I'm not sure what the problem is with BitCatcher.  Not sure I care after wasting the better part of two days.  I did have to disable Driver Signature Enforcement in order to install the driver... a signed one would be nice.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clark.leach wrote:
FTDI and SiLabs most certainly are VCP devices,
Not as described in USB specification.

clark.leach wrote:
I have both installed on my machine and they work.
That is because they come with their own drivers.

clark.leach wrote:
I guess I should have just bought a Zena in the first place.  Apparently Atmel is not interested in making this paperweight functional.
The software in question is not officially supported with W8. It is also not an Atmel product.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Last Edited: Wed. Sep 24, 2014 - 10:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

W8 is a pain. Try this .inf file file and see if it works.

You need to run with the firmware in the package.

 

It didn´t work for me. I am using Windows 7 32 bits.

As someone said

Quote:

Received my RZUSB stick from mouser this morning and can not get it work, it shows up as RZUSB (jungo device) but their is no virtual com port attached to it. The PID = 0x210a and not 0x2115 - any ideas what I need to do to get it to work

 

I changed the PID number at the file. Now Windows recognised the driver, and I can see the RFUSBSTICK as a COM port. However, it has an error, the device cannot be initialized.