This morning I took delivery of a ST Microelectronics STM32W-RFCKIT (€33 from Mouser). I was pleasantly surprised that it too has a network analyzer in the form of a Wireshark bridge. These days Wireshark is the only game in town for packet analysis, so this was a smart move.
The kit comes in two pieces: a remote control device with 6 buttons and a dongle for the PC.
Unfortunately all this is Windows software. So I powered up a Windows XP virtual machine, and installed the software from the ZIP file SW application to interface Wireshark packet capture tool (AN3406). I also needed to install Wireshark for Windows. I plugged in the dongle and assigned the USB device to my Windows VM (this is the same as physically plugging in the device if it was a real computer). Then the usual windows new hardware detection and driver installation. (I can never quite understand what is going on with Windows when new hardware is plugged in. I did a reboot also, but that was more out of habit... it might not have been necessary).
Right out of the box, the dongle does not have the right firmware installed. So select the Tools menu and select "Flasher". Click the 'Flash' button and all going well, the packet sniffer firmware will be transferred onto the dongle.
Linux is my OS of choice, so it would be great to have this working without having to boot a Windows VM. Unfortunately it seems that despite the wise choice of using the Wireshark tool and extolling the virtues of open source code in the documentation, they've neglected to include the source code for the firmware and server software. However it shouldn't be too difficult to reverse engineer. If I get a chance over the coming days I'll give it a stab.
 |
| A screen grab of Wireshark sniffing 802.15.4 / ZigBee packets from the dongle supplied with the STM32W-RFCKIT. |
Update (7 April 2012): I did a quick comparison with the STM32W dongle vs my Microchip ZENA (first version). Both devices are on my desk, about 50cm apart. I ran a Wireshark session on both devices at the same time on the same channel. After a few minutes the STM32W device captured 424 packets vs 290 packets from the ZENA. It seems the STM32W-RFCKIT makes for a better packet sniffer!
Update (9 April 2012): I've made good progress reverse engineering the firmware protocol. I've now got a Linux command line tool (written in C) that will dump packet hex to terminal and allows the 802.15.4. channel to be changed. I hope to release the first version of the Linux Wireshark server in the next few days.
Update (12 April 2012): The first version of the Linux Wireshark server has been released.
3 comments:
Hello!
I have a problem triggering digital output (like DO0) on the remote ZigBee.
Case 1:
I know I can trigger it like this:
- setting digital input on the base ZigBee
- setting digital output on the remote ZigBee (DO LOW)
- and if configured right the input state on the base ZigBee is transferred to the digital output on remote ZigBee
I managed to do that, but I would like to trigger it via data packets.
Case 2:
So I tried with setting API packets that set the digital output on the remote ZigBee. I managed to change the digital output on remote ZigBee with commands ATD0=4 (DO LOW) ATD0=5 (DO HIGH).
DO LOW API command:
7E 00 10 17 05 00 13 A2 00 40 08 C9 80 00 02 02 44 30 04 21
DO HIGH API command:
7E 00 10 17 05 00 13 A2 00 40 08 C9 80 00 02 02 44 30 05 20
Problem:
But the problem I have is that sometime the communication between the base and remote might be lost. And if the digital output on the remote ZigBee is set to 3,3V (DO HIGH) and the communication is lost, the digital output would stay at the 3,3V. I want it to "reset" to 0V. In "case 1" when I tried to trigger the digital output with digital input, you can set the reset timer for that digital output (command ATT0) and it did the work (the digital input reset to value 0V), but you can't use that in the case 2.
Question:
Does anybody know what is the API format of the packet to simulate case 1 - I/O line passing (case 1 data packets)?
Do you have any other ideas how to "reset" the digital output to 0V.
Sounds to me like you are referring to the Digi XBee modules. XBees can (and often are) configured to use the ZigBee protocol, but they can also use other 802.15.4 protocols. The different protocols are achieved by uploading different firmware to the module. So "XBee" is not the same thing as "ZigBee".
I'll assume you're referring to XBees. I did not know that you could configure XBee modules to set a remote digital IO line based on the input of the local module. I've just done some googleing and I think that feature is only available in some of the non-ZigBee firmware options.
So I don't think it's possible with the ZigBee firmware to have the remote module timeout and reset back to a default state if the connection is lost. I think you must have the base unit keep retrying the reset command until it succeeds.
But what you can do is have a MCU connected to the XBee module at the remote end. That gives you lots of flexibility, at the cost of additional hardware. The MCU could implement the timeout reset function. A really low cost MCU could do this. All you need is a one with a UART, maybe 1-2kB of program memory and 128 bytes of RAM. Microchip etc would do those for well under $1 each (maybe as little as 50c).
Hello!
Yes, I have Digi XBee modules. Sorry for not clearing that up.
Thanks for some info. Maybe I'll try to use some MCU to control it.
Thanks again!
Post a Comment