Wireless nRF24L01+ sniffer for MySensors

[Yveaux]

@marceltrapman Wooow! First 'official' sniffer PCB! :+1: (did you give it an oldskool look? looks 50 years+ old :-)
Great it worked out that well!

In my experience there are always some malformed packets, nothing to worry about.

[Damme]

This post is deleted!

[marceltrapman]

@Yveaux It is a combination of the board color (it really is a bit 'greenish') the green matte, daylight gone and the flash light :)

I am pretty content with it except that I need to think about those via's next time as well as using flux.

Any idea where those malformed packets come from?

[Yveaux]

@marceltrapman try to combine vias with through hole components. E.g a resistor write can bring you to the other side of the board.
Or just make the board single sided. Should be doable for such a board and it is also easier to construct.
I switched to smd primarily to prevent drilling and reduce board space...
Just a matter of taste/laziness :)

[Yveaux]

@marceltrapman said

Any idea where those malformed packets come from?

I guess it's just inherent to wireless traffic. The same reason why a Wi-Fi connection gives different rates all of the time.
It's just a hunch, I didn't really dive into it.
Using the sniffer we could also get some real figures on e.g. the capacitor fix. It all can make a difference but as long as you cannot measure objectively it is all guessing...

[marceltrapman]

@Yveaux said:

try to combine vias with through hole components. E.g a resistor write can bring you to the other side of the board.

I know and I did that with the LED's but with a header that is more difficult.

Or just make the board single sided. Should be doable for such a board and it is also easier to construct.

I am sure but I did not want to do that. This also was a learning project for me :)

I switched to smd primarily to prevent drilling and reduce board space...
Just a matter of taste/laziness :)

I am going to do that as well but I wanted to do one step at a time...

Thanks for your advice, much appreciated!!!

[hek]

Hackaday! Congrats.

http://hackaday.com/2014/08/05/sniffing-nrf24l01-traffic-with-wireshark/

[Yveaux]

@hek wow! Thanks for the tip!
Hope this will also boost mysensors popularity!

Over 1000 hits on my blog in half a day! Wow!

[Yveaux]

Updated the sniffer's Wireshark dissectors to MySensors 1.4b protocol version of Aug 18, 2014.
Please update the **mysensors2.dll **when you update to this 1.4b version.

[Sparkman]

@Yveaux Thanks for putting this together. I'm trying it out today and seem to have everything running properly and without errors, but it's not capturing any packets. Can I just run nrf24sniff with all default parameters (other than the com port) for the current 1.4 release, or do I need to change some of them? I haven't made any changes to the default mysensor settings such as channel and data rate. I'm running it on a Mega, but have tested the radio, etc. using the BinarySwitchSensor sketch and it's communicating properly to my gateway/controller.

Thanks
Al

[Yveaux]

@Sparkman Even if the MySensors protocol changed w.r.t. the version supported by the sniffer you should still be able to capture raw nRF24 packets on air. Only the MySensors dissection could fail in this case.

You should double check the values of DEFAULT_RF_CHANNEL, DEFAULT_RF_DATARATE and DEFAULT_RADIO_ID in NRF24_sniff.ino.
They should match the MySensors configuration from MyConfig.h: RF24_CHANNEL, RF24_DATARATE and BASE_RADIO_ID.
The MySensors default datarate has gone down from 1Mbps to 25Kbps, so I would expect the DEFAULT_RF_DATARATE in the sniffer causes the malfunction.

The SPI/pin settings for the radio connection could also be different on your Mega. The sniffer only supports hardware SPI. Other pins are configured in the same NRF24_sniff.ino:

    #define RF_CE_PIN                      (9)
    #define RF_CS_PIN                      (10)
    #define RF_IRQ_PIN                     (2)
    #define RF_IRQ                         (RF_IRQ_PIN-2) 

Also, the sniffer uses interrupts for quick response to new messages, so make sure the IRQ pin is connected between the Mega and the nRF24 (MySensors doesn't use) !

To rule out any issues caused by the Mega, could you test the sniffer using a regular Uno?

Good luck!

[Sparkman]

@Yveaux Thanks for the reply. I did run it with the -r2 option as well to see if that would work, but I didn't capture any packets that way either. I don't have an unused Uno, but also tried it with a Pro Mini and am not capturing packets that way either. I can use the Mega and Pro Mini with a regular MySensors sketch, so I know that all connections are good. I do have IRQ connected to pin 2 on both of them which according to the documentation for those, is where they need to go. I've confirmed the settings between nrf24_sniff.ino and myconfig.h and everything matched, except the data rate which I have now fixed. With development mode enabled on the sketch, I get the following:

-- RF24 Sniff --
4e 4c02050400fce1a8a80000000220 Channel:     76
Datarate:    250Kb/s
Address:     0xA8A8E1FC**
Max payload: 32
CRC length:  2

STATUS		= 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1	= 0xa8a8e1fc 0xa8e1fc03
RX_ADDR_P2-5	= 0xff 0xc4 0xc5 0xc6
TX_ADDR		= 0xa8e1fc00
RX_PW_P0-6	= 0x20 0x20 0x20 0x00 0x00 0x00
	
EN_AA		 = 0x00
EN_RXADDR	= 0x07
F_CH		 = 0x4c
RF_SETUP	= 0x27
CONFIG		 = 0x07
DYNPD/FEATURE	= 0x3f 0x06
Data Rate	 = 250KBPS
Model		 = nRF24L01+
CRC Length	 = Disabled
PA Power	 = PA_MAX

Listening...

and from nrf24sniff:

C:\Users\Downloads>nrf24sniff -P4 -r2

Connect Wireshark to \\.\pipe\wireshark to continue...
Wait for sniffer to restart Ok

Channel:      76
Datarate:     250Kb/s
Address:      0xa8a8e1fc**
Max payload:  32
CRC length:   2
Captured 0 packets, Lost 0 packets

Does anything jump out to you as being wrong?

Thanks
Al

[Yveaux]

@Sparkman I guess you've only enabled "development mode" (not defining BINARY_OUTPUT) to get some output to post on the forum, right? There will be no communication between the arduino and the Windows nrf24sniff executable when BINARY_OUTPUT is not defined, as textual output is not recognized by the Windows program. The parameter -r2 will not make a difference then...

Anyway, if you change the default configuration items as I suggested in my previous post, you should be able to see some data coming in on the sniffer in "development mode". Another option would be to connect some LEDs to A0..A4 to indicate data coming in/going out. This way you can rule out the connection to the Windows program.

Just to be sure, are you transmitting any data using a separate gateway+sensor when running the sniffer?

[Sparkman]

@Yveaux Yes, I only enabled development mode to troubleshoot. Had it running with BINARY_OUTPUT defined during normal operation. I have another sensor nearby that is sending data and it's talking to the gateway/controller properly so I know it's transmitting/receiving. I've tried a few different radio modules as well to rule out any issues with those, but I did test them using a normal MySensors sketch first to make sure they are operating properly. I'll add some LED's to troubleshoot. Below is my sketch for reference. Thanks for your help!

Cheers
Al

EDIT: Code Removed

[Yveaux]

@Sparkman Apart from the DEFAULT_RF_DATARATE your sketch seems to be identical to mine on GitHub...
It also doesn't seem to work on a Pro Mini, as you say. Only hardware difference between a Pro Mini and Uno is clock speed (or am I missing something?)

@marceltrapman Did you ever get the sniffer running on a Mega?

[Sparkman]

@Yveaux said:

Apart from the DEFAULT_RF_DATARATE your sketch seems to be identical to mine on GitHub...

That's a good thing right?

@Yveaux said:

It also doesn't seem to work on a Pro Mini, as you say. Only hardware difference between a Pro Mini and Uno is clock speed (or am I missing something?)

That's my understanding as well.

I hooked up LEDs to pins A0-A4. The LED on A0 is on when the sketch is running and the LED on A2 flashes briefly when my other sensor sends a packet. The LEDs on A1, A3 and A4 have not shown any activity. Is that what is expected?

Thanks
Al

[marceltrapman]

@Yveaux Never tried. It works with the Uno and I say 'never change a winning team' :)

[Sparkman]

@Yveaux Well strangely enough, after hooking up the LEDs, it now works. I've tried it on both the Pro Mini and on the Mega and am now capturing data. Does the sketch not work if the LEDs are not connected? Should I have commented out the #define LED_SUPPORTED line if the LEDs are not connected?

Thanks for the help and the quick replies. Much appreciated.

Cheers
Al

[Yveaux]

@Sparkman said:

That's a good thing right?

Of course! Mine works ;-)

I hooked up LEDs to pins A0-A4. The LED on A0 is on when the sketch is running and the LED on A2 flashes briefly when my other sensor sends a packet. The LEDs on A1, A3 and A4 have not shown any activity. Is that what is expected?

A1 blinks on reception of data by the nRF24 (toggled in the interrupt handler per packet). It will probably blink too fast for the eye to see (a scope would help though).

Same for A3 (which quickly blinks when a new config is received).
A4 will indicate the sniffer cannot keep up with the incoming packet stream. This should not happen as packets will be dropped.

[Yveaux]

@marceltrapman Hehe :+1:
Anyway, thanks for the update!