EQMOD issue?

[NickH]

Wondering if anyone else had seen similar.

Been running this over two RDP protocols. Tight VNC and Windows Remote Desktop (laptop indoors running XP Pro, imaging laptop outside on windows 7)

All been working fine for months with no RDP, perfect guide via PHD etc, then on two occasions, when running Windows remote desktop, I get periodic drop outs with the tracking in EQ Mod (it literally turns off tracking). Never ever seen this when not on RDP, and only when using the MS one, have I seen it at all?

Probably something in the RDP/Hub config I am using, but odd that VNC doesn't throw it.. been remoting from my iphone fine..

Just curious

[SteveL]

EQMOD will send multiple STOP commands if it is unable to communicate with the mount for a certain amount of time (not sure how long or how many times it tries). Its usually down to the serial driver not getting enough processor time. Someone on the EQMOD list had the same issue not so long ago. Had to run EQMOD at a higher priority so the serial driver inhereited a higher task priority too, and it all started working again fine. I wonder if MS RDP is creating too much CPU load compared to VNC. Have you tried telling MS RDP to use lower bandwidth and less colours?

[NickH]

I could try that. SImple solution is to stick with VNC, albeit that is very slow in comparison, it's mainly to monitor the subs and PHD graph from indoors, as I usually set up the laptop in the obs and then walk away

Thanks Steve, that's really helpful

[Psychobilly]

Have you tried teamviewer..? thats free for non commercial use...

[NickH]

I have used Mesh, not tried teamviewer...I like RD for many reasons, but VNC on the iphone is just cooler than cool!

[Psychobilly]

It might be a bit processor hungry again though... I love it...

Peter...

[steppenwolf]

I use RD all the time with this set-up XP to XP and not had a glitch so I suspect that there isn't a compatibility issue as such, more likely a resource issue.

[NickH]

It's a very very high spec laptop in the obsy...so if it is (with a 7 port hub on it mind you) then I will be amazed. but I will try

my suspicions lie at the mo with the hub and EQDIR unit, may be trying the HBX pass through for a fe wdays to compare...if it is the EQDIR... stand back and watch the fireworks!

:-)

[the rev]

Is the hub powered? I had to power mine to get constant strength of signal.

[blinky]

Wouldn't it be great if EQMod and PHD has remote capability - you could go to a webpage or similer and view the status rather than having to remote into the pc?

[NickH]

Is the hub powered? I had to power mine to get constant strength of signal.

yup...my second one, as the first one, whilst working with every other bit of hardware I had refused to work with the EQDIR module

[NickH]

Wouldn't it be great if EQMod and PHD has remote capability - you could go to a webpage or similer and view the status rather than having to remote into the pc?

https://www.mesh.com/welcome/default.aspx

:-)

Enjoy!

Been using this for a long time (formerly Mesh), it can punch through any firewalls, and I had it in the office monitoring the observatory (webcam for security) for ages

[chrisshillito]

EQMOD will send multiple STOP commands if it is unable to communicate with the mount for a certain amount of time (not sure how long or how many times it tries). Its usually down to the serial driver not getting enough processor time. Someone on the EQMOD list had the same issue not so long ago. Had to run EQMOD at a higher priority so the serial driver inhereited a higher task priority too, and it all started working again fine. I wonder if MS RDP is creating too much CPU load compared to VNC. Have you tried telling MS RDP to use lower bandwidth and less colours?

EQASCOM will attempt to stop the mount if 5 consecutive position polls fail (each poll is subject to the number of retries and timeout that you specifiy in the EQASCOM setup screen). Once this failed condition has been triggered EQASCOM will keep sending out STOP messages until such time as the mount responds (on the basis that the mount might at least be able to receive even if responses don't get back to EQASCOM).

Bumping up EQASCOM's thread priority is a good suggestion if you have any doubts over COMs - there is a configuration option on the setup EQASCOM screen to do this automatically on start up. I've been running mine at "realtime" priority since I added this function - no problems yet (mind you never had any before!).

Chris

[NickH]

Chris

Thanks again. Last night it did the same without the RDP connection, and I lost a lot of sub frames

Will do the thread priority update next session.

To everyone, thank you, invaluable info!

[chrisshillito]

Nick,

Next time it happens take a look at the EQASCOM message centre (or have it log to file) if comms errors are the root cause to this tracking loss then there should be some diagnostic messages in there somewhere.

Chris.