skybadger

Cheers for that, have you a link to your normal supplier ?

Are they third-party demo CCD boards that you are hooking into ?

I ...think... so. You need something to cut the cone of returning light to measure the zones. I have two Foucault devices, one from the stone age with a separate slit source and blade and a moving source one on a tripod stage. The second is much easier to use .

Foucault designs started with two half slits, one for the source and one for the sensor., one fixed, one moving independently to cut the return cone to detect the focal point for each coude zone. Then a bright spark realised that the same slit blade could do both, if the two positions were side by side or on top of each other, removing alignment problems. This further simplifies if the source is small enough to not need a slit. This arrangement is the moving slit because the source and slit a re on the same stage, using the same blade. Check out the stellafane web pages for a much better description. The problem with ronchi is it's qualitative while with Foucault it's very much quantitative. Typically glass pushers might use simulated ronchi patterns as comparisons to grind towards. While Foucault and the bath interferometer will tell you exactly where you are. I'd recommend if you are starting out to take a look at the bath. It's easy to build , quantitative, has a support community and easy to use. On the other hand, Foucault and ronchi will give you lots of practice aligning optics.

Indeed, alpaca is a rest web api specification that implements an interface to ascom, where the clients are typically windows ascom clients. However , if you want to write to an alpaca rest service hosted on your Pi device, feel free, it will work seamlessly. The same if you want the client end to be on your Pi and the device interface on anything else. I have a family of alpaca compliant devices coded at github/sky badger if you want to take a look. They are accessed from the ascom remote client running on the Windows server but also by many other non windows devices and are hosted on esp2866 Wi-Fi devices.

That's a plan. I'll take 3 other irons apart then. Need a small solid state 12 to 240 inverter now.

I have just been clamping a CFL Lamp to the end of the scope. Can the same be done with a neon to obtain calibration spectra ?

Ghats good, I never understood that method , I needed to measure my secondary, which is why I built a bath interferometer but I havent got round to using it in anger yet.

I built one using my existing cassegrain. It was really handy to put the pole withe the tertiary mirror through the primary mirror perforation. The focuser was mounted on a plate suspended across the frame poles. I think the reason I did it was to cater for an extended focal length as I moved the mirror spacing around to find the optimal spacing.

It's good to here of automation progress here. I followed the voyager path to handle multiple cameras using the virtual mount mode. However I'm still completing the dome automation so concentrating on that. I've got drag scripts that call external batch files for powering the whole setup on and off, using alpaca calls. I'm working on the shutter automation right now using my own home brew system at which point I'll be up and rolling..!

I expect that a solar charge regulator should limit the voltage to the battery to its safe charging range, fypically 12.6 to 14v for a lead acid battery. However mine is putting out more than that and a new one I have just bought does the same. I bought some 12v regulators to manage the load side voltage but as yet not working... I really don't like the idea of 19v across my lead-acids.

I have a solar cell charging a 12v 70ah battery through a charge regulator. The load output is separate from the battery charge output. But the output does not sit at a regulated 12v. What should I expect ? As a general rule, does everyone then use a high current 12v regulator to the load or does your regulator provide a regulated load output ?. Cheers Mike

That's pretty much how I started, but what was clear was that the star image is dependent on the exposure, adjusting the output by focusing the scope enabled me to refocus the guider. It's all in focus now though.

Hi Merlin, all. Mine is now assembled, on the scope and going through the commissioning process o f learning to use. I have a lodestar as guider and asi174 as camera. I have spectra of a CFL lamp and daytime fraunhofer spectrum, and learning to guide on the slit using phd2. Interesting thing is focusing. It looks in focus in the guider but has a distinct split spectrum in the camera. That means the star isn't focused in the slit. Focus until the spectrum has the minimum vertical dispersion. With no central split and refocus the guide camera... Using Altair as my trial star, had some problems with intensity but wasn't using first order. Have identified the micrometer setting for that now and taken some spectra using the simple line profile tool in maxim. So making progress, was about to have a go at del sag last night but the batteries went flat.. next time.

Hpc, stock gear, sdp, duval, should all stock standard sizes.

small then . I was expecting a shoebox on the side of a scope! Did you build the entire mount to carry the SHG ? Or was it something you had left over from other builds ? Will you be mountng this outside and imaging permanently ? I guess you use a panning mirror to scan the image across the slit or just use the sidereal motion ? sorry, bunch of questions.

Me too, let's see it!

So the unsigned long and an int on a esp probably occupy the same number of bytes (not uncommon for this type of hardware) but the way the compiler interprets the value changes.. if you put an ul into the int, it will be interpreted as an int , which is OK for positive values below half the maximum, but awful for negative values. However if they are not the same length in bytes then you have the other problem, of a long overwriting adjacent short variables.

Grand. While there are 4 hardware timers , how many of them are already in use by the os ? At least one for Wi-Fi and obedience the soft timer handler. While the Arduino manual is right you cannot declare an int and stuff it with an unsigned long. ,you d really like the compiler to pick that float + int error up.

Looking at the code I would note that constant int xxxx = 1234ul will have unintended outcomes. Also, dont sit and wait in the loop for things to fire. A loop happens every 5ms or so, so loop should look for a timer interrupt fired flag to indicate the desired event has happened rather than block. On do ding the flag you can then process the action. Otherwise, while interrupts will keep on firing, your Wi-Fi may crap out due to missing carrier detects. Don't write debug code in interrupts that write to serial.! You are using the hardware timer, there are only a few available . On the 8266 you can chain many more using the soft interrupt timer , I don't know if this is true for esp32. You can use c_str() to convert strings to char [] . I haven't run the code to work out where the issue is.

Can you stack trace ?

I too! Then I automated it using goto4all and sold it on. There's a variety of routes to goto for that mount if you want to. The eq5 is a bit more robust, if only in sheer capacity. I do miss mine, but I also have a gpdx with visac so not missing out too much.

Sorry, I was misleading you . I read that reconnect as a wifi reconnect while its not, its a mqtt reconnect. thats required for the client.loop calls as you mention. You only need to check for a connection when you have something to say and when you are expecting subscription callbacks . Are you using subscription callbacks ? The client.loop function is about checking for and servicing the subscription callbacks and activates the callback handler. If not using callbacks then You don;t really care if the MQTT connection times out since it will be remade every time you connect out to it.

Erm, good catch on the MQTT reconnect timeouts. Thats why I went to async reconnects handled through a separate timer handler. You dont want your device to be wrapped up and unresponsive to you becaase it can't see the MQTT server. Those periods will always be handled if you implement them using timer events. You can set the MQTT connection lifetime to be a longer value - the default is two minutes iirc. You should also watch out for the packets being within the MQTT header size - typically 120 bytes unless your redefine the limit in the library header. Also you need to go to the high capacity network model if your packets begin to get bigger than 350 bytes or so ( at least for the esp8266 version) you can also drop this line as no longer required if (!client.connected()) {reconnect();} since the Wifi object will auto reconnect if it detects a broken connection.

Can you get a ring buffer dump every time you have gone round the ring index. Is your buffer being written from somewhere else too ? If you are happy that the individual values are in range, does the sum overflow ? Are you getting a rash of spurious edges that cause it to occasionally overflow ? a la button damping ?