Author Topic: Default network (and other) ID(s) - alternating bit values  (Read 579 times)

LK

  • Newbie
  • *
  • Posts: 5
Default network (and other) ID(s) - alternating bit values
« on: June 11, 2019, 08:09:09 AM »
I notice that the default network ID (address) used, for example, in the library's Gateway and Node examples, is 100.

I have previously been using 0, as I just felt it was tidier and there was nothing in the comments to say that one ID was better than another (that is, if you were to use only one network ID in any one installation).

After reading around the subject of best use of radios (and reducing reception failure rate), though, I found that you want over-the-air bits to alternate between 1s and 0s as much as possible (thus the use of data whitening, Manchester encoding, etc.).

So I was wondering, if rather than 100, might 85 be better, as it would result in a sync word that would alternate more, as after the initial default 0x2D, it'd then alternate bits (giving a full sync word of 0x2D55 or 2 bytes of: 00101101 01010101)? Or might that be more likely to be mistaken for a section of preamble?

It certainly seems like my previous preference for using 0 might lead to more reception losses, anyway...

Also, based on the diagram given here: https://lowpowerlab.com/2019/05/02/rfm69-10bit-node-addresses/, if not using data whitening (to make the bits alternate more in the "payload length" byte, "to node ID" byte, "from node ID" byte, CTL byte and the follwoing bytes), would it be good to choose node IDs in those bytes that also caused as much alternation as possible in the 1s and 0s? For instance, the gateway ID might be set to 682 (binary 1010101010), if using those new 10-bit node IDs, as (presuming a node is always communicating with a gateway rather than with other nodes), it'll always lead to alternate 1s and 0s in either the to "to node ID" or the "from node ID" byte in each transmission?

Or would such small tweaks be nothing compared to the chance of long sequences of 1s or 0s in the message itself (causing reception issues)?

I ask partly to try and understand the underlying processes better and partly to try and reduce the rate of reception failures I'm seeing.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5996
  • Country: us
    • LowPowerLab
Re: Default network (and other) ID(s) - alternating bit values
« Reply #1 on: June 12, 2019, 08:22:29 AM »
There is nothing wrong with any number for network ID, but I suggest going with a better "magic token" than just alternating 1/0's. As you mentioned, this might be mistaken for preamble.
Ideally we want to clearly distinguish PREAMBLE from SYNC.

I am experimenting with using more SYNC bytes as well to reduce false packet triggers.

FWIW - I do not see any significant losses (read: none) by not using whitening and I have done some extensive tests.
I am debating whether to enable this by default, along with more SYNC bytes.

As far as node IDs, i think it makes no difference and should not matter. We need to be able to use all 10bits of address, once the preamble/synch are locked, the packet is unraveled and those IDs are just shifted into the registers regardless of their values.

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: Default network (and other) ID(s) - alternating bit values
« Reply #2 on: June 12, 2019, 05:25:21 PM »
As far as node IDs, i think it makes no difference and should not matter. We need to be able to use all 10bits of address, once the preamble/synch are locked, the packet is unraveled and those IDs are just shifted into the registers regardless of their values.
And are going to get scrambled over the air anyway if you're using encryption.

LK

  • Newbie
  • *
  • Posts: 5
Re: Default network (and other) ID(s) - alternating bit values
« Reply #3 on: June 13, 2019, 06:32:47 AM »
Oh, yes, I forgot there was encryption on top of that as well! So does that mean that whatever whitening does then might get undone by the encryption?

I'm surprised to hear that you get no losses at all, Felix. Is that using all-default values (i.e. as the library comes, fresh from GitHub)?

I get some message losses even when a node is right next to the gateway and the RSSI is at maximum (at various power outputs, with 867 MHz centre frequency), and more when I separate them further, or put obstacles in the way (bits of buildings, large plant like big metal air handling units, etc., to give them a "challenge"). Message loss is much reduced when I reduce the OTA baud rate from the default 55555 to, say, 9600. Different antennas made a massive difference, too. But the one thing I always have is (at least an occasional) missing message.

Most of those tests have been done by getting a gateway node to send out a message to request the RSSI that the node receives that message on, which it responds with back to the gateway. So I suppose it's a command and response that goes missing (one message out and one reply, in each case), rather than just, say, a node repeatedly transmitting to a gateway. I was only recording the replies that reached the gateway in those tests, as I was keeping the gateway stationary and moving the node to various locations. So that might be increasing the "packet loss" that I saw, as a loss of either the gateway-to-node command (doesn't reach the node) or node-to-gateway response (no reply back to the gateway), or both, would be seen as a missing message.

Inevitably, though it seems there are lots of times when I have to do a "try again on failed response". I'm getting a feeling that it's just in the nature of wireless transmissions to go missing, but I still wanted to try and find some ways to reduce the number of those, and make any systems I end up with as robust as possible.

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: Default network (and other) ID(s) - alternating bit values
« Reply #4 on: June 13, 2019, 07:24:59 AM »
Inevitably, though it seems there are lots of times when I have to do a "try again on failed response".
Are you sure it's a packet loss or could it be that you're not getting the ACK back to the sender in time?  The RFM69 example code is notoriously 'good' example of wasting time before sending the ACK - VERY BAD PRACTICE!  Always save the incoming data and then ACK right away if you don't want to waste transmissions (and battery power).

LK

  • Newbie
  • *
  • Posts: 5
Re: Default network (and other) ID(s) - alternating bit values
« Reply #5 on: June 13, 2019, 01:35:25 PM »
Good thought, but it's probably not that; I was getting a lot of the ACKs going missing when I first started (I think I even tried modifying the wait time to be longer, but to no avail), so I stopped using ACKs altogether and instead implemented definite, unique replies to each message type, with plenty of wait time. I was waiting for up to a second for replies, and they usually came in much sooner than that, when they did (even at the slowest possible OTA baud rate).

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5996
  • Country: us
    • LowPowerLab
Re: Default network (and other) ID(s) - alternating bit values
« Reply #6 on: June 14, 2019, 09:29:33 AM »
@LK - As far as I remember reading the DS, whitening is applied after encryption.

I hope to release some significant updates to the library and the examples too, that should make the gateway sample much better.

LK

  • Newbie
  • *
  • Posts: 5
Re: Default network (and other) ID(s) - alternating bit values
« Reply #7 on: June 14, 2019, 11:02:00 AM »
So I suppose, then, that doing anything to the addresses or payload is not very useful if it's encrypted afterwards, but it may then be important, once it is encrypted, that it does not have large runs of of 0s or 1s at that stage? It'd be hard to tell if there even was a problem resulting from that (sequential 0s or 1s), if the encryption and/or whitening processes happen inside the RFM69 module...

I look forward to updates to the library. It's been a very useful tool so far, and any improvements or additions would be great!

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: Default network (and other) ID(s) - alternating bit values
« Reply #8 on: June 14, 2019, 11:33:55 AM »
Good thought, but it's probably not that; I was getting a lot of the ACKs going missing when I first started (I think I even tried modifying the wait time to be longer, but to no avail), so I stopped using ACKs altogether
this is definitely a sign of a bad setup.  Either software or antenna or RF noise.  Have you checked your RSSI values at both ends of the link?  That will help isolate SW vs HW issues.  Anything -85 or better SHOULD produce a reliable connection. 



LK

  • Newbie
  • *
  • Posts: 5
Re: Default network (and other) ID(s) - alternating bit values
« Reply #9 on: June 14, 2019, 12:51:22 PM »
When I was testing it, I got the node to reply to the gateway with the RSSI it received the message (from the gateway) with in its reply. The gateway reported that over serial, and also then reported the RSSI that it received the reply with, so I got the RSSI from both ends, even when I was wandering around with the node to test range, or the nodes were outside in the boot of my car to give them an extra challenge!

Generally the missing messages were more frequent as the RSSI got worse, and messages were dropped much more often below about -85. But there were still some messages missing when the ones either side of them reported, maybe, -45 or even -25. It was much less frequent, but still happened sometimes.

Most of the tests were done by taking the node to a position where the messages were starting to drop (with an RSSI at either/both ends of -80 to -90), as I was using the successful message to dropped message ratio as a measure for comparing different antennas, baud rates, and so on.

The only other way to test those might have been to look at the RSSI values (without taking the nodes somewhere that made the RSSI levels so low), but the RSSI values seem to wander around quite a lot, even when the gateway and node are in the same positions relative to each other for a long time (the variations was about 5 to 10 "RSSI points" over about 10 minutes). But there were still times when I brought the node back (to being closer to the gateway), and on the way back, messages were dropped at much better RSSI levels. Might messages be more likely to be dropped when a node is in motion than when static somewhere?

I think I might need to revisit the tests and see what I get when I run the nodes for a long time with a middling-level RSSI value, like -50 or so.