Hello Ulrik,

Welcome on board !

"Normally" the protocol used by the Celestron CPC 1100 is (strictly) similar to the protocol used by the Merlin head. (same company = Synta)
Maybe that the Merlin head use only a simplified set of those commands ...
Could-you tell us what are the different commands that you have discoverered ?

Anyway, Fréderic, the father of Papywizard, is able to whrite a "plug-in" for Papywizard adapted to the Celestron ... so you will be able to use Papywizard directly without problems !

The fact that the communication is RS232 and not TTL make no differences, Papywizard is able to handle different Com's just by setting up the configurations paramaters.

Fréderic will certainly try to help you but is very busy at this moment !

In a first step, could-you tell us the difference in the commands that you have discover ?

Fréderic will be able to help you, I am confident !

Some small remark's :

The CPC 1100 has a Focal Lenght of 2800 mm with a aperture F = 10 ...
This telescope is oriented to astronomy not to photogarphy so the resolution is probably lower and 0,6 ° angle of view ...
I believe also that you will come out of precision of the CPC for terrestrial pictures ... + the fact that the material is very heavy and will be submitted to all vidrations ....

With the Canon EOS 5D Mark 2 (21.1 MP) and a Canon 800 mm F2.8 USM lens you will cover an angle of 2.1 ° angle

If you use a Canon 7D (18.0 MP) with the same objective you will get a coverage of 1.3 ° angle

In both cases, with the wide aperture of the Canon lens, you will be able to shoot at a much higher speed then with the CPC !!!

Just things that you must take into considerations before the final choice !

Hello Frédric,
thanks for your help and your fast response regarding the protocol!!! I understand that you are busy. I am happy to try writing the needed code.
I will try to setup a development environment tomorrow. I usually use Mac 10.6 for development. Are there any pros or cons with that? Should I use Linux or Windows 7 instead?
I'll keep you informed about my progress. And don't hesitate to tell me if you find a workaround for how to handle the differences regarding the GOTO command.

Claude - thanks for your remark regarding using a 7D. We might try that. We have also done some testing with 2x extenders to gain more detail.

I just realized I wrote a wrong lens information. It's 800 mm f 5.6 - which is still quite decent for an 800 mm lens. http://www.the-digital-picture.com/revi … eview.aspx . F2.8 would have been nice though

We are not planning to use the telescope. Just the mount and this lens. Our tests show that we need the image stabilization in the lens even with a robust mount. We need really sharp images for this project.

I bought a Merlin mount as well, to use as a reference platform. But I haven't had time to test it yet. It's a nice peace of hardware.

/Ulrik

Hello mediavets and thanks for you hints about alternative gear. I am a newbie when it comes to panoramic photography. There is a lot to learn.

We have looked at the Rodeon VR robotic, that is an alternative and I have been in contact with Dr Clauss. I looked at some different heads at Photokina (except that the large Roedon was not there). We also looked at the Gitzo Athena head which is interesting, but not so well adapted for long lenses. The CPC 1100 just seamed more mature and more robust, that why we decided to try that one first. If that fails I might get back to Dr Clauss.

Yes, a good tripod makes big difference. During our test I have been using a geared Manfrotto 400 head http://www.manfrotto.com/product/8374.3 … eared_Head It's an odd solution for panoramas, but we have fairly flat subjects so parallax error is less of a problem here.
We use tripods for video cameras and stabilize them with weights to keep them tight. And we still sometimes have problems keeping the camera steady. Most of the movement is in the tripod head.

10 m/s wind is regarded as decent weather we are really happy when we have less then 5 m/s. We often have wind peaks at 15 m/s. The front lens and long lens barrel catches the wind. You also get quite nasty turbulence around bridges. We are trying to capture tine cracks in concrete at 150 m distance. This is best done when we have humid nights and the concrete the dries, this makes our choice of photo days correlate with cloudy and windy day.

So this is not as beautiful as the panoramas you other guys are shooting. But this is an interesting photographic challenge.

/Ulrik

Ulrik, to develop under MacOS, you will need to compile PyQt, which is not really simple. If you don't want to bother with this, just switch to linux, where anything is included. Or Windows, but you will have to download and install stuff yourself.

Frédric,
I have a questing regarding the simulator. How do I use it?

I have installed Ubuntu on an old laptop. The source has been downloaded and I can start Papaywizard via papywizard.sh.
I have started to copy and edit files. I call the new driver NexStar since that is the protocol name. I used gigaPanBot as template for all files. I am slowly starting to understand the code. The code seams clean and easy to understand - even for a first time Python user.

I have added the following files and edit class names
papywizard/hardware/nexStarHardware.py
papywizard/plugins/nexStarPlugins.py
papywizard/hardware/nexStarHardware.py
papywizard/simulator/nexStarSimulator.py
papywizard/simulator/nexStarCommandDispatcher.py

I have edited he following to add/register my new files/classes
papywizard/scripts/main.py
papywizard/scripts/simulator.py

Papywizards starts ok and I am able to select my new plugin. I haven't tested with real hardware yet. I though testing with a simulator first might be a good start.

I found your simulator and have added files for NexStar there as well. Before I start to edit the simulator files to create a NexStar-simulator I would like to test the simulator with one of the existing plugins. I have done some tests starting the simulator with
./simulator -g merlin -c serial - /dev/ttyS0
But I am confused on how to get the simulator to listen to a port and work with Papaywizard. It starts but it doesn't respond to papywizard when I choose "Connect".

Please Frédric - Some hints on how to use the simulator would be great.

Thanks!
Ulrik

Hi Frederic,

does this mean we will have more choice in the hardware to use Papywizard ? cos, I can't locate a Merlin here in Australia, I have now tried east and west coast, with no supply

thanks

Henrik

You can try to sell the telescope alone on ebay...

Frédric,
thanks for your hints regarding the simulator. I have got it to simulate the Merlin head ok via Ethernet to local host. I will now continue to write the NexStar (CPC1100) simulator.

I have successfully connected with real hardware. NexStarHardware.init successfully executed stop motor and get firmware version. So I am making some kind of progress...

Hi Klaus,
Thanks for your advice. Using a gyro seams interesting.I know about their existence but hadn't thought about trying them for this purpose.

Have you any experience of using a gyro together with a motorised pano head? Does it work well?

I know that they have one of those gyros at our local camera rental, it could be interesting to rent one and try.

/Ulrik

Hi everybody
I am making progress with the driver. I can now control the head via the jog buttons i Papywizard and I get correct angle readouts.

I now have two problems to solve:
1) Papywizard is designed to control each axis independently. The Goto-command for this head is designed to operate both axis separatly. It's a bit tricky to find a solution without using global variables and to avoid race conditions.
2) I can't get the head to accept Goto-command. I have tried both "b" and "B" with different parameters, which is the commands for AZM-ALT Goto. The manual tells that the RA/DEC Goto (R & r) commands are only accepted after alignment. I suspect this is also valid for the AZM-ALT Goto. I haven't fully verified this yet, but I have done some tests by sending this as a hardcoded command in the init method of axis 1, and I the head didn't move.

I will now try a workaround. My plan is to implement my own single axis Goto in the driver using the same commands as for Jog and Read. This would solve both problems. I can operate both axis in parallel, and readout of encoder is mainly limited by the serial port speed of 9600 bit/s.
It will probably not be as accurate and fast as the heads Goto, and it will raise the load on Papywizard.  It actually means writing a servo controller algorithm. A bottle neck is the readout speed which will cause some delay.

I will continue work for a few hours today, then I will have a few days break to work on other projects. But thanks for all comments, questions and suggestions on this thread.

P.S. I am am slowly starting to adapt to the programming language that Papywizard is written in. Python stills sounds like Norwegian to me. I am Swedish, I can communicate with my Norwegian neighbours, but often with great confusion. You know, In Swedish the word "rolig" is "funny", a joke is "roligt". In Norwegian "rolig" is translated to "calm an quiet". Swedes would use the word "rolig" at the bar, Norwegians use it on the graveyard. But ones you know the false friends of a language it get less confusing. (This is just to be seen as a metaphor, not a way to have "roligt" on the behalf our our nice neighbour country. D.S.

Yep - and Python was named after the film "Monty Python Flying Circus"...