Forget about the coverage maps in the RRDB, those are "best guess/intended coverage" not real life RF propagation.
Not the best planning of frequency re-usage with three sites so close together. Are those three sites all using the same frequency for the active control channel concurrently? Ideally each site should be setup so that 853.675 would be the least preferred control channel to avoid that, which I suspect is the case here.
In any event, and assuming that only one site is using 853.675 at any given time, SDRTrunk is simply looking for any valid control channel. That is why it's showing the same details for all three "sites" you've programmed when you start those channels, because the SDRTrunk channel definitions are kind of dumb and there is no criteria to weed out unwanted sites such as by using a NAC or even the System ID. Find control channel = start decoding, it's really that simple.
Frankly, the only thing you can do in this situation is to remove 853.675 from the channel pool of the two sites (channel definitions) that aren't actually using that frequency on a consistent basis, leaving it only in the channel pool of whichever site it's the active control channel for. This will prevent SDRTrunk from finding it when rotating through the control channels for those other two sites.
