freiform

Hi,

I have a Lacerta 72/432 ED-APO (w/ flattener) and am (barely) using it with a Canon 1000Da, but I must say that the camera irritates me more than it probably should. Sensitivity in live view makes me dread focusing, and imaging in moderate temperatures is just too noisy.

I am considering getting a fast and sensitive mono camera. I would be satisfied w/o colour for a time and could gradually add filters and a wheel. Bug given my mediocre small town skies, and relatively small Vixen GP mount, I guess this could be a reasonable approach. I have been looking into the 1600 Pro, 183 Pro, or 174, but I really am not sure which way to go.

Considering pixel size, all should be a match for my scope, more or less. 

* The 1600 seems the to be go-to camera, tried and tested. I read about issues with micro lensing, altough I do not know if it would be an issue for me personally. And of the three mentioned, it has the largest FOV. Also, with ~1500 € more on the expensive side, relatively speaking.

* The 183 Pro has a bit smaller FOV, which might be ok, but those small pixels will be a difficult to handle. If I can actually utilize them at all given my small mount and small town skies. The price is nice. But will I be able to handle it? I also read that is has slighly more noise than the 1600, but again, will it practically matter?

* The 174 seems to be discontinued, and given the small sensor and FOV, more aimed at planetary? Although I suppose it would be nice going after smaller objects with it.

What about the other brands? Atik has its Horizon, but it doesn't seem priced well compared to the 1600. Then there is the QHY163, but I don't see any reason to prefer it to the 1600?

For the 183, there is the Altair Hypercam with the same chip, any reason to prefer that to the ASI 183, besides the sturdy case?

Are there other alternatives I am missing? It is important that the camera is fully suported by Linux / INDI. If I could use the cam to do some EAA/live stacking, that would be a nice addition, but I suppose all of the above are capable of that.

Regarding additional equipment, I would be perfectly fine in doing some broadband mono in the beginning, but I suppose I need an L-filter to cut UV and IR anyway? I probably could justify getting a motorized wheel and a set of decent LRGB filters I suppse. Any recommendations for that? Again, the wheel should be fully supported by Linux/INDI. Expensive NB filters can wait, there's enough to learn and do without anywhere near enough time to do it .

Regarding filters, would I get away with 1,25" filters for the 1600? How about distance from filter to sensor? With the 183's smaller sensor, I suppose this is less on an issue?

In the end, if I pay a bit less without loosing too much performance, that would be fine with me.

Any ideas, recommendations or comments?

Thank you

Sven

Ah, I suppose I will open a seperate thread. Hiding here, the question probably will not get a lot attention

2 hours ago, choochoo_baloo said:

*only* hardware control. I plan to subsequent processing on another beefy desktop.

As I've put above, I think it has to be ASCOM for foreseeable future and therefore by extension Win 10.

Can you therefore make any recommendations?

 

Hello Matthew,

I only have experience with an older NUC model which I used for a media center a couple of years back. They have a quite a range and there should be one that fits a certain requirement. I also read good things about Zotcac's zboxes which are in the same ballpark as the NUCs.

Anyway, general recommendations are difficult. In your shoes, I would make sure that I have all the ports I need, and solid connectivity, be it gigabit ethernet or WiFi. Especially look at the USB-Ports. If you use a big sensor or a high framerate (or both!), make sure you have dedicated USB-controllers so you don't run into any bandwidth issues. If you have legacy hardware using RS232 @DaveS recommendations is worth checking, and I am sure that there are other makes and models.

I would go about it using a service such as geizhals (skinflint in the UK?), browse to the mini-pc category and then play with the filters. They are quite extensive and you will likely get a list of candidates that fit exactly you requirements. At worst this will give you an overview what is available! Maybe then the forum can give you more solid advice? Sorry I cannot be of more help.

Sven

It is for controlling the hardware only, not processing or other CPU-heavy tasks? Also, are you set on a framework (ASCOM or INDI) and with it on a operating system?

Sven

Hi,

I have a Lacerta 72/432 and am using it with a canon 1000Da, but I must say that the camera irritates me more than it probably should. Sensitivity in live view makes me dread focusing, and imaging in moderate temperatures is just too noisy.

I don't want to capture the thread, so just ignore this if it's not appropriate, and I can open another thread. If it's ok, what would be a fitting cooled camera to go with such a scope?

I am considering a fast and sensitive mono cam. I would be satisfied w/o colour for a time and could gradually add filters and a wheel. Bug given my mediocre small town skies, and relatively small Vixen GP mount, I guess this could be a reasonable approach.i have been looking into the 1600, 183 Pro, or 174, but I really don't see the forrest because of the trees. Considering pixel size, all should be a match for my scope, for the 1600's sensors, I read about issues with micro lensing, altough I do not know if it would be an issue. So between the three above, it's about FOV, with the 183 more difficult to handle due to the small pixels?

In the end, if I pay a bit less without loosing too much performance, that would be fine with me.

Any ideas? I do not prefer ZWO, so other brands are also welcome. Given that they all share the same handful of sensors, I wonder what the differences are?

I am happy to start a new thread if this is not fitting here, but thought I might just as well try with the right people already here

Thank you

Sven

Hi,

I just built plugged together an allsky-cam using an ASI120mm controlled by an old RPi. It works, but I find the image rather noisy with longer exposures. Dark-subtraction is needed, otherwise there's white pixels dominating the image.

Also, I seem to miss meteors. On Tuesday I saw two between Swan and Lyra, but they are not on my images. One image shows small artifakt that might be one of them, but it's guesswork and only visible if you actually know where (and when!) to look.

Iwols, what parameters did you use to create the image posted above? And what lens do you use? 1.5 mm?

Sven   

The note on allsky's page is indeed strange. Or at least that here it has the opposite effect.

On the other hand, the manual for the ASI120 states that 

Quote

Our USB2.0 camera is not compatible very well with OSX & Linux.

So there are some problems and they are aware of it. If it could be resolved completely by using the compatible FW, then they would just point to that instead of spelling it out like that, wouldn't they?

Maybe I'll try building oacapture, should I run into problems I'd be glad to ask you for some hints, thank you!

Anyway, I just put the camera outside to do its thing with the allsky setup. I guess I just repurpose it for that and go for a new cam for guiding and planetary. Maybe even something that is capable of light EEA..  I am open for suggestions 😁

I just tried the 120MM with FireCapture on Manjaro. With standard FW, Firecapture says 'Capture failed' and that's that. After flashing the compatible FW, disabling all auto-settings, setting exposure to 10 ms, I can get the camera to capture at nearly 18 frames/second for a couple of seconds. Then the rate drops below 1 fps, I get a 'stiched up' image. Sometimes it catches itself, sometimes not, it is just not reliable.

Doing the same with Windows works without issues.

Also, for using the ASI120MM for Thomas Jacquin's allsky cam [1], I have to use the standard firmware, the compatible variant introduces errors.

[1] https://github.com/thomasjacquin/allsky

Ok, so it is working for at least one person. Strange. I tried different machines, Linux distributions, cables, hubs, and never came close to 17 frames per second.  You are using the old USB 2.0 only version of the 120mc? Which distro and kernel version are you running?

I set it to 40, which is the general recommendation for this device under Linux. That is actually the only way to get the 7 fps mentioned above at all. 

Hi James,

the maximum I can get out of the 120MM is around 7 fps. But even that is not stable. It often dips below 1 fps. Not really ideal for planetary. It probably would work for guiding, though.

Yesterday I noticed something strange when setting up an allsky cam; when using the compatible firmware, I get fragmented images, indicating speed and/or transfer problems. After flashing the regular FW, the problem is gone and I can capture using my old RPi 1. But with the regular FW the camera won't run at all with FireCapture under Linux.

It seems I can re-purpose the ASI120MM as an allsky-cam. Are there any alternatives to the -S or mini? Maybe an upgrade for planetary. Doesn't have to be ASI...

Hi,

is anyone using the ASI120MM (USB2.0, not 3.0, no -S) successfully  with Linux? I cannot get proper framerates at all (erratically jumping around <1 to 7fps). Guiding at longer exposure times might work, but lucky imaging seems not feasible. ZWO themselves are aware of problems and recommend other cameras for use with MAC/Linux. There are some reports of people making the switch to other cameras, some report it is working for them, but they never mention what they are actually using the camera for.

Before I start fiddling, replacing SDKs or recompiling kernels, does anyone have had success with planetary lucky imaging with this cam under Linux?

I am not really keen on selling an otherwise perfectly good camera. If I would go down that route, what would be a good (and not too pricey) alternative for guiding / planetary up to 1.5m (w/o Barlow) than works properly and without issues under Linux?

Thanks

Sven

18 hours ago, Gina said:

I looked into this a few years ago using vintage SLR camera lenses for a widefield rig with ASI1600MM-Cool camera.  Because of the extreme accuracy required in the optical path, the camera, EFW and lens must be rotated as one unit including the remote focus system for the lens.  This turned out to be a large turret assembly.  I decided in the end to abandon remote rotation and just set up framing manually.  This is the thread.

My refractor has one screw that fixes the focuser.  If I loosen this, I can rotate the focuser and everything attached to it. My point being, I never had to readjust besides maybe refocusing, so I don't see issues with the optical path. Am I missing something?  

18 hours ago, Tomatobro said:

Have you considered a RC Servo? They are very easy (if you know how..) to control with a processor and are quire powerful in the larger sizes.

Sometime ago I made a rotator using just such a device. Pics attached

Mhh, what are you rotating? I guess the motor itself is not the issue at this point 😁

4 hours ago, rpineau said:

You might want to take a look at this : https://github.com/cytan299/field_derotator

 

2 hours ago, redtail said:

http://www.scopefocus.info/home/rotator

 

Those look interesting, especially the one on scopefocus. I am not quite sure on what it is actually rotating on, though. Do they already have a manual rotator in place, like [1]?

[1] https://teleskop-austria.at/CAA-1_Takahashi-TKA21200-Kamerarotator-fur-FS-60C-FC-76-Sky

/edit

For reference, it seems the actual term is AAC (Camera Angle Adjuster) rather than rotator.

That is a nice design, but unfortunately beyond both, my tools and capabilities.

On the other hand, I would have to find two tubes with fitting threads, or maybe print tubes an adapt them some other way. I guess that the worm and gear can also be printed, with precision in rotation not being as important as with mount control. The bearings I found with a quick search seem too thick (outer - inner diameter), but I suppose there is something available somewhere, I just don't know the proper terminology. Maybe a slide bearing might also be feasible? 

/edit

found thin-section bearings that might do the job..

Hi,

while having enough projects as it is, I thought about a computer controlled rotator for proper object framing. The electronics and software side should be relatively easy, using a small microcontroller, stepper driver and motor,  and a few odds and ends.

But how about the mechanics? Let's say I want to fit something between my small refractor (Lacerta 72/432) and a DSLR, I have M54 inside thread on the focuser and a standard T-2 (inside) or canon bayonet on the Camera. How would I go about that? Would it feasible to get a cheap manual rotator (i.e. [1])? It's relatively narrow, but maybe sufficient to fit a belt?  How about 3D printed parts? But I suppose the threads will be problematic and I do not know if PLA is the right material for the job.

There seem top be DIY focusers and mount controls in abundance, but rotators apparently are a relatively scarce species? 😁

Ideas and opinions are appreciated!

Sven

https://www.firstlightoptics.com/adapters/sky-watcher-camera-rotator-for-evostar-72ed-ds-pro.html

Dave, how heavy is the tele-lens (Canon 300 mm?)  in your first photo? I have a small refractor here (432/72) that results in a relatively rickety setup.

Sven

Hi all,

interesting thread. I played around with INDI on a RPi and connecting to it from my laptop. While everything was fine control-wise, I had Issues displaying images, i.e. to judge focus, field or whatnot. The (raw-) images loaded very slowly which I found rather annoying. I read on the INID-Forums  [1] that a good alternative might be using USB/IP [2], but I did not come around to test it. How do you handle this with remote setups? Or isn't this an issue for you?

Sven

[1] http://www.indilib.org/forum/general/800-raspberry-image-download-duration.html

[2] http://usbip.sourceforge.net/

This is working nicely, thanks for your input.

Hi Per, 

basically a client implementation to talk to the appropriate hardware. Could have made that clearer. I considered INDI, but refrained form digging through the code so far

Sven

Hi, 

is anyone aware of a preferably Python implementation of the LX200 protocol for mount control? I'm planning to communicate with EQmac, which supposedly "provides an LX200 emulation mode via TCP/IP" [1].  Before I start implementing myself I wanted to ask if there already is a solution that I am unable to turn up..

Thanks

Sven

[1] http://eqmac.hulse.id.au/content/interfacing-other-software