Reading Guide Error RMS Values from PDH2 Server

[Bill Richards]

Hello,

I'm developing a Python app to monitor various aspects of my astrophotography rig and sound an alarm if any of the monitored parameters falls outside a safe range.  One of the parameters I want to monitor is the guiding error (Total RMS).  That value doesn't appear to be one of the attribues available in the Event Monitoring Interface, unless i somehow overlooked it.  I've downloaded the PHD2 source code and perused it, but have not been able to identify which value I need or how to access it.  I think it's the "m_stats.rms_tot" value in graph.cpp, but I'm not sure.

Can someone point me in the right direction?  I'd like the value I monitor to match what is on the PHD2 graph.

Thanks!

Bill

[Bruce Waddington]

You should monitor the GuideStep event and do your own calculation for various statistical properties  The data elements of interest are RADistanceRaw and DECDistanceRaw.  You will want to make your own decisions on the size of the computational window, how you want to deal with dithering, etc.

 

Regards,

Bruce

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/8163a99d-a9f6-42fd-b026-31e407b60f32n%40googlegroups.com.

[Bill Richards]

Hi Bruce,

There's no way to expose the values PHD2 is displaying?  That would make it consistent and a heckuva lot easier.

 

- Bill

You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/RlBuJqC9Rw8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/002601d9f7d7%247d5f7ee0%24781e7ca0%24%40earthlink.net.

[Bruce Waddington]

There’s no clean way to do that and it is very context-dependent – most of the methods and windows that have statistical content compute their own values just for that reason.  For example, there’s no requirement for the graph window to even be displayed so what would happen then?  And “consistency” is probably not the most important thing, it depends on what you’re actually trying to measure and what you want to do with the results.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CACYRTaNzvmVOys1SOHn87UywBSO8uOjZn0%2Bx5QUv6288FKpcPQ%40mail.gmail.com.

[Bill Richards]

Hmmm... I see.

My objective is to monitor the total RMS value and sound an alarm if it exceeds some user-defined limit (i.e., I want to be woken up if there is a guiding problem).  Is there a way to mimic the PHD2 calculations so I can get close?  Where do I find how PHD2 calculates the total error (rms)?  Is that from m_noDitherRA.GetPopulationSigma() and m_noDitherDec.GetPopulationSigma() and then the hypot of those two?

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/003701d9f7e3%240f977000%242ec65000%24%40earthlink.net.

[Bruce Waddington]

Yes, that’s how it’s done, the terms are combined in quadrature.  If it would help you get going, Andy did an open source Python client for PHD2 some time back:

 

https://github.com/agalasso/phd2client/tree/master/python

 

You might also want to expand the list of things you want to track.  For example, a large excursion will often ruin an image even though the rms statistics for the entire frame may not look that unusual.

 

Good luck,

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CACYRTaOc_ZYPeDX0ioKBuqHYzMBY8PxXSO5DvBc18RkTCO0LMQ%40mail.gmail.com.

[Brian Valente]

Bill you might look at the open source for NINA? - they have a PHD monitoring pane that mimics what you are describing

https://bitbucket.org/Isbeorn/nina/src/master/

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CACYRTaOc_ZYPeDX0ioKBuqHYzMBY8PxXSO5DvBc18RkTCO0LMQ%40mail.gmail.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

nature portfolio brianvalentephotography.com 

other astronomy https://www.brianvalentephotography.com/astrophotography/ 

[lmcl...@umich.edu]

Hi Bill,

If you are working in Windows, you can use AutoIt to capture the actual values being displayed in the PHD2 window.

https://www.autoitscript.com/

You could compile a small script to retrieve the values you want and then call it from your Python script.

Lamar

[Bill Richards]

Hi Bruce,

> Andy did an open source Python client for PHD2 some time back

Yes, I've already incorporated that Python code into my app.  I supposed now I need to figure out how to get the data I need - at the right times - and regenerate the total error RMS value.  

> You might also want to expand the list of things you want to track. 

Currently, the utility monitors a number of operational parameters, including:

1) Mount is tracking.

2) Mount coordinates are within 2 arc-min of the original coordinates (allows for dithering).

3) Meridian flip happened when it was supposed to.

4) PHD2 is guiding (with accommodations for auto-focus, dithering, and meridian flip)

5) PHD2 total RMS error is below some threshold <=== This is what I'm trying to get working

6) Number of images files in a specified folder is continuously increasing.

I've lost too many precious hours due to problems associated with one or more of these things, so if there is an independent monitoring utility watching over everything I should get alerted before too much time passes.

Regards,

Bill

[Bill Richards]

Brian,

I did think about that and may eventually dig into NINA.  I was hoping there was an easier way to get the data than to have to "reinvent the wheel".  If I can't figure it out using the PHD2 server, I'll take a look at how the NINA geniuses did it and shamelessly plagiarize their work.  :)

Bill

[Bill Richards]

Lamar,

Thanks - I'm unfamiliar with this software and may look into it.  My preference is to have a self-contained app, however, so I'm going to try to get the data from PHD2 first.

Regards,

Bill

[Brian Valente]

Couple thoughts

First, you might look at Carl Bjork's dashboard project, it seems like he's gotten quite far and is a nina plugin 

Second, it seems like you are doing an awful lot of work to figure out when something goes wrong. The things you mention you are spending too much time on might be better handled by making sure they don't happen in the first place ;) 

aside from that, NINA already reports on many of the parameters you mentioned

- guiding failures

- coordinate drift

- RMS (or more accurately refocus if RMS error is above a certain %)

it just seems like you are putting a lot of work into something that could (or is) handled elsewhere

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/69d7056a-3df5-4400-835a-eaa9cd295bbdn%40googlegroups.com.

[Bill Richards]

> you might look at Carl Bjork's dashboard project

Thanks for the point.  I'll have a look at what he's developed.

> it seems like you are doing an awful lot of work to figure out when something goes wrong. 

> The things you mention you are spending too much time on might be better handled by 

> making sure they don't happen in the first place

I don't disagree.  But I am human after all, and I occasionally do make mistakes that lead to these problems.  

For example, I changed a meridian setting on my mount, not realizing that it would cause NINA to NOT perform a meridian flip.  There are no sanity checks on such things and I lost multiple hours of data that night.  

In another case, I set up a target in NINA's advanced sequencer but didn't like how the coordinates framed the target so I made manual adjustments to frame it the way I liked.  I didn't realize that later that night, NINA would decide that the coordinate drift was too high and moved it back.  More data lost.  So in that case, the NINA safeguard was actually what caused the issue (albeit because I didn't set it up correctly).

There are other unforeseen events as well.  In one case, I lost connection to the camera (faulty USB cable).  No image files saved for hours.

> aside from that, NINA already reports on many of the parameters you mentioned

> - guiding failures

> - coordinate drift

> - RMS (or more accurately refocus if RMS error is above a certain %)

NINA uses HFR to trigger a refocus, not RMS error.  I don't believe that NINA monitors RMS error, but I could be wrong about that.

And while NINA does detect some of these problems, that tiny little "ding" isn't enough to wake me up.  Perhaps there's a way to intercept the NINA warnings and use those?  Maybe something else I can explore.

In any case, I need something that monitors critical operating parameters (with user-defined thresholds) and will sound an alarm until I wake up and silence it.  I'm all for making use of existing code or apps whenever possible.

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i6z8ui5SG%3Dd%2BHSZ%3DuZkbz4XC4vbFohfq5_0gSxe_n1WTA%40mail.gmail.com.

[Bill Richards]

After examining Andy's guider.py code more closely, I believe that the "GetStats" method returns the total RMS error in stats.rms_tot.  He uses StdDev instead of RMS to compute the value but if I understand correctly, it's effectively the same in this case.

His code excludes periods of dithering, so it appears this will give me the value I'm seeking.

Does that all sound correct?

 

- Bill

[Brian Valente]

>>>I don't disagree.  But I am human after all, and I occasionally do make mistakes that lead to these problems.  

yep completely understand

>>>For example, I changed a meridian setting on my mount, not realizing that it would cause NINA to NOT perform a meridian flip.  There are no sanity checks on such things and I lost multiple hours of data that night.

In this and the other examples you mention, these all seem like temporary things that will get resolved on the learning curve. Obviously you can do whatever you like, it just seems to me like a lot of work for things that you will eventually sort out. The last thing I want is something pinging and waking me up in the middle of the night unless it's about to rain on the telescopes!

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CACYRTaOP0cE2K7DThpDDFFJ1jKRdr8yySDs9UV63iVyRXSLWWQ%40mail.gmail.com.

[Bill Richards]

LOL - Now I have to attach a rain sensor and detect that, too!

I've been imaging DSOs for over 3 years now, but I don't have a permanent setup and I only get out to a dark sky site about once a month.  Consequently, the opportunity for error is higher than I would like.  Having this monitoring utility as a safety net should help prevent a loss of precious dark sky hours.

As a side note, I think I have it working now.  Using the PHD2 camera simulator and attached to my actual mount, I can see the RMS values incrementing in the PHD2 display and those same values are mirrored on my monitor display.  So it appears I have this one tackled.  Thanks for your guidance (no pun intended).

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i4nKC1zyraQBbknGdBNezQihRDE5-TPAH%3DkV8z3iJmNvQ%40mail.gmail.com.

[Carl Björk]

Hi Bill,

Yes I implemented GetStats using Andy's optimization (iterative way of doing it instead of recalculating it each time).

The dither is indeed excluded.

The total RMS is only for the ongoing "session". If a dither occurs or if the guiding stops (ie: OAG focusing, target change, etc) it will trigger a new "session" and RMS will be calculated for that new session only.

Cheers,

Carl

[Bill Richards]

Hi Carl,

Thanks for developing and publishing this Python code.  It's working very well for me.

What would I need to do to prevent the Stats from resetting following a dither?

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/83121393-3be8-456c-972e-a86c87fc45e3n%40googlegroups.com.

[Carl Björk]

Hi Bill,

Hmm sorry I did this a few months ago and got a bit confused, let me first clarify what I did and what I did not.

I did a 3rd part project to send over those values to a MQTT broker for my dashboard https://github.com/palmito9/phd22mqtt/blob/main/Phd22MQTT.py

In this context I made a change to guider.py and made a pull request, not merged yet but it's here if needed https://github.com/agalasso/phd2client/compare/master...palmito9:phd2client:master

Now I can help with your request, in Andy's algorithm there is an accumulator and RMS gets reset each time settling is completed (following dither).

So you would have to look into the guider.py file in the Guider._handle_event method, comment lines 223-225:

            self.accum_ra.Reset()
            self.accum_dec.Reset()
            stats = self._accum_get_stats(self.accum_ra, self.accum_dec)

That will prevent RMS stats to be reset to 0, while still filtering out errors during settling.

I hope this helps,

Cheers,

Carl

[Bill Richards]

Thanks, Carl - I'll have a closer look later today.

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/2e494adc-bc01-463b-b0bc-60573ce60dc1n%40googlegroups.com.

[Bill Richards]

Hi Carl,

I believe that line 225 needs to remain uncommented to prevent undefined references later in that state code.  Just commenting out the RA and Decresets, it seems to work very well.  My display reflects the PHD2 graph display exactly, provided that both are rest at the same time.

Thanks for your help!

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/2e494adc-bc01-463b-b0bc-60573ce60dc1n%40googlegroups.com.

[Bill Richards]

Brian & Carl,

I finally got a chance to use my monitoring utility at a dark sky site a few nights ago and noticed that after a long period of time, my RMS stats begin to stray from what PHD2 is reporting.  I suspect that PHD2 implements a sliding window to compute the RMS values while my utility just keeps accumulating until the session is ended.  The sliding window makes a lot of sense since you really don't want data from hours ago skewing the values from the last 30-60 minutes.  Does anyone know how large that sliding window is or how I can find out?

Bill

[bw_m...@earthlink.net]

The measurement window size is set in the graph UI, there’s a ‘History’ section there and the top-most pull-down is for the window size. 

 

Bruce

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Bill Richards
Sent: Friday, December 15, 2023 3:26 PM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Reading Guide Error RMS Values from PDH2 Server

 

Brian & Carl,

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/eb4cdade-3cec-4858-b64f-0c075bbd76ecn%40googlegroups.com.

[Bill Richards]

So it's just the width of the graph window that's used?

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/006201da2fb2%24d3bbdf00%247b339d00%24%40earthlink.net.

[bw_m...@earthlink.net]

It’s the number of data points that you specify in the pull-down. 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CACYRTaPBuJmiie1%3Dn6od-0dmVCxve%2BOio_mEJ%3DqxGmF82EExCA%40mail.gmail.com.

[Bill Richards]

Got it - thanks!

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/007101da2fc6%24c906ff40%245b14fdc0%24%40earthlink.net.

[Bill Richards]

On a different topic, last week while using my utility to monitor an imaging session, there were a couple of times during the night when things froze.  When I killed the Python code, everything unfroze and continued operating.  I assumed that I had a bug in my code  so I started troubleshooting.  It's difficult to reproduce, sometimes taking many hours to occur.  But I managed to track it down to a call to PixelScale():

    def PixelScale(self):
        """get the guider pixel scale in arc-seconds per pixel"""
        res = self.Call("get_pixel_scale")
        return res["result"]

When the code locks up, it never returns from the self.Call statement, which appears to get stuck in an infinite loop awaiting a response from a JSON RPC that never comes (or was sent and somehow lost).

For the time being, I changed my code to only call this function once at the very start, with the assumption that the pixel scale should not be changing during any given imaging session (seems to be a legitimate assumption).  Once I did that, I've been able to run multiple 10-12 hour sessions with no lock-ups.

Any idea what might be happening here?

Bill

[bw_m...@earthlink.net]

The likely reason is that your code “lost” the RPC return message, that’s easy to have happen if you’re not careful.  Calls like this one usually generate a return message almost instantly. In order to figure it out, open the appropriate PHD2 debug log file and do a text-search on ‘evsrv’.  This will find all the network traffic with PHD2 clients and the entries are clear enough that you’ll be able to see the RPC request/response pairs.  My guess is that you will find the RPC return for your call logged right underneath the JSON request.

 

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/56cc6a4f-e1a1-4bdf-923b-a8855f69ccbfn%40googlegroups.com.

[Bill Richards]

Hi Bruce,

Thanks for the pointers on where to look.  I believe you are correct - PHD2 does appear to reply to every RPC according to the Debug log.  Here is an excerpt of "evsrv" entries from a Debug log file that contained one of the hangs:

16:41:54.468 00.001 22184 evsrv: cli 0F037318 response: {"jsonrpc":"2.0","result":6.46297,"id":1}
16:41:55.481 01.013 22184 evsrv: cli 0F037318 request: {"method":"get_pixel_scale","id":1}
16:41:55.482 00.001 22184 evsrv: cli 0F037318 response: {"jsonrpc":"2.0","result":6.46297,"id":1}
16:41:56.488 00.226 22184 evsrv: cli 0F037318 request: {"method":"get_pixel_scale","id":1}
16:41:56.489 00.001 22184 evsrv: cli 0F037318 response: {"jsonrpc":"2.0","result":6.46297,"id":1}
16:41:57.502 01.013 22184 evsrv: cli 0F037318 request: {"method":"get_pixel_scale","id":1}
16:41:57.503 00.001 22184 evsrv: cli 0F037318 response: {"jsonrpc":"2.0","result":6.46297,"id":1}
16:41:58.515 00.122 22184 evsrv: cli 0F037318 request: {"method":"get_pixel_scale","id":1}
16:41:58.516 00.001 22184 evsrv: cli 0F037318 response: {"jsonrpc":"2.0","result":6.46297,"id":1}
16:41:59.529 01.013 22184 evsrv: cli 0F037318 request: {"method":"get_pixel_scale","id":1}
16:41:59.530 00.001 22184 evsrv: cli 0F037318 response: {"jsonrpc":"2.0","result":6.46297,"id":1}
17:04:18.076 00.001 22184 evsrv: cli 0F037318 short write 0/300 Input / Output error
17:04:18.077 00.001 22184 evsrv: cli 0F037318 disconnect
17:09:36.980 00.085 22184 evsrv: cli 0F037318 connect
17:09:36.982 00.001 22184 evsrv: cli 0F037318 request: {"method":"get_pixel_scale","id":1}
17:09:36.983 00.001 22184 evsrv: cli 0F037318 response: {"jsonrpc":"2.0","result":6.46297,"id":1}
21:40:20.453 01.521 22184 evsrv: cli 0F037318 disconnect

Note that at 16:41:59 a response is generated but then everything stops until 17:04 when I noticed the lockup and killed the Python program.

But it's not my code that's calling the JSON RPC; it's Andy Galasso's (@agalasso) code from here.  I'm hoping he can shed some light on this.

 

- Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/001c01da310d%241eb5fcb0%245c21f610%24%40earthlink.net.

[Michael A. Phillips]

I'm very keen on using this with Home Assistant!  Does the script support auth?  So far I've gotten it to connect to my PHD2 on another machine but it's only outputting this:

StarMass': 646251, 'SNR': 90.77, 'HFD': 2.66, 'AvgDist': 0.81, 'ErrorCode': 1, 'guidestate': 'Guiding', 'IsSettling': 0, 'rmsTot': 0.5199935182196411, 'rmsRa': 0.24844959647853057, 'rmsDec': 0.4567997996935808}
Traceback (most recent call last):
  File "/Scripts/phd22mqtt/./Phd22MQTT.py", line 79, in push_mqtt_message
    client = mqtt.Client("guider", clean_session=False)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/paho/mqtt/client.py", line 766, in __init__
    raise ValueError(
ValueError: Unsupported callback API version: version 2.0 added a callback_api_version, see migrations.md for details
INFO:root:PHD2 Checking Connection
INFO:root:Error pushing data: {'Event': 'GuideStep', 'Timestamp': 1710180799.715, 'Host': 'MAPHILLI14-WORK', 'Inst': 1, 'Frame': 5236, 'Time': 6820.853, 'Mount': 'On Camera', 'dx': 0.124, 'dy': 1.197, 'RADistanceRaw': -0.271444552, 'DECDistanceRaw': 0.832381831, 'RADistanceGuide': -0.171096699, 'DECDistanceGuide': 0.832381831, 'RADuration': -13, 'RADirection': 'East', 'DECDuration': -59, 'DECDirection': 'South', 'StarMass': 615668, 'SNR': 85.16, 'HFD': 2.38, 'AvgDist': 0.93, 'ErrorCode': 1, 'guidestate': 'Guiding', 'IsSettling': 0, 'rmsTot': 0.5711018079702705, 'rmsRa': 0.25161674023441355, 'rmsDec': 0.5126853724271051}
Traceback (most recent call last):
  File "/Scripts/phd22mqtt/./Phd22MQTT.py", line 79, in push_mqtt_message
    client = mqtt.Client("guider", clean_session=False)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/paho/mqtt/client.py", line 766, in __init__
    raise ValueError(
ValueError: Unsupported callback API version: version 2.0 added a callback_api_version, see migrations.md for details
INFO:root:Error pushing data: {'Event': 'GuideStep', 'Timestamp': 1710180800.922, 'Host': 'MAPHILLI14-WORK', 'Inst': 1, 'Frame': 5237, 'Time': 6822.043, 'Mount': 'On Camera', 'dx': 0.098, 'dy': 0.254, 'RADistanceRaw': -0.10756712299999999, 'DECDistanceRaw': 0.166765137, 'RADistanceGuide': 0.0, 'DECDistanceGuide': 0.0, 'StarMass': 603204, 'SNR': 85.18, 'HFD': 2.33, 'AvgDist': 0.73, 'ErrorCode': 1, 'guidestate': 'Guiding', 'IsSettling': 0, 'rmsTot': 0.5604804396542293, 'rmsRa': 0.24578135862392753, 'rmsDec': 0.5037160380491915}
Traceback (most recent call last):
  File "/Scripts/phd22mqtt/./Phd22MQTT.py", line 79, in push_mqtt_message
    client = mqtt.Client("guider", clean_session=False)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/paho/mqtt/client.py", line 766, in __init__
    raise ValueError(
ValueError: Unsupported callback API version: version 2.0 added a callback_api_version, see migrations.md for details
^CTraceback (most recent call last):
  File "/Scripts/phd22mqtt/./Phd22MQTT.py", line 117, in <module>
    time.sleep(CHECK_CONNECTION_INTERVAL)
KeyboardInterrupt

[Brian Valente]

>>> I'm very keen on using this with Home Assistant! 

Can you elaborate on this? Don't see this kind of application every day

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/e88455d9-1f59-4265-aa31-85b7451e5e76n%40googlegroups.com.

[Michael A. Phillips]

I have homeassistatnt pulling from my MQTT for NINA events, weather, indi-allsky etc....

[Michael A. Phillips]

I guess all I need to know to keep making progress is how to use the python file to auth to my mosquitto MQTT server?

TIA,

Mike

[Carl Björk]

Hi Mike,

This version does not support authenticating to the MQTT broker yet.

But it should be super easy to add.

You only need to modify the push_mqtt_message function to add one line:

    def push_mqtt_message(self, data):
        try:

            client = mqtt.Client("guider", clean_session=False)

            client.username_pw_set("yourUsername", "yourPassword")
            client.connect(self.mqtthost)
            client.on_log = self.on_log
            log.info("Pushing data")
            log.info(json.dumps(data))
            client.publish("sensors/guider", json.dumps(data))
            client.disconnect()
        except KeyboardInterrupt:
            raise KeyboardInterrupt
        except:
            log.info(f"Error pushing data: {data}", exc_info=True)

I'll soon release something more complete online, including a windows service version which is more convenient to use.

I just have too much other work in progress at the moment.

Cheers,

Carl

[Michael A. Phillips]

I got it working thanks!!!

I thought I posted the steps and config, but can resend if they got lost!

I can get hass and PushOver notifications now when guiding goes sideways!!!

PHD <> Python <> MQTT <> Homeassistant <> Mobile Phone!

Mike Phillips

[Carl Björk]

That's great, well done!

Carl

[Michael A. Phillips]

I'll get this written as a blog but for now....

PHD guide star loss problems and my mobile phone notification solution!

https://youtu.be/tYQnZ4mXdp0

Mike