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 CapnBry about 7 years ago

Yeah I was avoiding going below char(‘0’) because I assumed the receiver code did the same sort of math on the other side that the transmitter did (add ‘0’ to the rssi) and I didn’t want to bump into the line end characters. I had tried it with up to 32 levels but I saw this in drawScanline:

    # don't draw the input if it contains non numbers
    if {[catch {
        # find out the maximum signal on this line
        set lmaxrssi [::tcl::mathfunc::max {*}$var(scandata)]
    }]} {
        return
    }

Which I assume will throw and return if a non-numeric is in scandata.

I’m not pressing to get this implemented, I was only wondering if the ARSSI would make things more precise / fast. It works fine for me with 10 levels because I’m really just browsing my spectrum looking for a transmitter.

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

Yes, that’s what it does. I put it there as a sanity check because I was getting random chars during start up probably due to USB buffers containing remaining data in from previous operations. If the data is binary and can take any value then this check will cause problems.

The real problem for BERT is the bottleneck in receiving, that appears to be due to the 57600 bps speed. I tried adding a wrapper around binary data, but it adds more characters to the BER data coming in and lowers the useable test speed to less than 28 kBps.

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

CapnBry wrote:
> I’m not pressing to get this implemented, I was only wondering if the ARSSI would make things more precise / fast. It works fine for me with 10 levels because I’m really just browsing my spectrum looking for a transmitter.

No problem with that, I was curious about the ARSSI and you’ve given enough input for a future inclusion of an ARSSI mod in nRfMon.

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

Maybe this code will do the trick (not tested with real data yet):

rf12mon.ino, function scanRSSI, change from:

    Serial.write('0' + (i<=lev0 ? 0:i));

to:

    // binary output, escape a newline with a 0xFF
    Serial.write(i<=lev0 ? 0: i==0x0A ? 0xFF : i);
    // escape a 0xFF with another 0xFF
    if (i==0xFF)
      Serial.write(0xFF);

nrfmon.tcl, proc ::mon::drawScanline, change from:

    set var(scandata) [split $var(scandata) ""]

to:

    # map escaped chars back to original chars
    set var(scandata) [string map {ÿÿ ÿ ÿ \n} $var(scandata)]
    binary scan $var(scandata) c* var(scandata)

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

I did a quick soldering of a wire from the ARSSI side of the (unchanged) capacitor to analog 0 and pasted CapnBry’s hack in the rf12mon.ino sketch, expanded to 48 levels:

The tcl code is not ready for full scale 256 level ARSSI. There are a number of default settings that need to be adapted to the number of levels. Maybe the drawScanline proc needs rewriting too, since it still contains test code that needs refinement/removal.

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

Packet Error Rate changing over time:

In the waterfall screen I’ve seen noise levels changing from time to time. This may be showing what happens to PER during one such change.
After some more time:

In the two screenshots the settings are exactly the same.

RE: nRfMon - New version 0.7a uploaded - Added by dzach about 7 years ago

Version 0.7a of nRf Mon is in Github

Changes to nrfmon.tcl:

-Added FSK data and BERT modes. User can broadcast data by using ‘t ’ in the console (group 0, id 1)
-Scan data is now binary, as is FSK data.
-GUI changes. Removed unused controls
-Most screen colors are now user selectable and saved in nrfmon.conf
-Default mode is now Listen instead of Scan
-Removed redundant code
-Toggle grid depending on mode
-Added Quiet and Pause
-Added procs implementing the SLIP protocol
-Fixed loading preferences
-Fixed console Home key
many more

Changes to rf12mon.ino:

-Removed CW and ASCII mode.
-Added FSK data and BERT mode.
-Scan and FSK data are now binary.
-Simplified xmission, on/off timing

Documentation needs to be re-written to reflect the changes.

The updated binary is for Linux. Ports and binaries to other OSs are very welcome, as are comments and bug reports.
For bug reports it’s best to use the Github issue tracker

The new BER Test screen:


In the bitstream waterfall, blue is good bits, green is good bits but bad CRC, red is bad bits, white/gray is noise

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

I think it works in Win7x64.

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

Thanks JohnO.

That screen is a mess. If it’s taken after an error, that would explain it. I cannot replicate the error
I uploaded a possible fix, that will get something printed on the console, if nothing else.

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

Here is the latest screen.

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

That looks a lot better. It’s interesting that most screens (yours, mine) show the harmonics on the same frequencies, an indication that they are produced locally by the microprocessor or the RFM12B.

RE: nRfMon - Windows 32bit binary - Added by dzach about 7 years ago

Windows 32bit binary uploaded to github

I made this on an old WindowsXP of a friend. I don’t know if it will work in newer versions of Windows.

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

Win32 version executes for me on Winx64.
Listen mode display.

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

Version 0.7.1
Fixed some issues and added a ‘User actions’ choice to the console widget.

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

Appears much more robust for Win7x64 in this version.

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

Thanks for the report JohnO!
I uploaded the Windows binary for version 0.7.1 which hopefully fixes the problem of the window not remembering its last position.

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

[](<{margin:0 30px;}.rf12forensics75.png)

nRf Mon v0.7.1 monitoring JeeNode v6 packets reporting a changing analog value:

The PER plot should probably be turned off since the payload is not the BER test symbols and the resulting (green) plot is rather meaningless; it displays the result of XORing the LSB of the analog value with the BER test symbol (0x55) EDIT: that only happens with bad CRC packets.

At present, fixing the first payload byte to the ‘magic’ 0xFF allows the rest of the binary payload to be printed in nRfMon’s console:

< 3d           <- packet with a size of 3 bytes
▼ g 64 id 1    <- packet group = 0x64 (100d), id = 1
0046           <- packet data = 0x0046 (70d)

In the waterfall display of the leftmost screenshot, the fat bluish band is the magic 0xFF and it is followed (horizontally) by the two bytes of the analog value. Last comes the CRC value which is 0, since the ‘Quiet Rx’ button is ‘on’, meaning only good packets are received.

In the right screenshot, the ‘Quiet Rx’ button is ‘off’, so stripes of noise show up between packets. No bad CRC packet is shown on this picture.

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

Hello All,
I’ve been following this thread and finally decided to give it a try. Unfortunately I have not been able to get the application to connect properly. I am running Windows 7 x64, and using Jeenode SMDs. Here is what I’ve done:

  1. Downloaded the whole master .zip of nRfMon from Github
  2. Downloaded the ‘Community Version’ of Tcl8.6 from here: http://www.tcl.tk/software/tcltk/8.6.html
  3. Installed Tcl8.6
  4. Connected my Jeenode SMD via FTDI cable and loaded the rf12mon.ino sketch. The FTDI cable is on COM33.
  5. Started nrfmon.exe in …-master\binaries
  6. Typed com33 in the upper right field, pressed ‘enter’

On the lower right, I get:
couldn't open "com33": no such file or directory
. Disconnected

If I open the serial port in the Arduino IDE I get this:

xcvr rf12b ver 0.7a hw JeeNode.v6
< 128x pcnt 128 offdur 100 fsk 0x55

(I have another node sending packets)

Anything else I can try?

Thanks!

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

Works for me on Win7x64 - could you try tweaking the Comm port number to one less than 10. Mine is com4, I think you can adjust the port numbers in ControlPanel/DeviceManager/Ports (COM & LPT).

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

@JohnO, that did the trick! Was about time to clean out those hidden coms! Thanks.

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

I guess dzach will twiddle the code to fix the issue. I'm pleased it worked for you. The code is awesome, a magnificent achievementdzach.

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

I suppose this could be immediately useful as we are using Jeenodes in different cities. So first step would be to get an idea of the RF traffic and then try to optimize the settings to get the best results. Hmmm. Gets me thinking. Definitely have to play around with this. I agree, this is really cool!

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

Hi wiso!
Glad you find it useful and would love to see nRfMon helping tune nodes to suitable frequencies in a crowded band.
I’m almost blind when it comes to Windows (no Windows installation here) but JohnO has been very very helpful with debugging nRfMon on Windows.

wiso wrote:
>
> `xcvr rf12b ver 0.7a hw JeeNode.v6

< 128x pcnt 128 offdur 100 fsk 0x55`

The first line is the signature string sent by the node to whomever connects to the serial port. I see you are running a slightly outdated version, the last one (v0.7.1) has a few issues fixed. There is also a binary for windows (no need to install TCL if you don’t want to) which JohnO has checked and runs on his Win7x64 PC.

The second line quoted above is an auto response at the end of a transmission period; the node enters the Bit Error Rate test mode by default if no instruction is given within 10s from a reset, and gives a report at the end of each BERT cycle (128 packets of 52 0x55 bytes used as the BER test pattern). So, everything looks normal with the node in the above lines.

JohnO wrote:
> I guess dzach will twiddle the code to fix the issue. I'm pleased it worked for you. The code is awesome, a magnificent achievementdzach.

I am lost when it comes to fixing nRfMon issues with Windows. How can nRfMon know that COM33: is not there? For Linux there is a piece of port discovery code that makes it easier to connect to the node port.

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

Having said the above, I read in the tcler’s wiki that one can give an absolute path (?) for a comm port, in this case like: //./com33

Oh! And there is a JeeLabs piece of code that does serial port enumeration He’s already done it, thanks jcw!

JohnO, I’ll create a test branch in github with JCW’s code for serial port enumeration, if you would like to test it.

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

That will be fine dzach, I’ll take a look - probably in the morning.

(176-200/244)