chrisshillito

Pecprep has two purposes. It provides a periodic error analysis tool and also a PEC curve generation tool for mount types supported by the EQMOD ascom driver (essentially just skywatcher mounts).  So if your mount is not EQMOD compatible you will only be able to use the analysis side of things to diagnose the main sources of error on your mount.

Chris.

It could be that your ASCOM Park position is not the same as your chosen EQMOD Park position. Whilst form its own interface EQMOD provides multiple park positions - ASCOM only has the one PARK method and that simply says "park" it doesn't set the position to park to - this has to be done using an ASCOM "SetPark" command. So to set the position the mount will move to when an ASCOM Park is issued you must first move the mount to that position and issue an ASCOM "SetPark" command - the current position is then stored by the driver (EQMOD) and the mount will return to that position on all subsequent ASCOM initiated parks.

Try this:

• Use EQMOD to Park the mount
• Unpark
• Look on the windows start menu, in the EQMOD group, for the  "Set ASCOM Park Position" script
• Run the Script

Chris.

On 14/10/2020 at 14:18, Stepe said:

What I understand however is that the hour displayed in the EQMOD panel is ...just a display that won't affect how EQMOD itself works with the mount (alignment, limits, park positions, planetarium interaction, game controller, etc)

The "time" EQMOD displays is the the Local Sidereal Time. This is effectively the instantaneous Right Ascension value associated with the meridian line. LST is an essential parameter that EQMOD uses when calculating how to move the mount in order to bring it onto any celestial target. You are correct that LST doesn't have any bearing on park positions. Your planetarium will probably display its own LST calculation somewhere and this should be the same as EQMOD - if it isn't then there maybe some difference in observing site data between the planetarium and EQMOD which should be "fixed".

Chris.

My guess would be that some, but not all, of these software apps are being run with admin rights.  The problem is that for each "run level" a separate instance of EQMOD will get launched by windows/ASCOM when the associated application "connects". The first instance will open the desired COM port but the second will not be able to as it is already open.  The solution, if this is the problem, is to ensure that all applications are installed/run with the same rights.

Chris.

6 hours ago, Marcel said:

Hi Helen,

Thankxxx. In my opion EQMOD recognize only one COMport in staed of 2. I already use one COMport for the mount (skywatcher EQ6 R pro) If it is possible to use 2 COMports let me know.

It is only for alighment and in near future, in the field. That will be in Flushing, Netherlands.

Kind regards

The only restriction in EQMOD is that you COM port number just be less than 16.  Other than that, there is no problem at all in setting eqmod to use a one dedicated com port for the GPS and another for the mount.

Chris.

When EQMOD first connects to the mount it reads Al the mount specific parameters from the motor controller board and that it how it can work with all the different skywatcher EQ mount types.

EQMOD was developed to support the serial protocolskywatcher first introduced with EQ6/HeQ5 mounts  - at the time we couldn't have known that the range of mounts running this protocol would be expanded - so that's why you see reference to EQ6/HEQ5.

Chris.

On 02/03/2020 at 08:38, michael8554 said:

Re the EQMOD PEC, a nice curve generated, but it would have been nice to see the actual value of the PE. 

For PE analysis (PE is much more than just a "value") then you would pull the PE capture file that EQMOD produces as part of its autopec into PECPREP. This will give you full analysis or the error signals contributing to the overall PE.

On 17/10/2019 at 00:38, JamesF said:

The EQMOD group is also on Yahoo, isn't it?

It was - we've now moved over to https://groups.io/g/EQMOD

New posts and memberships will no longer be accepted on the Yahoo Group.

We chose not to automatically transfer our member base as we did not think it appropriate to transfer personal details to a third party but folks are free to join the new group. In due course we plan to transfer over the yahoo messages archive and maybe files and photos. Whilst we want to preserve as much has possible but we believe it is important to first seek the consent (or at least implied consent) from the content owners  - to that end we are giving yahoo members the opportunity (until Nov 22) to delete any content that they do not wish to transferred (Mods will help with this if asked).

Chris.

Ady is correct. All those folks who platesolve and say they don't align are only half right. Plate solving itself doesn't cange anything, but the act of synching, which is usually an integral part of the plate solve goto sequence, is what performs the alignment and is what allows the mount/driver to provide position correction. This is exactly the same as one star alignment except you can align closer to target and without being centred on a star. I guess the ease and convenience of the plate solve / goto process means many folks don't have to consider exactly what is happening behind the scenes, but if you platesolve and sync you are performing alignment.

Chris

The autopec feature in eqmod will store the raw pe data captured to file (it can do this even if you don't want to create/apply a correction curve). This can then be loaded into pecprep for analysis. 

Chris

16 hours ago, Stub Mandrel said:

Except for those of us who find it a major effort of will to remember to park the mount before switching it off...

If you can't remeber to park then put some thought into how to setup a resynch encoders position (maybe some distant terrestrial object you can see with a reticule eyepeice or a physical indicator on the worm shaft (EQ6Pro have a flat on the end). All you then have to do do is create a custom park with the mount at the position and whenever you want to reysnc just move the mount there (manually or under EQMOD control), select the resync as you current park option and hit the resynch encoders button.

3 hours ago, malc-c said:

The thing is I'm not sure if the communications come from the main board which would suggest the PIC micro is running, or if it comes from the power board where the handset and power connectors are.

Any suggestions ?

 

Malcolm

Comms come direct for the PIC's uart. If you are getting position display on EQMOD then it is communicating and the PIC is running fine.

On 28/02/2017 at 22:17, Geoff_L said:

 I was drifting off to sleep watching some YouTube videos from Chris

Yes, I can have that effect!

If you haven't already faked them you might want to consider bluring out your site locaton from those pictures.

Chris.

PEC.TXT is your Periodic Error Correction curve - this is what you would load into EQMOD (if its not doing it automatically).

peccapture_EQMOD.txt  is the raw PE data that was captured and during AutoPEC and from which the PEC.TXt file was generated. If you were interested in analysing your mounts PE, perhaps to determine which mechanical components were causing the periodic error,  then this is the file you would load into PECPrep.

Don't know why they aren't visible to you - some windows thing I guess. There are just normal .txt files.

Chris.

Yes, well that's definately a miss read of the RA axis encoder (ER)- the absolute absolute maximum value this can reach is 16777215.  DEC (ED) looks ok as do the RA and DEC motor status MSR and MSD. If EQMOD recieves bad data then it will use a simulated value instead until the next read - if it does this 5 times sucessively then it will stop the mount as it hasn't got what it deems to be full control. The fact your mount continues to run implies this is just an occasional, and short lived glitch.

If you had an EQDirect adpater to hand I would advise you to try that and compare - A direct connecton using an EQDirect is the most robust method of connecting EQMOD to the mount and while ever the sysncan is in the mix there is always some doubt over its own internal buffering and routing of the comms. Not sayig the synscan is a fault but it is at least one variable that can be removed.

Chris.

Lets be a little careful here! - only a correctly wired up FTDI aapter can be plugged straight into the mount. As a synscan in PC-Direct mode is bein gused this implies the ftdi adapter in question is a usb-RS232 type and not an EQDirect.

You shouldn't really be getting communicatons errors - that does indicate that something isn't working as welll as it should be -it may be the occasional timeout , which EQMOD can tollerate - but if EQMOD experiences a number of consecutive failures it will play safe and try to stop the mount from moving.

Chriis.

Power up the mount in the home position. i.e. Scope pointing at th pole, counterweights straight down. Or use the hanset to do a auto home.

When EQMOD connects to an unparked mount it expects it to be in the home position. Some small error from home is tollerated (and is usual) and can be corrected for by the alignment process - but if the error is large eqmod will assume user error (i.e. Synching on the wrong object) and deliberately ignores the synch request.

Chris.

Why move the RA for alignment if its going to be moved once slewing to an object?

The RA axis is moved during polar alignment only to put the polar scope reticule in the correct position for you to use the alt/az bolts to align the mount itself.

You don't have to move the ra axis, you could just adjust the az/alt bolts until polaris lies in what looks like the correct position on the reticule circle - however doing that requires a certain amount of guestimation which can be reduced significantly by letting eqmod position the reticle bubble in just the right place by rotating the ra axis.

Once you have the mount polar aligned just move it back to your normal starting (home) position and initiate gotos (and goto alignment) from there.

Chris.

You shouldn't have to do anything special for EQMOD to work with an EQ8. EQMOD reads all the mount specific parameters from the mount controller and handles them internally. EQMOD does contain some advanced parameters for those using non-standard mounts or mount with modified gearing ratios, but you don't need these.  You can force EQMOD to its default state by  deleting the ini file (which forces a new one to be created with defaults assigned).

Chris

Yes, it does seem that a lot of astro software development has its roots firmly back in "old" days of the 90's. I don't expect there is a massive demand that would cover the cost of redevelopment I agree, but with something like an additional module that already exists.. I wonder just how much more effort that really is?

Changing code that is structured to support a single instance to support multiple instances is a pretty fundamental change that would affect every part of the code. when it comes to software folks seem to forget that even a seemingly minor code change (which this isn't) can require significant effort in testing, and documentation changes (manuals, wiki, websites, video tutorial etc.) before it is suitable for public release. Clearly for a commercial product that effort has to justified against potential sales lost or gained.

I don't have a problem paying for additional bolt-ons. I do find it hard to swallow having to pay full wack for the use of one module though.

Perhaps you can negotiate a multi license discount if you contact the developer and explain what you're up to and why the existing licensing model doesn't work.

Alternatively, if you go the ASCOM route all the camera, focuser, mont functions are scriptable - you can always write your own automation software to glue it together and that meets your specific purpose. Being able to write your own software may require a significant learning curve but it is very empowering and cost effective in the long run

Chris

Hi Chris. I had the same flashing when opening up EQAscom_run independent of CDC. It was however the same issue re the COM port which is solved as you say by setting it in the toolbox.

Yes, that is correct. EQASCOM_run, like CDC, will doggedly keep closing and reopening EQASCOM in the hope that whatever is preventing the undelying comms issue resolves itself. It is a valid way of operating and if things do resolve themselves it works out quite nicely - but if there is a permanent fault using the toolbox is the way to go to diagnose it.

Chris.

The flashing I think is because it's hunting for the correct COM port

The flashing occurs because CDC opens up EQASCOM and instructs it connect to the mount, when this fails EQASCOM tells CDC which then decides to shut down EQASCOM and try all over again. If only CDC would just leave EQASCOM open rather then closing it you'd be able to read the error message that EQASCOM puts out on its main display. For anyone attempting a first time use of EQASCOM I would recommend using the toolbox app that installs with EQASCOM to validate comms as this won't close EQASCOM and lets you read the error message (there are essentially three, Port not found, port open or timeout).

Chris

Your best bet is to make contact with the guys contributing to that EQMOD group thread I linked to above. I've not flashed a synscan myself but they clearly have.

Chris.

There is a thread on the EQMOD yahoo group (probably need to be a member to see it) where one user has replaced both of his blown 16F73 PICs with 16F866 flashed with the latest firmware (an now capable of upgrade via the serial link).

http://tech.groups.yahoo.com/group/EQMOD/message/35581

Chris.