Wireless nRF24L01+ sniffer for MySensors

[marceltrapman]

@Yveaux said:

A small piece of software currently only for Windows

What language, tool did you create this with?

Maybe I can help making it either multi platform (Java or Xojo) or Mac (Cocoa)...

[Yveaux]

@marceltrapman it's written in C (got a cpp extension on visual studio...) but builds heavily on Windows api for serial comms and named pipe interfacing.

[daulagari]

Impressive project, that indeed deserves the title "Embedded Innovation"

Did dead the blog posts, very good documented, good to have this information.

I am eager to see more of the Wireshark protocol dissector/analyzer. I find looking at traces almost always the best way to get familiar with protocols.

[marceltrapman]

@Yveaux hmm ok. Will check it out first on my Windows box.

[ch3b7]

Very good job man! i have a question! can i use a vb.net program to send commands from the gateway (conected via usb) to sensors. if y use de command SERIAL.WRITE (in vb.net) dont work!

[Yveaux]

@ch3b7 better create a new topic for this, but I don't see why it wouldn't be possible

[marceltrapman]

@Yveaux Do you have any idea why I get this error when compiling:

NRF24_sniff.ino: In function 'void loop()':
NRF24_sniff.ino:287:20: error: 'class CircularBuffer<_NRF24_packet_t>' has no member named 'clear'

I am using Arduino 1.5.7 (but 1.0.5 generates the same error).
As mentioned in your post I created a separate 'Arduino Sniffer' folder with its own libraries in there.

Any idea what I am doing wrong?

[Yveaux]

@marceltrapman I recently added the clear method to the circular buffer implementation. Maybe I forgot to commit to the sniffer repository... I'm mobile right now, so maybe you can check the circular buffer component in the root of my GitHub account. If this does have the clear method you should copy that over the one from the sniffer repo.
I'll check things tonight....

[Yveaux]

@Yveaux damn, forget it... The latest version is only on my development pc then... I'll update the repo tonight.

[marceltrapman]

@Yveaux said:

@Yveaux damn, forget it... The latest version is only on my development pc then... I'll update the repo tonight.

I had already 'sniffed' the libraries and could not find it but I always think it is me doing something wrong

No problem, the rest is installed.
Uploading the sketch was the last thing to do!

[Yveaux]

@marceltrapman Good to hear you got that far!
I knew I missed something... Now it should be fixed.
Please try again!

[marceltrapman]

@Yveaux said:

@marceltrapman Good to hear you got that far!
I knew I missed something... Now it should be fixed.
Please try again!

Thank you, I will check out your updated sketch and load it into my Arduino.
Not sure that I will have the time to test it tonight though (but I must admit that I am a bit restless ).

[marceltrapman]

Compiling and uploading went well. Now the rest

[Yveaux]

@marceltrapman Apparently you're the first to build the 'thing', so thanks for pioneering!

[marceltrapman]

@Yveaux Not a problem, I like being a pioneer and I greatly appreciate the efforts you put into this

I thought I had everything in order this afternoon.
Installed Visual C++ Redistributable Packages for Visual Studio 2012 SP 4 but forgot to test...

Right now, whatever I use 'Visual C++ Redistributable Packages for Visual Studio 2012 SP 4' or (for testing purposes) 'Visual C++ Redistributable Packages for Visual Studio 2013' both x64 I still see the error message 'The program can't start because MSVCR110.dll is missing...'.
A restart should not be necessary but even a restart did not help.

Uninstalling all packages and reinstalling did not help either.

Any idea?

[marceltrapman]

For those following this topic I have not solved it but it could be related to this:
Upgrade to 8.1 and stuff stops working (not what most people would call an "up"-grade).

[marceltrapman]

OK, for those of you on Windows 8.1 this will probably not work 'out of the box'.

For me, a Mac user, the following solution makes complete sense

You have to install or repair Microsoft Essentials and the dll will be available.
Don't ask me why but it works!

[marceltrapman]

Everything works now.

Did not see any packets coming in though but I remember having an issue with a couple of Uno's and I am not sure if this was one of them.

Anyway, I will do some more testing tomorrow.
Very exited

[Yveaux]

@marceltrapman Great you got it working man!
In the meantime, please have a look at the last part I wrote, detailing the use of Wireshark and the sniffer: http://yveaux.blogspot.nl/2014/07/nrf24l01-sniffer-part-3.html

For tonight I'm totally done with this sniffer -- Aaaarghhh!

Btw. Could you also post stuff you had to do to get it working (just a wrapup) to my blog, to keep stuff together? Thanks!

[marceltrapman]

@Yveaux When I am sure that everything really works (including my Uno/Radio) I will sure write a wrap-up to you blog!

[Yveaux]

@marceltrapman said:

both x64

The console application is 32bits. I don't know if the 32 bits versions are included in the 64 bits installers...

[marceltrapman]

@Yveaux said:

The console application is 32bits. I don't know if the 32 bits versions are included in the 64 bits installers...

That was not the issue...

Below is the wrap-up that I also posted on your blog:

There are 3 things that I bumped into though that I would like to share with you and those that decide to use the sniffer.

1. Immediately after starting** 'Nrf24Sniff.exe -P6'** (the rest is default in my case) I got this error message 'The program can't start because MSVCR110.dll is missing...'. It basically complains that 'Visual C++ Redistributable Packages for Visual Studio 2012 SP 4' is not installed but that is not true. After doing a bit of searching I found that I needed to** install or repair 'Microsoft Essentials'**.
   Once this was done the program works as expected (don't ask me why, this must be pure MS genius).

2. Once Wireshark was started like described I noticed that the Nrf24Sniff console window displayed a *'Wait for sniffer to restart' *message. The author mentions that this will only take a few seconds but in my case I actually needed to reset the Arduino for it to go away. No exception.

3. After creating the correct setup in Wireshark I expected data to show up but it did not. I wondered why and ran a complete test to see that the Ardiuno was ok, radio sufficiently powered etc. but that was all ok. I then re-read the article and found that the author says 'when monitoring MySensors 1.4beta traffic (at non-default 1Mb/s)'. I completely missed this and that caused the issue.The MySensors 1.4beta is set to 250b/s by default. Once I started the sniffer like 'Nrf24Sniff.exe -P6 -r2' everything works as expected.

Now I have to find some time to read the third article so that I understand what happens on my screen

Anyway, good stuff and a big thank you goes to @Yveaux ...

[epierre]

@Yveaux can you do me a favour ? colord blind people cannot read red on black... they represent 10% of the population...

Also, does your software runs under nano

[marceltrapman]

@epierre said:

Also, does your software runs under nano

I can't think of a reason why it would not work.
Just try (once you can read the blog ).

[epierre]

@Yveaux ah a vb programmer... you need to install the msvcr110.dll msvcr110.dll t to make it start with wine. (does not work with mono...)

then I have wireshark but I don't understand what to do next...
"Connect Wireshark to \.\pipe\wireshark to continue..."

[epierre]

@marceltrapman yes but for the reason just above I can't... had to select all the text to read...

 mono Nrf24Sniff.exe 
 Cannot open assembly 'Nrf24Sniff.exe': File does not contain a valid CIL image.

[marceltrapman]

@epierre said:

@marceltrapman yes but for the reason just above I can't... had to select all the text to read...

I was really... Joking with you

BTW I can imagine that trying to make this work with wine will give you all sorts of issues that are hard to comment on for those that don't use it.

[Yveaux]

@marceltrapman said:

Below is the wrap-up that I also posted on your blog:

Ok, thanks again man!

[Yveaux]

@epierre said:

@Yveaux can you do me a favour ? colord blind people cannot read red on black... they represent 10% of the population...

What is red on black? Some coloring in Wireshark?
If so, I don't choose the colors, Wireshark does! I just mark it as 'warning'.
Have a look at Edit->Preferences->User Interface->Font and colors to see if you can change it to your likings.

AH, now I see what you mean! The text on my blog

Also, does your software runs under nano

I didn't test it, but don't see why it shouldn't!

[marceltrapman]

@Yveaux said:

What is red on black? Some coloring in Wireshark?

It is your blog.
Mostly white on black but, when highlighted, also red on black...

[Yveaux]

@marceltrapman Colors are not my top priority right now, but I'll put in on the list then. Thanks for the hint.

[Yveaux]

@epierre It's not written in vb! Shame on your! It's pure hardcore C!
If you get it to run on Linux (?) using Wine then let us know please!

[epierre]

@Yveaux yes I did... but I stopped here not knowing how to do it:

Connect Wireshark to \.\pipe\wireshark to continue...

[Yveaux]

@epierre It's in the blog: start a new command window and navigate to the wiresrak directory (c:\program files\wireshark)
Then run:

 wireshark -k -i \\.\pipe\wireshark

And it should automatically connect to the named pipe (which is written to from the nrf24sniff.exe tool) and start capturing.

[epierre]

@Yveaux yes but through wine are they POSIX compliant so my linux wireshark can connect to it ?

[Yveaux]

@epierre I guess not, as Linux uses files as named pipes and \.\pipe\wireshark is not a regular Linux file path...
Furthermore the Wireshark dissectors should compile on Linux, but I didn't test it.
You could try to also run windows Wireshark through Wine, maybe the named pipes will pass the data along just fine...

[Yveaux]

@marceltrapman said:

1. Once Wireshark was started like described I noticed that the Nrf24Sniff console window displayed a *'Wait for sniffer to restart' *message. The author mentions that this will only take a few seconds but in my case I actually needed to reset the Arduino for it to go away. No exception.

I changed the nrf24snif.exe to explicitly reset the Arduino (works for Uno) by lowering DTR/RTS lines. Should work for (most?) other Arduino's too, but I don't have any other to test one.
For me it seems to work now. Could you test if this works stable for you too?

Oh yeah, I added support for some status leds to the Sniffer, connected to A0..A4 and via resistors to GND:

• A0 sniffer monitoring (LED turns off during reset)
• A1 sniffer receiving a packet
• A2 sniffer transmitting (serially) a packet
• A3 new configuration received
• A4 buffer overflow

[marceltrapman]

@Yveaux Nice.

When I find the time I will test it for Uno and Mega.
Not sure that I have a free Nano right now.
Also not sure that I have a soldered Pro Mini.

[marceltrapman]

@Yveaux

Oh yeah, I added support for some status leds to the Sniffer, connected to A0..A4 and via resistors to GND:

• A0 sniffer monitoring (LED turns off during reset)
• A1 sniffer receiving a packet
• A2 sniffer transmitting (serially) a packet
• A3 new configuration received
• A4 buffer overflow

Maybe I should create a (little) shield for this that holds the radio as well.
Or just use a prototype board...

[Yveaux]

@marceltrapman Maybe all of the LEDs are a bit overkill, but the RX LED and maybe the buffer-full LED can seriously be handy.

[marceltrapman]

I only checked the UNO with the new sketch (no LEDs) and the new iteration of nrf24snif.exe and both work as expected...

@Yveaux Well done again!

[Yveaux]

@marceltrapman And? How did the testing go?
I fixed the Nrf24sniff.exe to use static linking so the msvcr110.dll should no longer be required.
Also fixed executable so it runs on WinXP now (untested...).

[marceltrapman]

@Yveaux To be honest, I have played with it a little but I have not come much further.
Spent my time this weekend on other things
Will let you know soon!

[Rasmus Eneman]

Could the line quality information be queried directly by the gateway so that it can be known without additional hardware?

[Yveaux]

@Rasmus-Eneman no, the nrf24 does not expose it. You can query the amount of retries it took before a message got an acknowledgement, which could be used as quality indication.

[Rasmus Eneman]

@Yveaux Okej, Thank You!

[marceltrapman]

@Yveaux said:

And? How did the testing go?

So, testing went well
I found a couple of malformed packets coming in so I will have to investigate that.
Yesterday evening I created my first shield, first double sided board and in fact the first true 'home brew' pcb in my entire life...

This is what it looks like (it is a bit of a mess because I messed up my via's the first time...

[Yveaux]

@marceltrapman Wooow! First 'official' sniffer PCB! (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
Anyway, thanks for the update!

[Yveaux]

@Sparkman said:

@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?

Very glad to hear that it's working now!

The LED_SUPPORTED being defined or not should only make a difference in code size, nothing else. The LED option was added after the sniffer was completely functional as some low-level indication of its status. It should work independent of LEDs being connected or not.

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

You're welcome! At least now I know the Mega's are also supported

[Sparkman]

@Yveaux said:

Very glad to hear that it's working now!

The LED_SUPPORTED being defined or not should only make a difference in code size, nothing else. The LED option was added after the sniffer was completely functional as some low-level indication of its status. It should work independent of LEDs being connected or not.

That's what I had thought as well, so not sure why it started working.

@Yveaux said:

You're welcome! At least now I know the Mega's are also supported

And the Pro Mini too!

Cheers
Al

[Sparkman]

In case anyone else is interested, I updated the sketch to work with a 20x4 LCD screen so that you can see how many packets have been captured. I used this LCD screen connected to the I2C interface. Make sure you get the correct LCD libraries for it as the default LCD libraries don't work with it. There's a link for them on the eBay page.

EDIT: There seems to be an issue capturing packets if it's also connected to the nrf24sniff program. It works fine standalone and also when BINARY_OUTPUT is undefined and talking to the Serial Monitor. I'l need to do more troubleshooting as to why.

Cheers
Al

/*
  NRF24_Sniff - An Arduino sketch to promiscuous capture all wireless
                traffic generated by Nordic Semi. NRF24L01+ modules.

  Created by Ivo Pullens, Emmission, 2014 -- www.emmission.nl
  Updated by Sparkman, 2015 - added LCD support

  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/   
 
#include <Arduino.h>
#include <SPI.h>
#include <CircularBuffer.h>
#include <RF24.h>
#include <RF24_config.h>

#include <Wire.h>
#include <LiquidCrystal_I2C.h>

#define LED_SUPPORTED
#define LCD_SUPPORTED

// Hardware configuration
#define RF_CE_PIN                      (9)
#define RF_CS_PIN                      (10)
#define RF_IRQ_PIN                     (2)
#define RF_IRQ                         (RF_IRQ_PIN-2)                                           // Usually the interrupt = pin -2 (on uno/nano anyway)

#ifdef LED_SUPPORTED
	#define LED_PIN_LISTEN         (A0)
	#define LED_PIN_RX             (A1)
	#define LED_PIN_TX             (A2)
	#define LED_PIN_CONFIG         (A3)
	#define LED_PIN_BUFF_FULL      (A4)
#endif

#ifdef LCD_SUPPORTED
	LiquidCrystal_I2C lcd(0x27,20,4);  // set the LCD address to 0x27 for a 20 chars and 4 line display
#endif

static uint32_t PacketCount = 0;
static uint8_t lostPacketCount = 0;

#define RF_MAX_ADDR_WIDTH              (5)                                                      // Maximum address width, in bytes. MySensors use 5 bytes for addressing, where lowest byte is for node addressing.
#define MAX_RF_PAYLOAD_SIZE            (32)
#define SER_BAUDRATE                   (115200)
#define PACKET_BUFFER_SIZE             (30)                                                     // Maximum number of packets that can be buffered between reception by NRF and transmission over serial port.
#define PIPE                           (0)                                                      // Pipe number to use for listening

// Startup defaults until user reconfigures it
#define DEFAULT_RF_CHANNEL             (76)                                                     // 76 = Default channel for MySensors.
#define DEFAULT_RF_DATARATE            (RF24_250KBPS)                                           // Datarate
#define DEFAULT_RF_ADDR_WIDTH          (RF_MAX_ADDR_WIDTH)                                      // We use all but the lowest address byte for promiscuous listening. First byte of data received will then be the node address.
#define DEFAULT_RF_ADDR_PROMISC_WIDTH  (DEFAULT_RF_ADDR_WIDTH-1)
#define DEFAULT_RADIO_ID               ((uint64_t)0xA8A8E1FC00LL)                               // 0xA8A8E1FC00LL = MySensors v2 (1.4) default
#define DEFAULT_RF_CRC_LENGTH          (2)                                                      // Length (in bytes) of NRF24 CRC
#define DEFAULT_RF_PAYLOAD_SIZE        (MAX_RF_PAYLOAD_SIZE)                                    // Define NRF24 payload size to maximum, so we'll slurp as many bytes as possible from the packet.

// If BINARY_OUTPUT is defined, this sketch will output in hex format to the PC.
// If undefined it will output text output for development.
#define BINARY_OUTPUT

#include "NRF24_sniff_types.h"

#ifndef BINARY_OUTPUT
	int my_putc( char c, FILE *t )
	{
	  Serial.write( c );
	}
#endif

// Set up nRF24L01 radio on SPI bus plus CE/CS pins
static RF24 radio(RF_CE_PIN, RF_CS_PIN);

static NRF24_packet_t bufferData[PACKET_BUFFER_SIZE]; 
static CircularBuffer<NRF24_packet_t> packetBuffer(bufferData, sizeof(bufferData)/sizeof(bufferData[0]));
static Serial_header_t serialHdr;
static volatile Serial_config_t conf = {
	DEFAULT_RF_CHANNEL,     DEFAULT_RF_DATARATE, DEFAULT_RF_ADDR_WIDTH,
	DEFAULT_RF_ADDR_PROMISC_WIDTH,  DEFAULT_RADIO_ID,    DEFAULT_RF_CRC_LENGTH,
	DEFAULT_RF_PAYLOAD_SIZE
	};

#define GET_PAYLOAD_LEN(p) ((p->packet[conf.addressLen-conf.addressPromiscLen] & 0xFC) >> 2) // First 6 bits of nRF header contain length.


inline static void dumpData(uint8_t* p, int len)
{
	#ifndef BINARY_OUTPUT
		while (len--) { printf("%02x", *p++); }
		Serial.print(' ');
	#else
		Serial.write(p, len);
	#endif
}

static void handleNrfIrq()
{
	// Loop until RX buffer(s) contain no more packets.
	while (radio.available())
	{
		#ifdef LED_SUPPORTED
			digitalWrite(LED_PIN_RX, HIGH);
		#endif
		if (!packetBuffer.full())
		{
			#ifdef LED_SUPPORTED
				digitalWrite(LED_PIN_BUFF_FULL, LOW);
			#endif

			NRF24_packet_t* p = packetBuffer.getFront();
			p->timestamp = micros();  // Micros does not increase in interrupt, but it can be used.
			p->packetsLost = lostPacketCount;
			uint8_t packetLen = radio.getPayloadSize();
			if (packetLen > MAX_RF_PAYLOAD_SIZE)
				packetLen = MAX_RF_PAYLOAD_SIZE;
		  
			radio.read( p->packet, packetLen );
		      
			// Determine length of actual payload (in bytes) received from NRF24 packet control field (bits 7..2 of byte with offset 1)
			// Enhanced shockburst format is assumed!
			if (GET_PAYLOAD_LEN(p) <= MAX_RF_PAYLOAD_SIZE)
			{
				// Seems like a valid packet. Enqueue it.
				packetBuffer.pushFront(p);
				PacketCount++;
			}    
			else
			{
			// Packet with invalid size received. Could increase some counter...
			}
			lostPacketCount = 0;
		}
		else
		{
			// Buffer full. Increase lost packet counter.
			#ifdef LED_SUPPORTED
				digitalWrite(LED_PIN_BUFF_FULL, HIGH);
			#endif

			bool tx_ok, tx_fail, rx_ready;
			if (lostPacketCount < 255)
				lostPacketCount++;
			// Call 'whatHappened' to reset interrupt status.
			radio.whatHappened(tx_ok, tx_fail, rx_ready);
			// Flush buffer to drop the packet.
			radio.flush_rx();
		}
		#ifdef LED_SUPPORTED
		    digitalWrite(LED_PIN_RX, LOW);
		#endif
	}
}  

static void activateConf( void )
{
	#ifdef LED_SUPPORTED
		digitalWrite(LED_PIN_CONFIG, HIGH);
	#endif

	// Match MySensors' channel & datarate
	radio.setChannel(conf.channel);
	radio.setDataRate((rf24_datarate_e)conf.rate);

	// Disable CRC & set fixed payload size to allow all packets captured to be returned by Nrf24.
	radio.disableCRC();
	radio.setPayloadSize(conf.maxPayloadSize);

	// Configure listening pipe with the 'promiscuous' address and start listening
	radio.setAddressWidth(conf.addressPromiscLen);
	radio.openReadingPipe( PIPE, conf.address >> (8*(conf.addressLen - conf.addressPromiscLen)) );
	radio.startListening();

	// Attach interrupt handler to NRF IRQ output. Overwrites any earlier handler.
	attachInterrupt(RF_IRQ, handleNrfIrq, FALLING);    // NRF24 Irq pin is active low.

	// Initialize serial header's address member to promiscuous address.
	uint64_t addr = conf.address;  // TODO: probably add some shifting!
	for (int8_t i = sizeof(serialHdr.address)-1; i >= 0; --i)
	{
		serialHdr.address[i] = addr;
		addr >>= 8;
	}

	// Send config back. Write record length & message type
	uint8_t lenAndType = SET_MSG_TYPE(sizeof(conf), MSG_TYPE_CONFIG);
	dumpData(&lenAndType, sizeof(lenAndType));
	// Write config
	dumpData((uint8_t*)&conf, sizeof(conf) );

	#ifndef BINARY_OUTPUT
		Serial.print("Channel:     "); Serial.println(conf.channel);
		Serial.print("Datarate:    ");
		switch (conf.rate)
		{
			case 0: Serial.println("1Mb/s"); break;
			case 1: Serial.println("2Mb/s"); break;
			case 2: Serial.println("250Kb/s"); break;
		}
		Serial.print("Address:     0x");
		uint64_t adr = conf.address;
		for (int8_t i = conf.addressLen-1; i >= 0; --i)
		{
			if ( i >= conf.addressLen - conf.addressPromiscLen )
			{
				Serial.print((uint8_t)(adr >> (8*i)), HEX);
			}
			else
			{
				Serial.print("**");
			}
		}
		Serial.println("");
		Serial.print("Max payload: "); Serial.println(conf.maxPayloadSize);
		Serial.print("CRC length:  "); Serial.println(conf.crcLength);
		Serial.println("");
		 
		radio.printDetails();

		Serial.println("");
		Serial.println("Listening...");
	#endif
	#ifdef LED_SUPPORTED
		digitalWrite(LED_PIN_CONFIG, LOW);
	#endif
	#ifdef LCD_SUPPORTED
		lcd.setCursor(0, 0);
		lcd.print("CH ");
		lcd.print(conf.channel);

		switch (conf.rate)
		{
			case 0: lcd.print(" @ 1Mb/s"); break;
			case 1: lcd.print(" @ 2Mb/s"); break;
			case 2: lcd.print(" @ 250kb/s"); break;
		}
	#endif

}

void setup(void)
{
	#ifdef LED_SUPPORTED
		pinMode(LED_PIN_LISTEN,    OUTPUT);
		pinMode(LED_PIN_RX,        OUTPUT);
		pinMode(LED_PIN_TX,        OUTPUT);
		pinMode(LED_PIN_CONFIG,    OUTPUT);
		pinMode(LED_PIN_BUFF_FULL, OUTPUT);
		digitalWrite(LED_PIN_LISTEN,    LOW);
		digitalWrite(LED_PIN_RX,        LOW);
		digitalWrite(LED_PIN_TX,        LOW);
		digitalWrite(LED_PIN_CONFIG,    LOW);
		digitalWrite(LED_PIN_BUFF_FULL, LOW);
	#endif

	#ifdef LCD_SUPPORTED
		lcd.init();                      // initialize the lcd 
		lcd.backlight();
		lcd.clear();
		lcd.home();
	#endif

	Serial.begin(SER_BAUDRATE);

	#ifndef BINARY_OUTPUT
		fdevopen( &my_putc, 0);
		Serial.println("-- RF24 Sniff --");
	#endif

	radio.begin();

	// Disable shockburst
	radio.setAutoAck(false);
	radio.setRetries(0,0);

	// Configure nRF IRQ input
	pinMode(RF_IRQ_PIN, INPUT);

	#ifdef LED_SUPPORTED
		digitalWrite(LED_PIN_LISTEN, HIGH);
	#endif
	#ifdef LCD_SUPPORTED
		lcd.setCursor(0, 1);
		lcd.print(PacketCount);
		lcd.print(" Packets");
		lcd.setCursor(0, 2);
		lcd.print(lostPacketCount);
		lcd.print(" Lost Packets");
	#endif

	activateConf();
}

void loop(void)
{
	while (!packetBuffer.empty())
	{
		#ifdef LED_SUPPORTED
			digitalWrite(LED_PIN_TX, HIGH);
		#endif

		// One or more records present
		NRF24_packet_t* p = packetBuffer.getBack();
		int serialHdrLen = sizeof(serialHdr) - (conf.addressLen - conf.addressPromiscLen);
		serialHdr.timestamp   = p->timestamp;
		serialHdr.packetsLost = p->packetsLost;
	 
		// Calculate data length in bits, then round up to get full number of bytes.
		uint8_t dataLen = (    (serialHdrLen<<3)                 /* Serial packet header */
			+ ((conf.addressLen - conf.addressPromiscLen)<<3) /* NRF24 LSB address byte(s) */
			+ 9                                      /* NRF24 control field */
			+ (GET_PAYLOAD_LEN(p) << 3)                /* NRF24 payload length */
			+ (conf.crcLength << 3)                   /* NRF24 crc length */
			+ 7                                      /* Round up to full nr. of bytes */
			) >> 3;                                     /* Convert from bits to bytes */

		// Write record length & message type
		uint8_t lenAndType = SET_MSG_TYPE(dataLen, MSG_TYPE_PACKET);
		dumpData(&dataLen, sizeof(lenAndType));
		// Write serial header
		dumpData((uint8_t*)&serialHdr, serialHdrLen );
		// Write packet data
		dumpData(p->packet, dataLen - serialHdrLen);

		#ifndef BINARY_OUTPUT
			if (p->packetsLost > 0)
			{
				Serial.print(" Lost: "); Serial.print(p->packetsLost);
			}
			Serial.println(""); 
		#endif
		// Remove record as we're done with it.
		packetBuffer.popBack();
		#ifdef LED_SUPPORTED
			digitalWrite(LED_PIN_TX, LOW);
		#endif
	}

	#ifdef LCD_SUPPORTED
		lcd.setCursor(0, 1);
		lcd.print(PacketCount);
		lcd.print(" Packets");
		lcd.setCursor(0, 2);
		lcd.print(lostPacketCount);
		lcd.print(" Lost Packets");
	#endif
 
	// Test if new config comes in
	uint8_t lenAndType;
	if (Serial.available() >= sizeof(lenAndType) + sizeof(conf))
	{
		lenAndType = Serial.read();
		if ((GET_MSG_TYPE(lenAndType) == MSG_TYPE_CONFIG) && (GET_MSG_LEN(lenAndType) == sizeof(conf)))
		{
			// Disable nRF interrupt while reading & activating new configuration.
			noInterrupts();
			// Retrieve the new configuration
			uint8_t* c = (uint8_t*)(&conf);
			for (uint8_t i = 0; i < sizeof(conf); ++i)
			{
				*c++ = Serial.read();
			}
			// Clear any packets in the buffer and flush rx buffer.
			packetBuffer.clear();
			radio.flush_rx();
			// Activate new config & re-enable nRF interrupt.
			activateConf();
			interrupts();
		}
		else
		{
			#ifndef BINARY_OUTPUT
				Serial.println("Illegal configuration received!"); 
			#endif
			#ifdef LCD_SUPPORTED
				lcd.setCursor(0, 3);
				lcd.print("Illegal Config");
			#endif
		}
	}
}

[Yveaux]

It would be a noce idea to create a portable 'sniffer' which you could easily position around the house (compared to a laptop + sniffer).
If it could do charts like Wireshark, e.g.

it would be very easy to determine signal quality and the like!
Requires dissection on the sinffer, though.

[Sparkman]

@Yveaux Yes, creating a portable one is my target. I will need to learn more about the rf24 though. I also want to include a ping utility to allow coverage testing.

Cheers
Al

[marceltrapman]

So, remember that pcb I showed earlier.
This is what it looks like with a 3D printed green glow in the dark case around it

[maltimus]

A portable version of the nRF24L01+ sniffer could be extremely useful. Anyone know if it would be possible to combining a nRF24L01+ and an ESP8266 into an Arduino giving it the capability to transmit the nRF24L01+ data over WIFI to a computer running wireshark? I dont have the time to research the possibility right now, but will keep this in mind for the future.

[Yveaux]

@marceltrapman This thing looks psychedelic!

[Alain69]

Hello,
Great job !!! I am French so excuse my broken English. Does someone could guide me? At launch Wireshark, I have a message systematically "tvb_lenght The procedure entry point is not found in the dynamic link library \ Program Files (x86) \ Wireshark \ plugins \ 1.12.4 \ mysensors1.dll" then same for mysensors2, nrf24.dll, radiohead.dll. I'm sure I added DLL in Wireshark, and tried the 64b version and the 32b, under Windows 8.1. If someone has an idea, THANK YOU

[Sparkman]

@Alain69 Which version of WireShark are you using? Try it with the older version that's available for download. The sniffer does not work with the latest versions.

Cheers
Al

[gonzalonal]

Hi, Nice job what yoh've done here.
Awkardly, I am not able to compile the sketch. I have download the last version available form github, but when I try to compile it, the IDE hungs about 60% and nothingelse happens. The compiler log looks like this:

Utilizando biblioteca SPI en carpeta: C:\Program Files\Arduino\hardware\arduino\avr\libraries\SPI
Utilizando biblioteca CircularBuffer_Sniff en carpeta: C:\Users\arnalbago\Documents\Arduino\libraries\CircularBuffer_Sniff (legacy)
Utilizando biblioteca RF24-master en carpeta: C:\Users\arnalbago\Documents\Arduino\libraries\RF24-master (legacy)
Utilizando biblioteca RF24_Sniff en carpeta: C:\Users\arnalbago\Documents\Arduino\libraries\RF24_Sniff (legacy)

C:\Program Files\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10604 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\eightanaloginputs -IC:\Program Files\Arduino\hardware\arduino\avr\libraries\SPI -IC:\Users\arnalbago\Documents\Arduino\libraries\CircularBuffer_Sniff -IC:\Users\arnalbago\Documents\Arduino\libraries\RF24-master -IC:\Users\arnalbago\Documents\Arduino\libraries\RF24_Sniff C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\NRF24_sniff.cpp -o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\NRF24_sniff.cpp.o
C:\Program Files\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10604 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\eightanaloginputs -IC:\Program Files\Arduino\hardware\arduino\avr\libraries\SPI -IC:\Users\arnalbago\Documents\Arduino\libraries\CircularBuffer_Sniff -IC:\Users\arnalbago\Documents\Arduino\libraries\RF24-master -IC:\Users\arnalbago\Documents\Arduino\libraries\RF24_Sniff C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24.cpp -o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\SPI\SPI.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24-master\RF24.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24_Sniff\RF24.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\hooks.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\WInterrupts.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring_analog.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring_digital.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring_pulse.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\wiring_shift.c.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\abi.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\CDC.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial0.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial1.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial2.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HardwareSerial3.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\HID.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\IPAddress.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\main.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\new.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\Print.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\Stream.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\Tone.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\USBCore.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\WMath.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\WString.cpp.o
Utilizando archivo previamente compilado: C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\core.a
C:\Program Files\Arduino\hardware\tools\avr/bin/avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp/NRF24_sniff.cpp.elf C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\NRF24_sniff.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\SPI\SPI.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24-master\RF24.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp\RF24_Sniff\RF24.cpp.o C:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp/core.a -LC:\Users\ARNALB~1\AppData\Local\Temp\build2068833823121923998.tmp -lm

Does anyone know what could be happening with this?
I would appreciate any help you can provide.

Thanks, regards.

[Yveaux]

@gonzalonal I reproduced compiling the latest version on Github with Arduino IDE 1.6.5.
It compiles without problems on my IDE, on Windows.
Some things you can try:

• Reinstall the Arduino IDE and/or make sure you're using 1.6.5
• Extract the NRF24 Sniffer source code to its own sketchbook location. Don't put any other stuff in there (e.g. no MySensors libraries). Point the Arduino IDE to this location (File -> Preferences -> Sketchbook location, save and restart the IDE)

Good luck!

[gonzalonal]

@Yveaux
Thanks Yveaux. Pointing the sketch path in the right direction made the trick.
Once again, thanks.

Regards.

[hoegaarden_bier]

Is there anyone who has the Wireshark dissectors for the latest 1.5 api?
Mine is complaining about "The Procedure entry point tvb_length could not be located in the DLL library libwireshark.dll"

[Yveaux]

@hoegaarden_bier use the Wireshark version as defined on my blog. Possibly the portable version of Wireshark.
Wireshark keeps changing their dissector api so sure to lack of time I stopped updating them.

[freeck]

Hi there,

The (my ) sniffer tool has trouble interpretating float values, received from temperature/humidity sensors.
The data payload indicates that the sniffer receives 5 bytes instead of the expected 4 bytes of the float32 variable, the extra byte is always a 0x01. The preceeding 4 bytes are the expected bytes of the float.
After swapping the hardware, both cpu and nrf24 , still the same result....
Integers and booleans are received OK, and my serial gateway receives the correct float values.

[Yveaux]

@freeck iirr float decoding was not implemented yet in the Wireshark dissector.

[freeck]

@Yveaux
Hi, thanks for the quick response....
But I do not understand: I get float values on my screen but the wrong interpretation.
Perhaps a better question: is there an indication when this will be solved, as I appreciate the sniffer tool very much!?

[Yveaux]

@freeck
@Yveaux said:

was not implemented yet

Maybe I should rephrase: it was implemented, but doesn't work right
See: https://github.com/Yveaux/NRF24_Sniffer/issues/2

For MySensors 2.0 the sniffer will have to be updated.
I might pick this one up along the way.

[bilbolodz]

@Yveaux said in Wireless nRF24L01+ sniffer for MySensors:

For MySensors 2.0 the sniffer will have to be updated.
Any chance for Mysensrs 2.1.1 support?

[Yveaux]

@bilbolodz not from my side anywhere soon... Just too busy...

[bilbolodz]

@Yveaux Sad to hear that.

[tonbor]

Wireshark is version 3, MySensors 2.3.1 released 2018. nrf24 protocol with old dll is not working. Cost me hours tot find out it is "Oude Meuk", and not working with Wireshark error message "dissector not found". Please @Hek and @Yveaux release working version or wipe it from the forum at many places, PLEASE!

[Yveaux]

@tonbor said in Wireless nRF24L01+ sniffer for MySensors:

Wireshark is version 3, MySensors 2.3.1 released 2018. nrf24 protocol with old dll is not working. Cost me hours tot find out it is "Oude Meuk", and not working with Wireshark error message "dissector not found".

MySensors protocol support for 1.x and 2.x is included. The protocol 2.x hasn't changed for 2.3.1
The wireshark version referenced from the blog (1.10.8) still works with the included dlls. The Wireshark devs make it nearly impossible to create a dissector that compiles with newer versions as the wireshark api keeps changing.

This 'oude meuk' is still working as released.

[tonbor]

@yveaux Well this is your description: "Installation As you can see in the description above, the console application and Wireshark dissectors are currently only available for Windows (anyone who volunteers to port them to Linux and/or Mac, please do so and let me know). In the description below I assume you've already downloaded and installed: Wireshark - I used 1.10.8, either 32- or 64-bits"

Well I suppose you meant it is only working with Wireshark - 1.10.8, that's really only using "Oude Meuk" Sorry I wasted my time, and I see too late more people did.

[mfalkvidd]

@tonbor you’ve been a member here long enough to know that this forum is a place for people helping eachother.

I understand that you are frustrated, but if everyone in a diy community who ever got frustrated were to get angry on the other people who tried to help, the world would be full with angry people.

[tonbor]

Indeed, helping each other is not pointing with kingsize letters to obsolete software or leaving the thread there without any warning. Sorry if I was carried away with my anger after trying for a day to get things working.

[tonbor]

https://www.filepuma.com/download/wireshark_64bit_1.10.8-6009/download/
with a little help from my friends ……..

[TRS-80]

Did anyone ever get this working in Linux? Possibly with Wine?

Unless I missed it somewhere, from what I could tell reading the thread, it doesn't look like it.

[apharvey99]

Hi, I have the sniffer and wireshark running to capture a 256kbps MySensors 2.3.1 network which is part of a working home automation setup. It does capture some packets over a test period of a few minutes but the sniffer program (in verbose mode) reports it is missing several thousand packets. Also, the hundred or so packets that it has captured appear unintelligible in wireshark. Can anyone tell me what parameters I should be using when I start the nrf24sniffer program please ? I think I have some parameters incorrectly set. Many thanks for any advice you can offer.

[Yveaux]

@apharvey99 said in Wireless nRF24L01+ sniffer for MySensors:

... but the sniffer program (in verbose mode) reports it is missing several thousand packets.

What message do you get? The one in https://github.com/Yveaux/NRF24_Sniffer/blob/master/SerialToPipe/src/Nrf24Sniff/Nrf24Sniff.cpp#L445 ?

If you see packets coming in the nRF24 at least detects the packets on air.

What parameters do you use in your setup, and when calling the Nrf24Sniff executable?
Did you compile the binaries yourself or used precompiled ones?
Did you #define BINARY_OUTPUT in the Arduino sketch?

I really need more input to be able to help...

[apharvey99]

@Yveaux Hi, thanks for your reply. Sorry I didn’t provide more information at first. I do have Binary output defined in the nrf24sniff Arduino sketch.

I have rerun the data collection and the screenshot below shows my nrf24sniff startup parameters, the output I get from nrf24sniff and the output from Wireshark. As you can see, in wireshark even the source and destination address of the MySensors 2.3.1 packets are not visible, neither is the payload.

I don’t fully understand what I’m doing with this but am trying to follow your very helpful instructions to be able to view the nrf24 data packets that my home automation system is clearly sending as it is working fine. I am obviously doing something wrong so your help would be very welcome. Thank you.

[Yveaux]

@apharvey99 From the Wireshark capture you can see the packets coming in at an extremely high rate. Also the packet data is all zeroes, except for the node address.
You say you are monitoring your home automation system. Is it a MySensors network?