Wake On Lan Packet Sniffer

[Albina Hickel]

Ifyour are able to wake up your other computers using WOL broadcasts, then it is unlikely that you have an issue with broadcasting the magic packets. The only way to know for sure is to run a packet logger/analyzer.

Wake-on-LAN Packet sniffer is designed to troubleshoot and setup Wake-on-LAN in the Network. It allows to check whether the target machine receive the packet or not. Program will display all incoming "Magic Packets".

Wake-on-LAN (WOL) technology is used for remote waking up machines from sleep state through special network packets (Magic Packet). The Magic Packet is a UDP broadcast message, that contains the Media Access Control (MAC) address of the network card of the target computer. This packet should contain a synchronization stream of 6 bytes of FFh and 16 times the repetition of the MAC address.

There are three different ways to send Wake-on-LAN packets: Limited broadcast: the Magic Packet sent to the limited broadcast address (255.255.255.255) it is received by all machines on the same subnet but not forwarded to machines on other subnets. Subnet-directed broadcast: the Packet sent to the target machine subnet. The router or switch will forward the packet to all the machines on the subnet. Unicast: the Packet sent directly to the machine IP address. If the router or switch still has cached what port that computer is attached to, packet gets access to the machine. Last two ways requires configuration of the routers for each subnet.

I used the SmartRF settings from Expert Mode, with additions of adding 4 Sync Words, 4 preamble bytes, and an address byte (DEV_ADDR).

Everything else is the same. It works great. I'm using polling extensively of RX_BYTES, not interrupts. No GPIOs used.

Next, I took the SmartRF settings for Expert Mode, RF Sniff Mode and loaded those into the CC1120. I kept the 4 sync words, 4 preamble

bytes and address byte. I left the micro running continuously so I could get one thing at a time working. I'm not able to receive any

packets. The micro is continuously looking at RX_BYTES and never sees anything (same code as first exercise). Only difference is

calibrating RCOsc, and instead of going to RX mode, it goes to WOR mode. After that, RX_BYTES is always 0. The TX sends 50 packets, as

before, but nothing received.

You cannot use SPI polling when running sniff mode, as pulling the CSn pin low to communicate on the SPI will wake the radio from SLEEP mode (Pulling SCn low will take the radio to IDLE and it will not get back to sniff mode before you issue a new strobe command).

The purpose of the sniff mode is to use as little current as possible, and the idea is that the MCU should be in SLEEP while waiting for an interrupt from the radio saying that a packet has been received. SPI polling is not possible for SLEEP mode.

Thanks. I have been referring to that code example. I understand your response and I have tweeked my code slightly. My MCU is not going to be asleep in many cases when a packet comes in, so once I set the CC1120 to WOR mode, I continually poll the EXTINT register on my MCU (which is tied to GPIO0 by virtue of value of 0x06 in the IOCFG0 register) for an activation, but so far that's not working either. I also tried a 0x13 in IOCFG0 register and still no activation. So, I'm still working on it.

Furthermore, I have two modes for my MCU, ON and SLEEP. And the same two modes for the CC1120. Even in polling when I have both chips in ON mode (meaning they are alway running), I have GPIO0 set up to generate an external interrupt when TX packet is received. Even though I don't use the interrupt (I poll RX_BYTES), it works perfectly and verified by a scope. Every TX packet received activates EXTINT, and when flag is cleared, EXTINT goes back low. TX sends 50 packets (one every 3 seconds). RX receives every one perfectly.

If I use the register setup from the example code for RX Sniff (leaving the MCU in ON mode and GPIO0 left the same), EXTINT on my MCU never goes high to indicate RX received a valid packet. So, is there something I can I can monitor to see that indeed the CC1120 is waking up every wake period? I'm not sure whether the CC1200 is waking up at all or it just isn't seeing a valid TX packet.

Here are my register setups. The first is basically from the Expert Mode, Packet RX setup on SmartRF with a few changes for

preamble, addressing, and fixed packet length. This leaves the radio on continuously and I can either leave my MCU on continuously

or go to sleep. The external interrupt works perfectly in either condition. In both cases, I monitor the external interrupt

pin for a trigger (using GPIO0), and read the packet after the trigger. It works perfectly.

The 2nd is the register setup for RX Sniff Mode. I took the SmartRF setup (Expert Mode, RX Sniff Mode) and tweeked it to

have the preamble, addressing, and fixed packet length as in my first example. It doesn't trigger the external interrupt ever.

I'm still debugging.

You asked about data rate. I'm using whatever data rate is in the registers from the example on page 17 of the RX Sniff

Mode from the 428A document you sent (which is the same as the Expert Mode, RX Sniff Mode on SmartRF). I've been using that

as a reference since the beginning of this exercise.

These registers are the ones I'm using other than the default values. The 'YES' is just a flag to indicate to read/verify the setting once

the register value is set. But, you can see the values I'm using.

In my continuous RX and MCU, I leave the SETTLING_CFG as default (0x0B). The register chart I posted in previous posts are those registers that were programmed with values other than default. Upon starting of my code, I set all registers to default values and validate. The continuous RX works perfectly.

All of the RX Sniff Modes in document 428A use 0x03 as the register value for SETTLING_CFG as well as SmartRF. I'm using the same value. I am also using the same code provided with the SmartRF and that TI provided that calls the Manual Calibration routine before the main infinite RX loop. This is not working.

You have change the preamble to 4 (PREAMBLE_CFG1 = 0x18) bytes even thought the app note uses 3 and this is also what you get from SmartRF Studio (PREAMBLE_CFG1 =0x14). It is OK to increase the number of preamble bytes, but I do not understand why you use it, since you configure the sniff interval based on a 3 bytes long preamble.

I made a calculation error. My Event0 time was also 16.63ms. Your register values performed just like mine, with the RX waking up properly. But, no TX packets are being received - just like mine. If turn on the RX continuously, all TX packets are received. The only thing I think I am doing differently is using the Address, different Sync Words and a fixed packet length.

Still working on it. A little frustrating, as it's probably a simple register omission. I am using GPIO0 for my external interrupt trigger and GPIO2 to monitor the eWOR0 signal. So IOCFG0 = 0x06 and IOCFG2 = 0x37 so I can monitor the signal on the scope.

Is there a way to see is ANY packet, noise or otherwise is being received by the RX to see if the RX is discarding packets? This setup is at my house, so there shouldn't be any noise being 2 feet away.

I took a couple of steps back. I connected up a computer to each of my 2 TrxEB boards. I started SmartRF on both computers, with my custom settings for TX on one computer and RX on another. RX in continuous receive mode. It didn't work. Which was strange. It works on my custom board setup every time. The same settings as listed at the top of this post.

I used the Expert Mode, Packet RX on one computer and Expert Mode, Packet TX on the 2nd computer. Default SmartRF settings. It worked fine. 100 packets sent and received. I then started changing one thing at a time on both setups, to see if it still worked. I changed the sync codes to my sync codes. It worked fine. I changed to Fixed Packet Length and changed the Packet Length to 10. It worked fine. But, when I changed to use address filter (PKT_CFG1.ADDRESS_CHECK_CFG to 01 and DEV_ADDR to 0xCD), it stopped working. Again, it works on my custom setup for RX continously ON mode. So, why would that not work here?

OK. I figured out the DEV_ADDR issue on SmartRF. If you define the system as Packet RX, then changing PKT_CFG1 and DEV_ADDR enables address filtering for the RX only. On the Packet TX side, those registers don't matter and you have to go down to the Advanced Tab and enable address and put the address value. I wasn't aware of that. So that is working now for continuous RX monitoring.

I changed the SmartRF from Packet RX to RX Sniff mode on one computer, using the same TX on the other computer. The 1st packet goes thru, but then no other packet goes thru unless I stop the RX and restart again. If I sent 5 packets from the TX, the RX receives 1, but no more. So, unsure why. This is the default RX Sniff setup, with my sync words, fixed packet length of 10, and address filtering using 0xCD as the address.

I used the normal rx configuration (since I wanted to use the sniff mode settings exported from Studio) and modified the code to use the SWOR strobe instead of the SRX strobe. I also changed the register file:

So, RX Sniff is still not working for me. I went back to my custom setup and loaded the register setup above, except I have swapped

IOCFG0 and IOCFG2 (0x06 and 0x37 are swapped). So, 0 is my interrupt and 2 is my RF Sniff monitor (scope). The external interrupt never

triggers, just like I was seeing before. But the Radio is turning ON/OFF and the scope shows that.

A) and B) work perfectly. The TX sends 50 packets, one every 5 seconds. With the Radio always ON, the external interrupt triggers each

time a packet is received. The CPU can be ON or in Sleep Mode, and the packet is processed either way. The trigger is also verified

by my scope. EXTINT goes high when packet comes in, and is reset when I finish processing. And, repeat.

3a8082e126