I know this part, but believe me, the problem is that the mount reports a by 4h different RA value without slewing. As you could see in the code part you are citing, the log takes the current telescope position when reporting and not the target position.

Read More...

Jamie,
there must be something that changes your scope position suddenly from RA = 22h 48m 15s to RA = 02h 48m 15s. This is what creates the mess.

Do you have a second mount in your network? The question might be silly, but I know from own experience that this causes trouble if they have the same name even on separate INDI server.

Could you please turn on the INDI mount logging next time?

Cheers
Wolfgang

Read More...

Voilà:

[2021-09-17T00:33:51.921 EDT DEBG ][     org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "22h 59m 56s"  scope RA= "02h 48m 14s"  ha= 8.19508 , meridian diff= 0.13 , hrstoFlip= -8.06508 , flipDelayHrs= 0 ,  "Pier Side: East (pointing West)"

Jamie,
I took a first look into your log. The really weird thing is that two MFs are happening more or less in a row without slewing to a different target in between.

There is one weakness in the MF: we do not check afterwards if the position reached matches the intended target position. In your case, it seems to be far off - no idea, why! Instead of RA=22:48:14, after the MF slew, it has RA=02:48:14, so exactly 4h apart.

As a consequence, a second meridian flip is started while alignment is still running - another weakness, currently alignment is not aborted in this case, it simply is suspended until the mount is tracking again.

Do you have an explanation for this significant difference in RA?

Maybe you could turn on the INDI log for your mount, so that we could take a deeper look inside.

Btw.: I see you have a OnStep mount. There was a discussion here recently leading to a fix in the OnStep driver. Are you on the latest version?

HTH
Wolfgang

Read More...

Hi Joshua,
you might take a look at weatherradio. This is an Arduino-based solution for an entire set of weather related sensors and comes with an INDI integration: github.com/indilib/indi-3rdparty/blob/ma...adme-WeatherRadio.md

Cloud detection with the IR sensor is tricky to get it reliable. With rain detection I‘m currently experimenting. The most promising is the RG-11/RG-15 with optical drop detection.

Read More...

As far as I know the repository is intended for Ubuntu, not for Raspbian. If you know what to do for guiding it on your own, I would recommend building from sources. If it is setup, repeating it for latest versions is easy.

Read More...

And good point about the false positives, it could be that the evening sun casts some rapid shadow movements since it shines through the tree.

Read More...

Right, the overflow will not create a crash, the counter is simply ignored for drop counting. There is one function evaluates the interval counter and calculates both rainVolume and eventFrequency. It does not distinguish between drop and bucket count. The differentiation comes through the serialization function, that creates a JSON document:

void serializeRainSensor(JsonObject &doc, rainsensor_data &data, String name) {
  JsonObject json = doc.createNestedObject(name);
  json["init"] = data.status;
  json["mode"] = data.mode == 0 ? "tipping bucket" : "drop detect";
  if (data.status) {
    json["count"] = data.count;     // only relevant in tipping bucket mode
   if (data.mode == 0) {
      json["rain volume"] = data.rainVolume;
   } else {
      json["drop freq"] = data.eventFrequency;
   }
 }
}

check here for the explanation to obtain stellarsolver: invent.kde.org/education/kstars#building

Read More...

For simplicity reasons the count variable is delivered for both types of rain sensors, bucket count and drop count. For the latter, only the eventFrequency is of relevance, count can be ignored.

Read More...

Btw: the count variable is only used for bucket mode. For drop detection the frequency is calculated by intervalCount, which is typically reset to 0 once a minute. And for the bucket mode, I would question that anyone sees the overflow.

Read More...