promiscuous mode issue with rfm69

[pb66]

Hi Guys During this "Data loss due to RF packets getting corrupted" discussion on the openenergymonitor forum, I learn't about the "// FIXME doesn't seem to work, nothing comes in but noise for group 0" line in rf69.cpp.

Is there a fix planned for this?

I have extended a rf12demo sketch to have a "trace_mode" to help troubleshoot rfm network issues that is unable to fully function due to not getting a full promiscuous mode of operation. It simply uses rf12_recvDone() on a regular timebase (0.1s to 2.55s) to refresh the rssi value and from that a trace is output to a serial console. the additional code is wrapped in "#if RF69_COMPAT"s and is dormant in normal running, I've used "y" as the command and the preceding value defines the timebase. "0y" is off(default) and 10y pauses normal packet processing and outputs the rssi based trace to serial every 0.1s.

I have seen in the RFconsole there is a "fourByteSync" used in place of a "fiveByteSync" to exclude the group id from the signature comparison, Having looked into this myself I'm afraid it's beyond my ability and it looks like any fix would need to be in the lib rather than the sketch.

Paul

[JohnOH]

The RFxConsole library is able to receive all groups if set to group = 0, it does this by extending the match pattern before a packet start is accepted. This reduces the noise substantially. Using this library ought to be transparent to your code.

[JohnOH]

I would like to give your code a spin in RFxConsole since I try to add any and all debugging capabilities to the RFxConsole branch.

[JohnOH]

Hi Paul,

I have been thinking about your application and think it would benefit from a discussion in the Jeelabs forum. I don't think git is the correct place, could you raise a post to continue developing this point?

[pb66]

Hi John, Late last night i did try just switching "JeeLib" branches and recompiling but got 2 unexpected results, 1 was my weakest node is no longer received in any mode and the other was the plotted output seemed to "switch" between last received rssi values, each time a good packet was due the plot would change and then stay at that same value until another good packet was received.

I need to look into both of these, but as I'm not familiar with the RFxConsole I may need to revert to the original JeeLib. as the trace was just a tool to achieve a job and I wasn't looking to spend to much time with it but had hoped for a fix to the issue I raised just to make it's use more effective (and easier).

It was(is) quite basic but it does work with the original JeeLib within the restrictions imposed by this issue, you can see the code at https://github.com/pb66/RFM2Pi/commit/99060e18e533389b2f51b7d95df9c5ae4f6daa6b perhaps it's short comings are more obvious to a more qualified eye.

[JohnOH]

Hello pb66,

I am sorry for the long delay in replying. I understand why your distant node could not be received by RFxConsole. One of my major concerns with the sensitivity of the RFM69 is triggering a packet reception on noise and having to wait for the packet being received to be aborted. In RFxConsole there is a line in RF69.cpp which reduces the sensitivity of the receiver:

0x29, 0xA0, // RssiThresh ... -80dB

You will see that the equivalent line in the master branch is commented out so using the default sensitivity of -114dB. You can do this also in RFxConsole if you wish.

Your trace code is very effective but only has access to packets delivered to it by the driver you are using. The master driver does not attempt to capture all groups whereas the RFxConsole does. In a further attempt to reduce sensitivity to noise RFxConsole extends the preamble sequence. While still compatible with the RFM12 transmitters & receivers it is more difficult for the hardware to trigger on noise. Once triggered on noise the radio is deaf to a valid packet arriving until end of packet processing has happened. Further, in an attempt to abort bad packets early the RFxConsole branch validates the length byte and aborts reception if it indicates a length greater than 66.

I am confident we can substantially improve your RFM69 reception but it will need to be based on RFxConsole branch for the moment since I am confident all known wrinkles have been removed from this branch.

[JohnOH]

A point of clarity, you may still use the RF12Demo.cpp code but it needs to be compiled using the RFxConsole library. There is a copy of RF12Demo.cpp in the RFxConsole library.

[pb66]

Hi John, Thanks for taking the time to come back to me. The -80bB limit makes sense, and I can experiment with that threshold, is there any plan to make that threshold a user setting? I'm not keen on making any permanent alterations to the lib as I am not looking to fix a single application, but am helping debug and support other users, hence the tool.

The tool was intended to just be a "visual aid" that users could just switch to to see if there was any "life" or extraordinary events etc,

Your explanation of the way noise better filtered and excluded on size would (if I'm understanding correctly) also explain the "latching effect" I experienced with on the rssi value in RFxConsole when using the trace_mode, the lack of noise will mean the rssi will remain at the last non-noise rssi until another non-noise packet is accepted and the rssi is changed,

In the instance of the tool it could be better to allow the noise through to get a picture of what is there rather than just knowing it's beyond the threshold by an unknown amount right now, it also gives a better profile if the rssi is changed between packets and gives an indication of transmission length.

I will try the RFxConsole again when I can, I am a bit bogged down at the moment :-)

Thanks again Paul

[JohnOH]

RFxConsole.ino has a backdoor method to adjust the noise threshold. There is also a command to display noise, bearing in mind that noise is always there it is just a case of at what dB level. ",0q" will set the sync length to a value of 1 and lots of stuff will match, that is a comma, a zero and a q. When in this mode good packets will also not be indicated for obvious reasons.

[pb66]

Aaaah. that looks promising! is an ack considered a transmission in this context?

PS why is is a specifically a comma? are a space and a comma not treated the same way ?

[JohnOH]

An ack is considered a transmission. Specifically a comma to be backwards compatible with the master branch command formats - I don't recall if it was adopted by @jcw. RFxConsole.ino certainly treats comma and space the same way.

[JohnOH]

",0q" isn't available in the master branch.