SGP has built-in support for Alnitak Flat-man flat panels, but I needed a way to control my Spike-a flat panel with SGP. I put together an emulator program that makes the Spike-a panel look just like a Flat-man to SGP. Just in case this is useful to anyone else with a Spike-a panel, I wanted to share it here.
I have a Flat Fielder on the way right now! I was looking at a way to control it from SGP so your sharing is very much appreciated. I spoke to John at Spike-a and he sent me the command line driver which I was going to script into the ‘Pre-Event Options’ for setting the brightness levels. From what it says in the the readme file this will be a much more elegant solution. +1 for the native SGP support!
Just wanted to let you know I got the emulator up and running and it works great!
I tried playing around with running a script at the start of each flat event but apparently SGP doesn’t run scripts for ‘flat’ events? I suppose one could just add a pause to allow setting the intensity for each filter, but SGP has me spoilt - I want everything to be able to run automatically! Anyway, your emulator does the trick!
One question for you: my Lum flats are less than 1 second on the lowest setting. Do you use an ND filter or something else with your panel?
Thanks for the update, glad to hear the Alnitak emulator it is working for you.
I think if you use the Flat Box Brightness setting in SGP (Control Panel => Filters => Define filter List => Flats => Flat Box Brightness) then SGP will control the panel brightness and you would not need any script.
I have not taken any real flats with my panel yet, but one thing I found was that when I first setup the panel I installed the USB dimmer box in series with the manual dimmer box (the one with the dangling keyfobs ) I later realized that this was causing quirky results like blinking at low intensity settings, and by removing the manual dimmer box (use only the USB dimmer box) you get a much smoother range of intensities, especially at the lower range (no blinking). Not sure if this is the case for you but figured I would mention it.
If you have already removed the manual box, there is one other issue that may be preventing the panel from getting its dimmest illumination. The Alnitak panel has brightness levels 0-255, but the Spike-a has 0-1023. The emulator maps the Alnitak setting from SGP linearly to a Spike-setting, so the lowest value (1) from SGP results in the value “4” being sent to the panel.
We could change the mapping to be non-linear so that low values map directly one-to-one. That would allow you to use the values 1, 2, 3, etc. Not just 4, 8, 12, … Let me know if you want to pursue this and I’ll put together a new build of the emulator.
Funny you should mention that… I have an ASCOM switch driver for the Spike-a panel, available here.
SGP does not currently have the ability to control flat panels as ASCOM switch devices, so Alnitak emulation was the way to go for now.
Even if flat panel makers provided ASCOM switch drivers, there would still need to be some conventions adopted. In patricular: does the driver implement two switches – an analog switch for brightness and a boolean switch for on-off (the Alnitak model). Or does one implement a single analog switch with 0 = off (The Spike-a model.) I guess this would be a good topic for the ASCOM forum.
You’re right. The scripts don’t run in a light event either. I think this is a windows (8.1) related problem. That, and my programming skills date back to ms-dos basic from the 70’s… The script calls an .exe file with the brightness parameter, and I’m guessing they both need to be in a specific folder or have god-like security settings? Anyway, I’ll save this puzzle for a rainy day since the built in Alnitak support through Andy’s excellent emulator works so well.
I did and it works beautifully. I rough tested the brightness levels for each filter and then I ran the flats calibration wizard, et voila, the flats wizard creates an instant flats target with pre-set events to match each light event and filter. Very slick!
I had thought about the 1024:256 resolution but even when I set the panel manually to ‘1/1023’ (the lowest possible setting) it still only calibrates to a 1.78 second exposure. Also, my darkest filter (OIII) calibrates to a 2.1 second exposure at the highest setting so I think the easier solution may be to add an ND filter gel under the frame to lengthen all of the exposures.
That’s exactly the reason I pushed the Switch interface through. All we need to do is persuade the application developers to join in.
I’d do exactly what you have, a single analogue switch to control brightness. 0 is off and MaxValue is full brightness. I can’t think of a use case where separate brightness and on/off control would help.
At one point I requested native Spike-a panel support from Jared and Ken for SGP and I think they added it to their to-do list. But in retrospect it would have been better to have asked for ASCOM switch panel support. Perhaps Ken and Jared would consider adding that now that we have at least one ASCOM controllable flat panel?
You may have to run SGP as admin for it to be able to run VBS scripts.
I’ll have to look into this more. Is there a reference device for flat panels? The issue (from an application developer perspective) about using the switch interface is that it’s so generic. This is both the switch’s greatest strength and largest downfall. Other ASCOM devices set forth a set of contracts that both sides can use to develop against and which there is a switch interface it doesn’t provide any sure fire way to implement a flat box.
For instance, above Chris mentions a single analog from 0 to X for brightness. This seems to be fine for a very simple flatbox. What about when there is a shutter on the flat box like the FlipFlat? How does the application know which switch to toggle to open/close the shutter or turn the light on or off? Should we query for the # of positions that each switch has and make some assumptions? What about if the shutter has 5 states (Open, Opening, Closed, Closing, Unknown) and the flatbox only has 2 (on/off). How are we to know to differentiate between the two?
I also know that one of our users has a flatbox that can change light frequency as well. How do we account for something like that where there could be multiple lights in the flatbox that they would like mixed differently based on their filter? (I’m not sure we could really ever account for this…just mentioning it to illustrate that flatboxes can vary a lot)
I have no problem implementing a Switch based flatbox in SGP. We just need a reference architecture to use or we’ll have to develop our own. We need a contract by which to use a switch to control a flatbox that can be reusable and generic enough that multiple flatboxes can fit into the paradigm.
Using the Switch device would work like this:
First you need to decide what you are going to support. I guess this would be a light control and an optional Open/Close state such as with the Flip Flat. It probably can’t be every possible device that can be imagined. Are you seriously planning to support multi frequency light boxes?
In the flatbox setup:
The user selects a switch driver from the list of switch devices. You have to rely on the driver choosing a Flat controller, which he identifies by it’s name.
You open the driver and present the user with the switches that are available, there will be one or two, one for the light intensity and one for the shutter.
The user chooses the one that controls the light intensity and the one that controls the shutter. You remember the choice.
That should be it, you know the switch ProgId and what switches control the shutter and the light intensity.
You can read the maximum, minimum and step size from the driver and can use this to decide how the UI should look. A slider for an analogue control, and a check box for a binary control.
There’s a little more set up but not a lot. You read what needs to be set up from the driver, including the names.
You have to rely on the user choosing the light box switch and not for example the dew heater or observatory power control.
A Light box would probably have:
ID Name Min Max Description
0 Light Level 0 255 Light panel intensity
1 Shutter 0 1 Light panel shutter
Andy - I just took a look at your flat box references - quite expensive and even more so when delivered to the UK with duty and VAT. One of the designs uses a standard Nielson style clip frame, which I already use for my exhibitions. For £25, I can buy 5m of LED lighting strips (I never knew these existed) and have a go myself. The design has to be a simple matrix of white LED’s with two layers of white perspex. There is little room for anything else within the frame.
The controller will be a simple motor PWM controller, the same as for a dew heater…which leads me to an idea - if there is an interface for controlling a light box level, why not one for a dew heater? In terms of usage, it would be used on every session (I have refractors). If the Temperhum worked (big if) - SGP could increase the dew heater as the RH approached 100%. Dew heaters appear to be one of those things which seem to have been overlooked by all the image capture programs.
Let’s try not to muddy the waters here with sniping at manufacturers.
If we have a switch interface then everyone can use it. Your mickey mouse solution, mine, everyone’s. Lets work together on this.
Yes, a dew heater could be another switch interface. Personally I’d keep it out of SGP. Maybe a separate observatory management application would handle it.
This is why I came up with the Switch interface. There are a lot of things that may be needed in a remote observatory and it’s impractical to do ASCOM interfaces for all of them.
Some I can think of are:
Environmental monitoring (temperature, humidity etc.)
I would have put the TemperHum on a switch driver, it might have been more practical to hide it’s vagaries behind a driver.
Weather Monitor - possibly as a facade to a Safety Monitor.
Reviving an old thread here. I tried out your emulator as a daylight test and it works great! Thanks!
When testing directly without the emulator/SGP, I have found that, funny enough, for no-filter flats I have to have the box set to 1 (out of 1024) to give me over a 1s exposure. I’m sure for L it will be a tiny bit better and better still for RGB and narrowband.
But, was thinking, assuming spike-a support isn’t imminent in SGP, a non-linear mapping would be ideal as jumping to 4, 8, etc., is jumping too much.
Not sure if this is easy for you to implement, or if you’re open sourcing it?
Thanks for reminding me of this… it had slipped off my radar. The answer is yes to both… it is easy to implement and I would open source it. I’ll put it up on GitHub when I get a chance and post back here with the info.
In v0.4, the mapping from Alnitak intensity values (0…255) to Spike-a values (0…1023) was linear: y = x * 4
The new mapping in v0.5 is a polynomial: y = x + k x^4. This stays nearly linear for lower values of x, then grows more quickly to cover the full range.
I am building a remote private Observatory. I have developed Dome, UPS Power and Safety Hub ASCOM driver. Finally, I need to develop a Flat ASCOM driver, so searching and find this topic.
Through this forum, I saw a Sample: var X = new ActiveXObject(“ASCOM. SpikeAFlatFielder.Switch”); X.SetupDialog(); WScript.Echo(“hit ok to connect”); X.Connected = true; WScript.Echo(“hit ok to turn it on, brightest”); X.SetSwitchValue(0, 1023); WScript.Echo(“hit ok to go dimmer”); X.SetSwitchValue(0, 128); WScript.Echo(“hit ok to turn it off”); X.SetSwitchValue(0, 0);
I would like to ask the question: do I use VisualStudio build a Swith ASCOM program framework, implement the Connected, SetSwitchValue method? SGPro may use the ASCOM driver?