Project

General

Profile

nRfMon - RFM12B forensics

Added by dzach over 7 years ago

nRf Mon is coming of age and now has it’s own project page in JeeLabs. The project page will eventually become a guide on how to use the nRf Mon spectrum analyzer. The code is in github .

Sample Display:

Full Control Panel:

Transceiver settings
Quick Settings:

Quick settings


Replies (244)

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

Thanks JohnO. I’ll try to run jcw’s code and see what comes out before I start with it. That’ll probably be tomorrow evening, with a friend’s WinXP PC.

RE: nRfMon - RFM12B forensics - Added by tve over 7 years ago

Minor issue compiling rf12mon.ino: I had to forward-declare two functions:

diff --git a/rf12mon/rf12mon.ino b/rf12mon/rf12mon.ino
index 4bb1ba0..abfbb43 100644
--- a/rf12mon/rf12mon.ino
+++ b/rf12mon/rf12mon.ino
@@ -4,6 +4,9 @@

 #include 

+void setGroup (byte group);
+static void rfmon_reset ();
+
 /*
   Change the last part in the next line to reflect the hardware signature that'll be shown on the R
   The signature is a dictionary, i.e. should be pairs of key/value, where the last pair is the hard

Also, I tried the ARSSI by jumpering the module cap to ADC5, but I don’t get anything reasonable looking (915Mhz band), see attached screen shot. The circled areas do show when I was transmitting from another node, so I am seeing RSSI data, but some scale is off. I’ll wait for the next installment of ARSSI improvements :-).

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

tve, thanks for the report!

I guess I should have removed the ARSSI code from the sketch, since nRfMon is not up to the job yet. There is a need to modify certain nRfMon parameters to be able to scale the ARSSI signal and display more than 8 signal levels. The change to binary scan data has already been done but ARSSI values must be scaled to the new max. Your screenshot shows it clearly: the yellow waterfall and dBm values and the bleeding spectrum plot at the bottom show wrong limit calculations based on 8 level RSSI.

Good to see that //./comX works for ports above com9 in Windows. I hope to have jcw’s serial port discovery code for Windows included to nRfMon soon, so that the gap between Linux and Win is closed for serial ports.

The rfmon_reset and setGroup functions are used before they are declared in the rf12mon.ino sketch. I’ll rearrange the code to fix this.

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

It looks like jcw’s code for serial port enumeration in Windows works nicely in nRfMon:

Will include it in the next version v0.7.2 coming up, together with some additions for displaying packet data in nRfMon’s console as raw chars, binary stream, hex or decimal numbers.

RE: nRfMon - RFM12B forensics - Added by tve over 7 years ago

dzach: I’m looking forward to the updates, it’s a very, very cool tool overall! THANK YOU! Having the windows binary was very helpful as I don’t have TCL installed. Is there a reason you’re not including hex files for the sketches, that would have saved me ~20 minutes?

WRT the RSSI representation, if I understand correctly, you’re currently using ‘0’..‘7’ for 8 levels? If so, it would be pretty easy to grab the character sequence for base64 encoding and use that. You’d then get 64 levels encoded in one character without any special-char concerns. While 64 != 256 it’s probably close enough to the margin of error and general noise not to matter. just my 2 cents…

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

Version v0.7.2 with binaries for Linux and Windows is in github


Bad CRC packet header and data. Data here is displayed as hexadecimal words.

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

Thanks tve!

tve wrote:
> You’d then get 64 levels encoded in one character without any special-char concerns.

The code is already in place for 256 levels, and I have successfully displayed them in nRfMon but to include that hack in a normal release I need to do thorough testing of all parameters, and that’s something I haven’t done yet. In your case displayed above, you successfully receive 256 levels but the display thinks it has only 8 levels so the waterfall gets saturated and shows maximum signal (that’s the yellow color). Maybe you could try use the Auto contrast setting and see what happens.

RE: nRfMon - RFM12B forensics - Added by dabbishaw over 7 years ago

I think that rfmon is great, very impressed what you’ve managed to put together. But I’m being dumb and I don’t understand what its telling me.

I’ve attached a screen shot, I think that this it telling me that there are four different devices all operating in the same band and that there a lot of background interference, so there’s no natural gap to choose for the best range etc.

I think that the center yellow band are my jeenodes talking.

Any thoughts?

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

Hi dabbishaw. The RFM12B module is a little miracle so undoubtedly there is a need for proper documentation for nRfMon; the one in the wiki is now outdated.

dabbishaw wrote:
> I think that this it telling me that there are four different devices all operating in the same band and that there a lot of background interference, so there’s no natural gap to choose for the best range etc.
>
> I think that the center yellow band are my jeenodes talking.

Probably not. The jeenode’s transmission is very brief (unless you transmit data continuously) but the signals in your screenshot seem to be continuous. So they are most probably harmonics of some clock signal(s) in the vicinity, either of the JeeNode or other electronic equipment, like the PC it is connected to.

Judging from my own JeeNode, you seem to get a rather homogeneous noise background, of normal overall power (abt 103 dBm). If you would like to see clearly how a continuous transmission looks, just upload rf12mon.ino to another JeeNode and watch it automatically transmit bursts of the Bit Error Rate Test pattern. It does it by default; no need to have it connected to a PC after you upload the sketch.
Using the Auto contrast feature exaggerates the week signals and they show up kind of scary. However, it does help identify frequencies with less noise, like around 861.5MHz in your case. Turning it off allows the waterfall display to show colors corresponding more or less to the absolute signal strength. You can also turn on Hold max and see, after a while, what frequency has the least noise and maybe tune your nodes there.
You can also switch to Listen mode and watch the transmissions of your nodes as they happen. You will have to set nRfMon to match your nodes’ settings, i.e. channel (or Freq.), RX bandwidth and, most importantly, the Rate setting. The defaults in nRfMon are the ones of jcw’s RF12demo.ino . You will probably need to set Print packet data to something other than raw to be able to read the values in the packets.
I hope the above can help find some use for nRfMon. Otherwise it’s like watching the snowy screen of an old TV set; there is nothing to see there :
)

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

I should add that, even if the waterfall display shows some frequencies as having less noise, one should make sure the desired signal is also good, by measuring the signal strength of the desired transmission; theoretically, there is a possibility that the receiver sensitivity/transmitter output is reduced around the edges of the band. What matters actually is the ratio Signal/Noise (S/N); that ratio needs to be maximized to achieve the best results.

RE: nRfMon - RFM12B forensics - Added by JohnO over 7 years ago

I have tested the latest git code on Win7x64 and I can see a problem using COM33 as the connection to the JeeNode. I tested operation fine with COM4 and all was well. I then used device manager to change to COM port to 33. I am able to access COM33 using Putty async terminal. When I try to link nRFMon to COM33 I see:

● nRfMon v0.7.2
(C) 2013,D.Zachariadis
Licensed under the GPLv3
couldn't open "com33": no such file or directory
. Disconnected
► 

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

@JohnO, have you tried using //./com33 instead of com33?
Do you enter the port manually? What happens if you use one of the ports appearing in the Port: combobox at the upper right of nRfMon’s window?

RE: nRfMon - RFM12B forensics - Added by wiso over 7 years ago

JohnO, does using //./comX work? Was this version meant to access higher numbered ports?

(oops, dzach beat me to it!)

RE: nRfMon - RFM12B forensics - Added by JohnO over 7 years ago

Ah, it works fine if I select from the pulldown. An unusual technique, where may I find out more about the //./ feature.

RE: nRfMon - RFM12B forensics - Added by JohnO over 7 years ago

dzach - I was indeed manually entering “com33”.

RE: nRfMon - RFM12B forensics - Added by JohnO over 7 years ago

Will it be possible to use a 433MHz RFM12B to scan the 433Mhz range? Similar question I guess for 915Mhz for our US friends.

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

JohnO wrote:
> Ah, it works fine if I select from the pulldown. An unusual technique, where may I find out more about the //./ feature.

I was enlightened by this wiki page: http://wiki.tcl.tk/1838

> Will it be possible to use a 433MHz RFM12B to scan the 433Mhz range? Similar question I guess for 915Mhz for our US friends.

Definitely. I have too acquired some 433MHz modules and will be trying them soon. If you do it, please post some screenshots; they are very useful for reference.

RE: nRfMon - RFM12B forensics - Added by MichelV over 7 years ago

maybe a little off topic, but TI has a deal going on since yesterday for a frequency analyzer (see this thread as well).

Thought it might interest you guys as well, if not for the hardware, perhaps just for the documentation of the thing :-).

RE: nRfMon - New version v0.7.3 - Added by dzach over 7 years ago

New version v0.7.3, fixes some issues with printing packet data and adds a new control to hide/show the spectrum line, helping display an uncluttered Hold max plot that’s easier to use:

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

MichelV wrote:
> Thought it might interest you guys as well, if not for the hardware, perhaps just for the documentation of the thing :).
Thanks MichelV! Useful indeed to see what the competition is doing. They can’t beat us in price though :
)

RE: nRfMon - RFM12B forensics - Added by MichelV over 7 years ago

Hehe, definately not :) Especially if it’s possible to add 3 RMF12B’s to one JeeNode, so you have the same frequency range :)

RE: nRfMon - RFM12B forensics - Added by dzach over 7 years ago

If JeeLib can handle 3 RFM12Bs by properly addressing them, then nRfMon will be there to use them.

RE: nRfMon - version v0.7.4 - Added by dzach over 7 years ago

Windows users are probably accustomed to using friendly serial port names like “COM13”. Recent versions of nRfMon can handle ports above COM9 but not with their “friendly names”, making it necessary to use names like //./com13 to connect.

The new version 0.7.4 allows manual entry of “friendly names”. The Port: combobox also presents enumerated ports with their friendly names. However, the “ϟ Connect” event in the console shows the actual name used to open the serial port instead of the friendly name.

RE: nRfMon - RFM12B forensics - Added by JohnO over 7 years ago

Works a treat - thanks dzach

RE: nRfMon - RFM12B forensics - Added by dabbishaw over 7 years ago

I have a 868mhz RFM12b, but if I change the frequency band I seem to be able to see data from the 915 or 433mhz bands.

Is this correct? I didn’t expect a radio for a specific band would work on the others?

(201-225/244)