Anyone fancy writing a plug in?

[NickH]

Either way it will be invaluable..plug in would make it all integrate with other components (like plate solving)

[Ben Ritchie]

Ben, if I read this right, then you are writing an independent applet rather than a plugin?

Yeah - although strictly speaking all i'm writing is a bit of code to parse Swift/BAT alerts, I have the other bits and pieces already in one form or another so it's easy to put together. So it will sit there in the background listening and if an alert comes in it'll either give you the option of going there, or in 'full auto' mode will go there and start imaging without you doing anything ... provided you have CCDSoft, at least (at the moment anyway) ...

It's capable of plate-solving in a limited sense already, because it can call into TheSky via the Bisque COM interfaces.

[NickH]

So, you could pass this over for integration into say the EQDIR/EQMOD control, or would you develop it to completion in the sense of it working with any ASCOM app as a plug in?

[Reggie]

Absolutely superb work guys, much kudos, this is just the sort of thing i was hinting at in the 'Neil' thread, for imaging beginners/advanced imagers who would like to contribute in a scientific manner. Especially ideal for the begiiners who don't necessarily have the skill to pull all of the necessary data in themselves.

Any thoughts on expanding it so the data collected can be verified (photometry backend? theres a superb photometry beta software thats either web based or PC based 25GB linux version, for web http://live.astrometry.net/ and PC based http://www.astrometry.net/ thanks PsychoBilly) and once any image data is collected what you would/should do with it once verified?

You'd already mentioned plate solving I see as I was writing this

[chrisshillito]

Cheers Nick, i'm calling into the ASCOM chooser via COM - if it will do protection against invalid slews then that does save some effort.

Ben,

The chooser doesn't provide any protection. What was mentioned was that when using the EQASCOM driver you get inbuilt horizon profile. EQASCOM is a driver for EQ mounts only (currently). Personally I believe limit control should be the responsibility of the driver as it seems unreasonable to expect each client application to implement its own separate limit/collision handling - however not all ascom drivers are as enlightened as EQASCOM in this regard and many only provide a very thin interface to the mount requiring the client apps to do all the work.

If you're worried about limts you may also want to consider issuing a pier flip warning if the target is on the other side of the meridian (just so folks can get ready to catch thier eyepieces and cameras )

Chris.

[NickH]

Some neat ideas here, but I think once Ben has coded up as much as he's happy to, we put this in to the open source community/EQ/ASCOM groups and see how it will/can be developed and also gives more opportunity for testing (given the cloud conditions here, and my work schedule, I may have limited time)

Some absolutely superb ideas though, and Ben's made monumental progress in such a short space of time, so the kudos definitely belongs to him

[steppenwolf]

plug in would make it all integrate with other components (like plate solving)

One of the nice things about using POTH is that positional data is shared amongst all active components so, for example, using MaximDL as one of the components, Pin Point Astrometry (an included astrometry engine) could be invoked and the base search carried out using the positional data in the FITS header which in turn would have been collected and distributed at imaging time by the POTH. I have no doubt that other programs would work in a similar manner.

[Ben Ritchie]

It should all be very extendible (provided you can write a bit of Java, I guess - or talk nicely to someone who can ) - so it can chase supernovae as well as GRBs, or I guess follow a list of your own RA/Dec for variable stars etc. ASCOM makes it very simple.

For now all i've done with slew limits is convert from RA/Dec to Alt-Az and avoid anything below 30 degrees elevation. That misses out a few things possibly, but below 30 degrees is usually down in the crud here anyway and for the majority of these things you're going to want to be near the zenith to go as deep as possible. That approach makes it easy to spot a pending meridian flip too, so i'll add that to the 'to do' list.

Got one annoying bug to fix and need to make a few things configurable (so you're listening on your email, not mine plus a few instructions wouldn't go amiss - doesn't need much though I hope. And then i'll have some code for people to play with if anybody is feeling brave. It's quite cool when an email drops into your inbox and the 'scope sets off in persuit

[steppenwolf]

It's quite cool when an email drops into your inbox and the 'scope sets off in persuit

I'll bet!

[Psychobilly]

Cracking piece of work this BeN

[mcrossley]

A couple of questions...

Ben how are you handling email? I already have code written that scans the Outlook In-Box. Writing a universal email handler looks problematic to me (I use branded GMail for instance, and there are loads of other email clients and on-line services now)?

RSS would be universal, but it requires active scanning of the server to detect updates, Uni. Glam. may not want lots of people hitting their server every few minutes?

For speed this service needs to be push rather than pull, so RSS is out I think; practically I guess that leaves just email?

Mark

[Ben Ritchie]

Mark, i've written it using the JavaMail API so it'll connect to any POP3 or IMAP inbox. You just define the host (e.g. pop.1and1.co.uk for me), username and password and it kicks off a worker thread and polls the mailbox every minute or so - the network load for that is pretty low - and scans anything new for signs that it's an alert. I've found an AAVSO page here

http://www.aavso.org/observing/programs/hen/filterdatabase.shtml

that allows you to sign up for alerts, so you get something like this dropping into your email account

http://www.aavso.org/observing/programs/hen/archive/

my code just strips out the RA/DEC from that, bounds-checks it, asks you if you want to go there and heads off if you do (or, if you have CCDSoft installed, you can set it to head off there and start taking UVBRI images automatically if you're brave enough to leave your observatory open and unattended!).

The code's pretty basic really, but I think that's a simple way of doing what Nick wants - the idea is that you just kick this off in the background and it sits there until an alert comes in and you can decide at that point if you want to interrupt what you're doing. In due course i'll strip out more of the information from the email to make the alert box a bit more useful in deciding if you have a reasonable chance of seeing the transient or not to help make the decision. 90% of nights you'll probably see nothing from it at all, but the hope's that the timing is right for somebody - will be sooner or later, and the brigher of these should be well within reach.

Right now i'd suggest a dedicated mailbox - it should leave non-alert email untouched, but "no warranty expressed or implied" or whatever the legalese is for saying that it may go on a rampage and delete email you want...

[mcrossley]

Right now i'd suggest a dedicated mailbox

That is key, otherwise your regular mail reader may download and delete the message from the server before your widget gets a chance.

[Ben Ritchie]

Ok, volunteers required

You'll need:

- ASCOM installed (i'm using v5, I think it'll work with v4 too) and connecting to your 'scope

- Java installed (i.e. doing start -> run -> cmd and typing java -version should give some output)

- a dedicated email address is highly advised, because there's no guarantee that this won't mess up existing email (although it shouldn't), if need be I can define one for you

and ... most importantly ... a high tolerance for software that doesn't quite work right and a willingness to tell me how it broke

If that's you, please drop me a PM with some contact details - probably only worth a couple of people doing it at first while i'm ironing out the niggles of getting it working for other people. Probably not going to have time today to tie up the loose ends, but can get something out tomorrow.

My main remaining question is the precise format of alert emails. I'm signed up for a feed, but need a real GRB to happen now! For now there's a test application that'll put a faked up email in your inbox - you can define a suitable RA and DEC for that and the application should pick it up and go there. That's the theory anyway...

[Doc]

Can't help at the moment as i'm a dob man only.

But I'm sure hell interested in this. keep us posted.

[mcrossley]

Ben

Given the weather it could be months before I am both out with the scope AND a GRB occurs! Though at other times I could leave it running with scope simulator. The Gemini control unit on the G11 checks for below horizon slews, but I think you have incorporated this in your code as well now (presumably you need to configure your lat/long).

Mark

[steppenwolf]

PM sent

[Ben Ritchie]

Mark - the testing is to make sure that when that alert does arrive at the right time the app doesn't barf with a NullPointerException

Testing can be done indoors I think, no need for darkness or clear sky (or a GRB). All that needs checking is that when a correctly-formatted email drops into your inbox the application picks it up and the 'scope slews to the RA/DEC in the email - so when the slew is complete the mount should be reporting the RA/DEC in the email (the correspondence between the reported RA/DEC and the pointing location on the sky is obviously down to mount alignment itself). Most likely problems are bugs driving the mount through ASCOM, my initial experimentation shows that the ASCOM simulator, Celestron driver (for the HEQ5) and AP driver don't behave in exactly the same way as each other.

I have code to send a faked-up alert email to your mailbox, so it's just a case of checking that it all works when that's run.

There's also a chance that the email fetching and parsing is incorrect, so that messages don't get picked up or get misinterpreted so that the 'scope goes somewhere other than the correct coordinates. I think that works correctly but I can unit test it easily enough here though, so I'm mainly after checking that the mount commands get issued correctly.

Steve, i'll drop you an email with code tomorrow - thanks for being a guinea pig!

[NickH]

Mark - the testing is to make sure that when that alert does arrive at the right time the app doesn't barf with a NullPointerException

T

Steve, i'll drop you an email with code tomorrow - thanks for being a guinea pig!

You have my email Ben , be warned, if I do get testing on it, the reports could be substantial (the last one I wrote on some software was 168 pages..lol...)

Should be able to give it a blast Tuesday/Thursday this week

Just kidding btw..

AOL I guess okay for the email account (just set a new one up)

[steppenwolf]

Ok Ben, I await the code and have a choice of simulators to try although the EQMod simulator would be the weapon of choice but let's see!

[Psychobilly]

With the way the weathers lookign at the moment then there's plenty of test time available

Great piece of work though Ben

[Ben Ritchie]

It continues to evolve! A number of the more annoying bugs are gone now, and it's basic-but-usable - here it is with CCDSoft in the background running in 'full auto' mode

[steppenwolf]

I am really pleased to report that I have the system up and running beautifully and automatically commanding EQMod to slew the telescope to the required coordinates using the EQMod Simulator. My experience with the EQMod system normally indicates that if the simulator works, the real mount will definitely work! - Well done Ben!

[NickH]

New build coming soon too, Ben's doing amazing work on this.

Naysayers - 0

Doers - 2

Start testing myself later this week...given time

[Ben Ritchie]

Getting closer ... dark, clear sky ... southern hemisphere ...

The following is a alert from GCN distributed via the AAVSO International High Energy Network.

Please visit http://www.aavso.org/observing/programs/hen/archive/ for more information on this alert.

-----------------

GRB Detection Date: 08/11/21 20:35:32.85 UT

GRB Notice Date: Fri 21 Nov 08 20:36:12 UT

Center of Error Pattern RA: 89.264d {+05h 57m 03s} (J2000), Dec: -60.626d {-60d 37' 32"} (J2000),

Error Pattern Size (diameter arc min): 6min

Distance to Sun: 95.31

Distance to Moon: 86.40

Type of Notice (see web page for details): Swift-BAT GRB Position

Comments from GCN: SWIFT-BAT GRB Coordinates. This is a rate trigger. A point_source was found. This does not match any source in the on-board catalog. This does not match any source in the ground catalog. This is a GRB. This trigger occurred at longitude,latitude = 186.66,4.50 [deg].

-----------------

Info: SWIFT/BAT alert received

Debug (Fri Nov 21 21:18:43 GMT 2008): GrbCommand pending for Burst Coordinates: RA: 5h 57m 4s, DEC: -60° 37' 34"

Comments: SWIFT-BAT GRB Coordinates. This is a rate trigger. A point_source was found. This does not match any source in the on-board catalog. This does not match any source in the ground catalog. This is a GRB. This trigger occurred at longitude,latitude = 186.66,4.50 [deg].

Command received: Burst Coordinates: RA: 5h 57m 4s, DEC: -60° 37' 34"

Comments: SWIFT-BAT GRB Coordinates. This is a rate trigger. A point_source was found. This does not match any source in the on-board catalog. This does not match any source in the ground catalog. This is a GRB. This trigger occurred at longitude,latitude = 186.66,4.50 [deg].

SlewCommand pending for Burst Coordinates: RA: 5h 57m 4s, DEC: -60° 37' 34"

Comments: SWIFT-BAT GRB Coordinates. This is a rate trigger. A point_source was found. This does not match any source in the on-board catalog. This does not match any source in the ground catalog. This is a GRB. This trigger occurred at longitude,latitude = 186.66,4.50 [deg].

Slew pending to Burst Coordinates: RA: 5h 57m 4s, DEC: -60° 37' 34"

Comments: SWIFT-BAT GRB Coordinates. This is a rate trigger. A point_source was found. This does not match any source in the on-board catalog. This does not match any source in the ground catalog. This is a GRB. This trigger occurred at longitude,latitude = 186.66,4.50 [deg].

Debug (Fri Nov 21 21:18:47 GMT 2008): ASCOM driver reports longitude: 0.0095

Debug (Fri Nov 21 21:18:47 GMT 2008): ASCOM driver reports latitude: 55.1395

Info: ASCOM driver reports lat/long (55.1395, 0.0095)

Info: Target at altitude: -37.697108799193664 degrees

Info: Target outside slew limits, ignoring

if it was somewhere I could see the 'scope would be on target within 30s of the alert being mailed.