I don't have a magic wand for you. I know the subject is more complex than most us understand. When studying anything it is best to reduce and make things as simple as possible. When one is in violation of NMEA 4000 installation standards and introducing RF to the environment near the subject unit in question, that isn't something I am even going to consider because basic guidelines are being broken. The longer it is in place the longer likely issues are to get worse. Think of your ear as a receiver and if someone comes up and consistently yells into it, it is very disruptive. It goes beyond that because after they stop yelling, the ears might continue to ring. Eventually after enough yelling sessions occur, permanent damage happens and overall sensitively is affected. Same happens with sensitive receivers of just about everything. Same reason they don't recommend putting a GPS into the RF of a radar. Many will last for about 2-3 years before they can't hear anymore but there is a slow degradation of signal level long before then but mostly goes unnoticed. It is not to say that there is also something else going on as well.
I think we are a bit frustrated because it appears there is a genuine problem with a key safety feature that your engineering staff seems to not want to recognize. Just go back and look at the screenshot in my post that started this thread and see numerous spurious ARPA targets along with the handful of real targets that show a return under the ARPA symbol.
In my case, there is really no possibility that RF interference is a factor. No Starlink. My SCX-20 is mounted about 10 feet aft and 8 feet above the radar array, certainly meeting any specification for separation. The VHF and AIS transponder antennas are also about 10 feet away. The internal GPS receivers in my TZT3 units are four feet below the radar and effectively shielded by the hardtop, which has carbon fiber cloth.
I am pretty capable of understanding the complexities of the problem. Reducing it to simple terms, the radar is receiving a return from a target that it sees as moving at a rate above the ARPA speed threshold and displaying it as an ARPA target with the course and speed vector it has calculated from sequential returns. Just as with the sea state and rain filters that limit the display of target returns that the software determines are not vessels or other types of "real" targets, the ARPA software must apply a set of filtering parameters to the returns to determine whether to track and display them as ARPA targets.
A simple guess is that there are sea surface returns that the ARPA is identifying as targets that should be tracked and displayed but that the sea state filter is removing from the display (otherwise there would be some sort of return showing on or near the spurious ARPA targets. This would seem to be confirmed by the boat wake (which is not removed by the sea state filter and shows on the display) very often getting tracked by the ARPA. So this is telling me that the algorithms the ARPA software applies to the target returns to choose what gets tracked is not filtering out some weak sea surface returns that it should filter out.
A further guess is that the ARPA advanced settings might alter this behavior but since those are not meant to be changed by the user, we have no way of knowing what could be done to change it.
As I said in an earlier post, the outstanding ARPA performance I have experienced over the years with Furuno radars is a big part of why it is installed on my boat. Indeed, I removed a competitor's system and replaced it with Furuno because of the poor radar performance and the pathetic manual target tracking.
