Two very minor Cosmetic bugs

Very minor but easy to fix cosmetic bugs:

  1. focus lines in log show my temps as C, but are actually F.
  2. At the end of each month the images get labeled with MMDD like this: EndOfMonthMMDDbug
    MMDD changed from 0831 to 0901 after midnight. Should stay 0831 for entire night.

There’s a bug with the date, but not the one you described.
MMDD did actually change the month, but not the date, it should change to 0901 after midnight.

In my opinion it’s a good thing SGP is saving celcius in the filename, it seems very common for astronomy software to use celcius which is a good thing :+1:

Where do your focus temps come from? The focuser itself or an environment device?

It actually changed to 0931. Either way it has been fixed as such:

For the absolute current date:

  • “dd” for day
  • “mm” for month
  • “yy” for year

To use a constant date based on when the sequence started:

  • “d2” for day
  • “m2” for month
  • “y2” for year

Available in the next beta (>

My focuser temps come from the focuser itself. I have configured it to use F. I can send a log if you need it.

No, that’s ok, was just curious… we can’t do anything about that log statement as the ASCOM focuser interface does not allow a way to query the temperature scale… since almost everyone uses Celsius, we just fudged it. If you were getting it from an environment device we might have been able to detect…

No problem. I only mentioned it because you are concentrating on cleaning up any issues with 3.1, which I am very much in favor of.

Ken, you might to reverse these. mmdd has always worked like m2d2 is proposed to work, except of course on the last day of the month. This will require everyone to change this parameter. That’s fine with me. Your logic is good, it will just make everyone make this change.

“mmdd” has never worked that way. That has always been current month current day. What you are referring to, I think, is “mmdy” which is current month, starting day. BUT, even though I pulled it out of the docs, “dy” is still respected so impact should be minimal.

According to the ASCOM specification the ASCOM Temperature property returns a number but there’s no current requirement that it must be Celcius or anything else. It’s just a number.

I’ve raised this with the ASCOM specification keepers, I think it needs a change to the documentaton saying that the temperature must be returned as C.

1 Like

I concur with this