PACKET_CAPTURE_THRESHOLD vs collision detection

[pswiatki]

When I use the original value of PACKET_CAPTURE_THRESHOLD (5) I tend to get no readings from my water meter.
It used to work in the winter - then I observed higher values in wmbusmeters' rssi_dbm field. They were oscillating around 10. Now (springtime) they are lower and seem to get lower than 5.
I can see this #define is used as follows:

// Stop receiving packet if current rssi below threshold.
// The current packet seems to be collided with an another one.
if (rssi < PACKET_CAPTURE_THRESHOLD)
{
   reset_t1_c1_packet_decoder(decoder);
}

However, when I lower the value of PACKET_CAPTURE_THRESHOLD to e.g. 2 - I can see almost every packet (I believe the meter TX period is 8 seconds). My case is probably somehow strange - the meter is located ~2.7m underground and 12-15m away from the antenna (which already is a 10-element Yagi - without it I could not pick up anything from my meter). Another two meters are just on the other side of the fence, also underground (same depth, I think) and the distance from my RX antenna is similar (perhaps 2-3m further away). The RSSI reported by wmbusmeters is much higher, though. I think it was in the 30-40 range last time I checked (a long time ago).

There are also plenty of more distant water meters I can pick up with this directional antenna I use (so those are strong enough!), so I would expect many collisions to take place often enough.

It might be my meter's RF transmitter is broken and thus TX is weak (the meter is quite new - only 1.5 years old and its battery status indicates no issues with the battery).

But I am not sure why lowering the value of the above #define makes rtl-wmbus work as expected. After all, collisions should be occurring equally often, should they not? Strangely, despite any possible collisions I see my own telegrams as expected and I get almost all of them. How come?

[xaelsouth]

The idea behind the code snippet you referenced - "if (rssi < PACKET_CAPTURE_THRESHOLD) { reset_t1_c1_packet_decoder(decoder); }" - was as follows:

Stop receiving by resetting the state machine if the signal currently being received gets weaker und falls below a threshold = PACKET_CAPTURE_THRESHOLD. So we don't waste time with a weak signal, which we probably would never have received at good quality, and prepare us to receive the stronger signal instead. It's assumed that the stronger signal could begin even before the weak signal is completely gone!

A collision occurs when a weaker signal is going to be overlapped by a stronger one, not the oher way around.

You can disable this kind of collision detection by setting PACKET_CAPTURE_THRESHOLD = 0.

Collisions should not occure equally often, assuming sending datagrams is correct implemented. Each device maintains a pseudo-random offset to sending time, which should help to eliminate cycling and collisions in sending schemas.

[xaelsouth]

To device's battery status which is reported to be ok. Batteries embedded in metering devices are often not very powerful to provide enough current to RF transceiver for sending datagrams. A small electrolytic capacitor near to the battery solves the problem with load peaks. May be that the capacity is to small or degrades with time or is too sensitive to external temperature, so that your device is sending with less power?..

[pswiatki]

It is possible, but all water meters in the vicinity come from the same water company - I believe they are the same type (and the mandatory replacement dates are not too far away). So, if there is a hardware malfunction, it is in my own meter, because I can easily pick up other, more distant ones and the reported RSSI is much higher. By the way, I also have the power meter (amiplus) in the basement of the building and its reported RSSI is always well above 130. Must be very strong transmitter (signal goes through a thick, brick/concrete floor and several meters up to the RX antenna (which it hits from a wacky angle of 90 degrees to the boom of the 10-element yagi). Yet, it doesn't affect the RSSI level a single bit. But hey - power is not an issue for.... a power meter, right? ;)

Frankly speaking: I had a plan to make a portable scanner (perhaps the RPi running wmbusmeters and GPS) and somehow conceal the yagi, then go for a walk ;) It would give me a pretty good idea of what I should expect from my own meter (compared to other meters with their known locations and therefore also distances from my original RX rig in the house.