Stray/unknown node appears in Dashboard

[Stereodude]

So the other day a stray/unknown node has appeared in my dashboard.  I only have one node of my own (so far).  I have only received a few packets from the unknown node ID 129 (looks to be 12 RSSI packets).  How is this possible?  Shouldn't they only show up if the sending RFM69 radio has the same encryption key as the gateway?  I have a randomized 16 character key so it seems unlikely to me that someone else in the area could have the same encryption key.  I thought that perhaps the data from my node was being corrupted, but I would expect that to be random, not always 129.

I don't see how it could be connected, but this only started after I added an an ambient light sensor to my nodea few days ago.  Before I was reporting & collecting temperature, pressure, and humidity for over 2 weeks with no stray node appearances.  Now my messages are a little longer (by 8 characters), but I'm struggling to see a connection.

I'm not sure why it thinks node 129 is reporting a level of 0 in CM.  When I download the CSV for that metric, there's no data in it.  AFAIK that wouldn't appear unless there was a "cm" in the received message.

I'm pretty new to the world of RFM69 radios and wireless sensors.  Is this a common issue?  Is there something I'm overlooking or not considering?

[Felix]

Somehow the gateway reported a node 129 with a matching metric.
If it were noise I doubt it would ever produce anything meaningful other than some bogus node ID.
It could be your other node somehow sends a packet that gets corrupted/split, but if you're using stock code, I would not expect that. I never see any bogus stuff showing up.
Any non matching data goes into a nomatch separate db, just for the record.
Try to track down in the log when it happened, and the complete message from your gateway, that's the best piece of evidence you have to investigate more.

[Stereodude]

It could be your other node somehow sends a packet that gets corrupted/split, but if you're using stock code, I would not expect that. I never see any bogus stuff showing up.

Stock code in which?  The MightyHat is completely stock with the exception of the network config.  The Moteino M0's code has been fairly well customized because the sample Weathermote project I started with was for an AVR based Arduino and uses an AVR specific function, dtostrf, not available for the Cortex M0+ and I had to use an alternate method to create the message for transmission.  The sleep strategy is also totally different between the two architectures so that had to be altered as well.

Try to track down in the log when it happened, and the complete message from your gateway, that's the best piece of evidence you have to investigate more.

They appear to be corruption...  Node 10 should be sending a message every 30 seconds and the received data from node 129 appears to be right on the 30 second schedule with the expected message from Node 10 missing.  Here's an example.

Code Select Expand

[11-10-18_02:39:18.346] [LOG]    >: [10] F:64.27 H:45.15 P:28.97 L:0.00   [RSSI:-51]
[11-10-18_02:39:18.349] [LOG]    post: /home/pi/gateway/data/db/0010_Temperature.bin[1541835558,64.27]
[11-10-18_02:39:18.350] [LOG]    post: /home/pi/gateway/data/db/0010_Humidity.bin[1541835558,45.15]
[11-10-18_02:39:18.351] [LOG]    post: /home/pi/gateway/data/db/0010_Pressure.bin[1541835558,28.97]
[11-10-18_02:39:18.352] [LOG]    post: /home/pi/gateway/data/db/0010_Illuminance.bin[1541835558,0]
[11-10-18_02:39:18.353] [LOG]    post: /home/pi/gateway/data/db/0010_RSSI.bin[1541835558,-51]
[11-10-18_02:39:18.359] [LOG]       [10] DB-Updates:1
[11-10-18_02:39:49.474] [LOG]    >: [129] (�̄�Ќs���|��0C�K�5WC$7�9aZ   [RSSI:-48]
[11-10-18_02:39:49.487] [LOG]    post: /home/pi/gateway/data/db/0129_CM.bin[1541835589,0]
[11-10-18_02:39:49.496] [LOG]    post: /home/pi/gateway/data/db/0129_RSSI.bin[1541835589,-48]
[11-10-18_02:39:49.499] [LOG]       [129] DB-Insert new _id:129
[11-10-18_02:40:20.293] [LOG]    >: [10] F:64.27 H:45.13 P:28.97 L:0.00   [RSSI:-49]
[11-10-18_02:40:20.296] [LOG]    post: /home/pi/gateway/data/db/0010_Temperature.bin[1541835620,64.27]
[11-10-18_02:40:20.297] [LOG]    post: /home/pi/gateway/data/db/0010_Humidity.bin[1541835620,45.13]
[11-10-18_02:40:20.298] [LOG]    post: /home/pi/gateway/data/db/0010_Pressure.bin[1541835620,28.97]
[11-10-18_02:40:20.299] [LOG]    post: /home/pi/gateway/data/db/0010_Illuminance.bin[1541835620,0]
[11-10-18_02:40:20.301] [LOG]    post: /home/pi/gateway/data/db/0010_RSSI.bin[1541835620,-49]

Looking in the home/pi/gateway/data/db folder I see RSSI have been received from nodes 39, 153, 183, 207, 211, 216, 235, 240, 243, and 253.  They have similar appearances in the log appearing where a message from node 10 would have been expected.  Some happened only once, some appear a few times.  They pretty go back all the way to when I first started up the gateway at the end of October.

Since the RSSI is there and not corrupted that would suggest data corruption on the sending side or RF interference correct?  If there was a communication issue was between the MightyHat and the Rpi3 I would expect the entire line to be gibberish without an intact RSSI.

[sparky]

I also get weird entry's in my db folder although I don't get them showing up on the dashboard

Code Select Expand

0018_RSSI.bin
0049_RSSI.bin
0058_RSSI.bin
0059_RSSI.bin
0069_RSSI.bin
0106_RSSI.bin
0146_RSSI.bin
0151_RSSI.bin
0162_RSSI.bin

[Stereodude]

I also get weird entry's in my db folder although I don't get them showing up on the dashboard

Code Select Expand

0018_RSSI.bin
0049_RSSI.bin
0058_RSSI.bin
0059_RSSI.bin
0069_RSSI.bin
0106_RSSI.bin
0146_RSSI.bin
0151_RSSI.bin
0162_RSSI.bin

Are you running an ARM Cortex M0+ based node(s), or an AVR based one?

For those nodes to show up the encryption key and network ID has to match.  If only the payload gets trashed, but not the encryption key or network ID that would seem to suggest a communication issue between the Atmel micro and the RFM69 chipset or a issue creating the message.  If I'm reading the driver code correctly the encryption key and network are not sent from the micro to the radio with every message.  But neither is the node ID and that's getting corrupted. 

[sparky]

Are you running an ARM Cortex M0+ based node(s), or an AVR based one?

For those nodes to show up the encryption key and network ID has to match.  If only the payload gets trashed, but not the encryption key or network ID that would seem to suggest a communication issue between the Atmel micro and the RFM69 chipset or a issue creating the message.  If I'm reading the driver code correctly the encryption key and network are not sent from the micro to the radio with every message.  But neither is the node ID and that's getting corrupted. 

No MO, just standard Moteino w/RFM69HCW transceiver

[Felix]

I meant stock code for the Mhat, which is what it sounds like you are running.

Since the RSSI is there and not corrupted that would suggest data corruption on the sending side or RF interference correct?

I think this is sending side. Check your code and maybe sniff some serial of the buffer you are sending. Corruption/randomization/noise never creates information, only destroys it. I have seen similar things in my coding Arduino, where you think you're printing something to a buffer, and it's something entirely different. That and the fact that you seem to hit the 30 second marks from your node with different node IDs, I think I can almost bet that's where the problem is.

Let's see what you find from looking at your sender a little more in depth.

[Stereodude]

I think this is sending side. Check your code and maybe sniff some serial of the buffer you are sending. Corruption/randomization/noise never creates information, only destroys it. I have seen similar things in my coding Arduino, where you think you're printing something to a buffer, and it's something entirely different. That and the fact that you seem to hit the 30 second marks from your node with different node IDs, I think I can almost bet that's where the problem is.

Let's see what you find from looking at your sender a little more in depth.

I think this will be a bit of a pain to sniff.  I will likely have to log the node for days and days and wait for a bad reception and see if I find a corresponding buffer output (or not) in the days of serial data.

This code seems pretty innocuous to randomly be gibberish every so often:

Code Select Expand

    /* create an equivalent buffer to AVR based "inos" for transmission since the M0 doesn' have a  dtostrf function */
    temp_string = "F:" + String(F) + " H:" + String(H) + " P:" + String(P) + " L:" + String(luminance);
    temp_string.toCharArray(buffer, 50);

    sendLen = strlen(buffer);
    
    radio.sendWithRetry(GATEWAYID, buffer, sendLen, 1); //retry one time