Wireless nRF24L01+ sniffer for MySensors
-
@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\wiresharkAnd it should automatically connect to the named pipe (which is written to from the nrf24sniff.exe tool) and start capturing.
-
@Yveaux yes but through wine are they POSIX compliant so my linux wireshark can connect to it ?
@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 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.
-
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). -
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.
-
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 ...
@marceltrapman said:
- 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 said:
- 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 said:
- 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
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... -
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... -
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 :) -
@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...). -
Could the line quality information be queried directly by the gateway so that it can be known without additional hardware?
-
Could the line quality information be queried directly by the gateway so that it can be known without additional hardware?
-
@Yveaux Okej, Thank You!
-
@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...).@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 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...

-
Ok, brace yourself! :zap:
I finally had the time to write on my blog about the wireless network sniffer I've been working on lately.
For the impatient see:- http://yveaux.blogspot.nl/2014/07/nrf24l01-sniffer-part-1.html
- http://yveaux.blogspot.nl/2014/07/nrf24l01-sniffer-part-2.html
- http://yveaux.blogspot.nl/2014/07/nrf24l01-sniffer-part-3.html
This wireless sniffer allows you to capture traffic on air between multiple nodes of your MySensors network and is able to even capture packets with invalid CRC Values. The amount of CRC errors gives a fair indication of link quality, which is not provided by the nRF24.
The sniffer in action:
http://www.youtube.com/embed/wxjxm0LnkAkActual capturing is performed by an nRF24L01+ module connected to an Arduino (we all known how to do that ;-) ). No other hardware is required.
A small piece of software (currently only for Windows, sorry @hek) reads the packet data from the sniffer and forwards it to Wireshark, a network protocol analyzer.
Wireshark then allows you to inspect the packages from high-level down to the individual bits, filter by content, and analyze statistics.
Details are all in the blog posts. Last post in this series, which is yet to be written, will dive into using Wireshark and getting useful information from it.
I didn't want to keep this tool to myself until finally finished and documented, so there can (will?) still be some bugs left...Please discuss any issues/ideas/suggestions in here or in my blog.
Happy sniffin' to all of you!
This post is deleted! -
@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.
@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 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?
@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 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?
@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 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 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!!!