LittleFoot Elegance Photo Community Forum
LittleFoot Elegance Photo => LFEP ASCOM => Topic started by: Armando on Wednesday, 24.04.13 - 19:40:27 - CEST
-
Hi @all,
please use this topic to report LFEP ASCOM driver bugs. Providing detailed reports will speed up bugs fixing. ;)
Because of the low LAN speed, I think great part of the users will prefer COM connection: maybe it's a good idea ignoring, for now, bugs that occur exclusively by LAN connection.
CS
Armando Beneduce
-
Hello Armando, i think you are right :)
The WLAN or LAN connection is Not so stable
As the usb-serial connection i have tried both options .
Best regards
Rainer
-
Hi Armando,
I will integrate the bugs open from the bugreport (which is also buggy :-)):
When scope is unparked and switch tracking on after unpark is checked the siderial is shown in the gray field but not operating on HBX. The other way round when HBX is operationg in XXX speed, the ASCOM driver shows that the scope is in parking position.
Parking has to be overworked comletely, also a bug on the HBX 6.20 by the way. Parking over ASCOM does not work stable and correct.
Last but not least, ASCOM LFEP Server process stays in Memory when driver is closed. Its for sure when Auto park is activated as parking cannot be acomblished (see bug above) however it occures also in other situations from time to time. I could not find a recurring situation that pops up this issue until now.
Regarding installation problems under Win7 I try to find out where we need to register for the driver to be un-danger.
CS
-
Hi the_lizardking,
When scope is unparked and switch tracking on after unpark is checked the siderial is shown in the gray field but not operating on HBX. The other way round when HBX is operationg in XXX speed, the ASCOM driver shows that the scope is in parking position.
LFEP parking is affected by a firmware bug. So "Controller parking" won't work.
We need to enable PC parking. It also was affected by a bug (I think a simple sleep call fixed it). So I sent you an updated driver: it should work.
Parking has to be overworked comletely, also a bug on the HBX 6.20 by the way. Parking over ASCOM does not work stable and correct.
I think/hope no more ;)
Last but not least, ASCOM LFEP Server process stays in Memory when driver is closed. Its for sure when Auto park is activated as parking cannot be acomblished (see bug above) however it occures also in other situations from time to time. I could not find a recurring situation that pops up this issue until now.
It simply occurs if you don't click on disconnect. It's a feature, not a bug ;D
Regarding installation problems under Win7 I try to find out where we need to register for the driver to be un-danger.
The main issue/mistake is the use of Windows! :)
CS
Armando
-
I will test the parking,...
Regarding the ASCOM Server process, it is not always only when not clicking disconnect,... I did not find out why and in which situations but from time to time the prcess stays resisdent.
Let you you know regarding parking then.
I also found antoher strange thing today and yesterday,... the King Rate as well as Intelly Track is switched on after a GoTo with CDC and it cannot be switched off via ASCOM. When I go to HBX and trying to switch off the King Rate I get failed with the first try, a second try brings the success then. WE shoudl keep it in here, I will try to find out when it exactly happens and let you know if it still pops up.
-
Hi @all,
I'm trying to solve some parking issues reported by the_lizardking.
I hope to receive other reports by someone else just to know if the issues are related to the FW release in use (I'm using the latest 6.30 FW release, the_lizardking is using the previous 6.20 one).
I obviously need reports made by using the latest ASCOM driver.
Because of a LFEP firmware bug there is the need to use PC parking option. There is also the need to set (by handbox) tracking enabled at startup.
Another bug that still occurs at the_lizardking (after ASCOM connection) is related to Site longitude reading.
To manage it (as I'm not able to reproduce it) I need someone else that will confirm it occurs. I also need a log of the traffic on serial port. SerialMon is able to sniff the traffic so that we can see what happens when the error occurs.
If you need other details to contribute as beta tester please don't hesitate to tell me what details/instructions you need...
Thank you in advance and Clear Skies!
Armando
-
Hello armando if i can i would help you to test beta .
Please send me more information about the longitude problem under 6.30
you have found 😊Best regards Rainer .
-
You are right, the info is missing hehe
Long, Lat Problem:
So we have the following error during FIRST connection with LFEP from time to time:
(http://abload.de/img/ahdfifcazwuac.png)
I changed the COM2 connection setting and since that its better or gone - to:
(http://abload.de/img/hfeadcdhxpuqc.png)
When moving the scope I get teh following Warnings in ASCOM Log screen:
(http://abload.de/img/eagjgcfdm8b45.png)
Parking Problem:
When scope is parked with ASCOM and you power down and on the LFEP and connect with the driver ASCOM shows scope in parked mode but scope is moving and shows wrong coordinates 0:00 and 0:00.
Other open parking problems are fixed so far, but could be that there are also other bugs.
FtDI Driver used on my system is:
(http://abload.de/img/fbjjhbceucinn.png)
-
Hi @all,
I just uploaded a new driver. I see no critical issues on my LFEP now.
User tests are appreciated.
CS
Armando Beneduce
-
Hi @all,
I'm spending a lot of time to try to improve the driver.
Since I'm receiving bug reports only by the_lizardking and my LFEP works as expected together with current ASCOM beta release, I'm not sure they are driver related...
Receiving a feedback by other users could be of help.
What I found is that the hardware handbox can cause communication issues while LFEP is managed by the ASCOM driver.
So I would ignore these issues for now.
I'm interested in knowing if someone else has critical issues that make LFEP not working at all.
Thank you and Clear Skies
Armando
-
Hello everybody,
I had a session on Wednesday after to update the ascom driver
and I had some trouble to connect the LFEP >:( .
I need to change the COM3 to COM1 on windows and
everything were OK after that :D.
Thanks for you great job.
CS
Patrice
-
Hello Armando,
My Win 7 must be reconstructed, thatswhy my Test comes later
next week .
Best regards
Rainer
-
Hello Armando,
i tested 1.5.3. beta, but no not the version from today night , only one version bevor yesterday morning :
Following problems ;) :
1st. - Orientiation stay on EAST , after choose West and reset, i found EAST : in the preferences !
2nd. - The programm Astro - Photography Tool 2.2. ( Win 7 ) over MAC OS X cannot use the driver properly - Why ?
3rd. - Save windows - save the preferences to ?
May be i can test the new version today :)
Best regards and thank you very much for your and lizard_king`s work !!!
B.t.w. On Mac programms like Safari pro / Equinox pro no such problems exist ;D
Best regards Rainer
-
Hi Rainer,
first of all thank you for your reports.
1st. - Orientiation stay on EAST , after choose West and reset, i found EAST : in the preferences !
I was not able to reproduce the issue. Maybe it's related to the FW. Does the issue occur also when you invert Dec by ASCOM handbox?
2nd. - The programm Astro - Photography Tool 2.2. ( Win 7 ) over MAC OS X cannot use the driver properly - Why ?
Unfortunately demo version doesn't include ASCOM connection feature. I'm not able to check.
3rd. - Save windows - save the preferences to ?
The command is meant to save current GUI settings to restore them on the following ASCOM LFEP connection.
I see it works. Did you find it not working?
May be i can test the new version today :)
I uploaded a new update with some improvements: mainly I found annoying the too low RA and Dec update rate while telescope was slewing.
So I enabled RA and Dec update every 1s if telescope is slewing. I also forced RA and Dec update when a manual moving command by ASCOM handbox terminates.
Silent mode (I'm referring to the checkBox under "Locked" one in the motion control panel) now reduces traffic. I think it can be useful while guiding...
Clear Skies!
Armando
-
Hello Armando , first of all thanks for your answer 😀
1st - With the driver from wednesday and firmware 6.30
after set orientation to west in ascom and reset
the scope make a slew in north direction ? - Why i dont know ?...
The lfep handbox Shows W at the same time ascom Shows E ?????
2 nd - I found no problems in the saved preferences
3 rd - I will load your new version and test this version tomorrow
Best regards Rainer
-
Hi Rainer,
1st ...
Could you check if setting an higher timeout (by Telescope->Setup) solves the issue?
I also need your typical and max Response time (you find it in the first log lines...)
Let me know ;)
CS
Armando
-
Hello Armando,
i think problem solved ;D because of the newest ascom 1.5.3 . exe
After installation the current version i found :
1st - Response time 118,75 ms
2nd - Timout 1500 ms
3rd - After changing the orientation with my handbox while ascom is open - telescopesettings , than after
close and reopen the settings - orientation in ascom is the same as in the HB ;D - So i think the problem is solved :P
b.t.tw.
Can you increase the fieldsize of the logging field or change to a dynamic field size depend of the amount of lines ?
Best regards
Rainer
-
Hi Rainer,
Can you increase the fieldsize of the logging field or change to a dynamic field size depend of the amount of lines ?
I just uploaded a new release.
Now a right click on the log panel will keep the last 10 log lines and remove the previous ones.
CS
Armando
-
Hallo Armando,
super 😃
I wil test next week, because much to work in my Hospital .
Best regards
Rainer
-
Hi @all,
I'm evaluating to add a dew heater control to switch on the heater if temperature < dew point.
I could manage the heaters supported by the I2C extension.
But I see there is also a command (#>:VD#) directly supported by LFEP to set a dew heater with no need to use an external extension.
I'm tempted to think the value the user can set by #>:VD# controls a PWM output. But I see no pins related to it. ::)
Do you know something else about this command?
CS
Armando Beneduce
P.s. I'd like to procure a tiny interface together with a temp/humidity sensor. I've no idea where I could get it.
-
Armando,
I think this is related to the Auto Switch for the dew heater in conjunction with the tiny.
See Menue 3 Dew Heating Auto/On/Off.
However this function is a bit strange, if you had the heater in Off and set auto it will keep it off untill dewpoint is reached. If you have it in on and set auto it will keep the heaters on until dewpoint is reached... this is how I understod it but I did only a dirty fast test.
However it is setting an OpenCollector on the TinyInterface and you will need to have a small robo relais interface behind. I think this all works over robo focus behind and uses only the I2C temp feature. So maybe there is no need to use the tiny,... not sure regarding the menue 3 and how it works behind but i see the tiny was only something in between to make some new commercial feature easy to use. The temp feature should come from the I2C anyway,...
-
Hi the_lizardking,
I think this is related to the Auto Switch for the dew heater in conjunction with the tiny.
:(
However this function is a bit strange, if you had the heater in Off and set auto it will keep it off untill dewpoint is reached. If you have it in on and set auto it will keep the heaters on until dewpoint is reached... this is how I understod it but I did only a dirty fast test.
It could be useful to take into account a reversed logic in the connected hardware extension...
However it is setting an OpenCollector on the TinyInterface and you will need to have a small robo relais interface behind. I think this all works over robo focus behind and uses only the I2C temp feature. So maybe there is no need to use the tiny,... not sure regarding the menue 3 and how it works behind but i see the tiny was only something in between to make some new commercial feature easy to use. The temp feature should come from the I2C anyway,...
The command >:VD makes use also of the accumulator value. So I'm tempted to think that setting an accumulator value less then 255 will make a PWM output available... What I understand now is that this output will be available only by a Tiny interface. Really bad... >:(
As for I2C, each slave is identified by an address.
I'm not sure that a generic I2C address is accepted by LFEP.
For example my I2C focuser board (to measure focuser position) required a LFEP firmware change just to unlock an I2C address (the one I had to use in my I2C slave firmware).
I could obviously modify my I2C slave board so that it will also measure temperature and humidity and pass it, by LFEP I2C, to ASCOM driver...
But I'd like to have for once a ready to use feature... :)
In place of SHT-7X there are temperature and humidity measuring devices that are fully I2C compliant. They could be connected to LFEP with no Tiny interfaces... But maybe the LFEP FW won't make them working...
CS
Armando
-
Could be a reverse option,... Dont know but people should know how to use it. We have no clear specification,... Also not sure about the sht sensor because for cloud sensor there is absolute no specification,... And the tiny taken in the past was only for short period available ... So we are in a deep oneway road here without open source.
Another reason why we should hope to get out of this half commercial situation, this is horrible for progress. But i am not sure i think there was a direct connector on the i2c board for an temp sensor up from the old lfe or not?
-
Hi the_lizardking,
for the missing heater output I could use the fan output. :P
A better solution would be using the I2C extension already supported by ASCOM to control also the power for 4 heaters.
But I could implement the missing code in my I2C board.
So, in any case, the main issue is related to the temp. and humidity reading.
Just now I've no need to use a dew heater (Newton together with an OAG). But temp. could be useful to improve focusing.
I could make my board able to read temp and humidity too but I'll be obliged to use two sensors that are no I2C devices since they should be managed by my I2C slave. I may be wrong but I see that accurate sensors ready to use are only I2C devices. ::)
Another reason why we should hope to get out of this half commercial situation, this is horrible for progress. But i am not sure i think there was a direct connector on the i2c board for an temp sensor up from the old lfe or not?
I know nothing about LFE. And I don't know everything about LFEP...
CS
Armando
-
There is also a user defineable switch that can be controlled over ascom, so you maybe dont need to use the fan controll which makes sense for other application. There is menue in the ascom to control the user pins.
I think there where two pins for an external temp sensor. Because you have the one that messures the motor driver temp, which can be read out also,... I am not sure for what this sensor was planned for but would also be possible to use it outside the controler unit for messuring the temp. However does not help for hum.
Maybe this helps: http://elegance.rajiva.de/elegance/updates/I2C_Update.htm
This is from the old lfe and i think there was not a big change on that, its only integrated on the board now.
-
Anyway if the auto dew heater is already implemented I think I should implement nothing more in ASCOM.
Does it work as expected?
If you set auto mode when the dew heater is off it works as expected. But when a power cycle occurs do you need to set auto mode again?
CS
Armando
-
No this works as expected no bug here,... if you set Auto Auto is set for off or on.
-
Hi, I'm a new user of the LFEP.
I'm trying to learn to use it -a bit complicated and I find the manual somehow superficial, to be honest- so it may not be a real bug but just my mistake. Anyway, I've been trying tonight parking using the ASCOM driver and I wasn't able to get it working.
I selected PC parking, positioned the mount to the desired position, pressed the Set parking position button. Then, I moved the mount and pressed the park to stored position, but nothing happened. When I press the other button, park to current position, the mount stops, but the unpark button remains grayed.
Any idea?
-
I am not sure but could be that there are not all bugs fixed,... (did you load the latest driver?) I had close issues before. Important is also that the scope orientation is correct.
Would be great if you could test again, make sure orientation is correct and if the bug still remains let us know.
-
Yes, the driver was the last one (1.5.3 I think to remember, right now I'm not the same PC of the telescope and I cannot check).
I was making the tests indoor, without the telescope, just synchronizing the mount with the planetarium and seeing if it was moving correctly. The go-to was working as expected -I checked with the circles on the mount- so I think that orientation was fine too. The mount simply wasn't slewing to the park position. Tell me what I have to test and I will repeat everything this afternoon or tonight! I'm glad to help if I can!
-
I've made some further tests.
Turning on the mount and connecting the driver, in the setup windows the telescope was indicated as parked, with the unpark button enabled, so it looks like that the mount state is not updated until the driver is closed and opened again.
The Park button on the main windows stops the mount (also in this case, no go-to to the park position), the parking light on the interface flashes for a while, but the unpark button on the setup windows (is it missing on the main window?) remains grayed.
-
Do you mean you changed something on handbox and connected then to the unparked mount?
I think you should stay with ASCOM only for the test, we located some issues with parking crossed over,...
Did you try to push the parking button again until the unpark button is enabled?
I would also suggest to check that the coordinates of the mount are transmitted correct once startet the ASCOM as well as the option "remote controlled" in telescope setup is unchecked.
I hope I can also try today,... and will post some comments if I find the same issues. As I can remember the last time it worked,...
-
No no, I'm just using ASCOM, nothing else.
Yesterday night I made the test on the parking function, then I turned off the mount.
Today, when I turned the LF on, the RA motor start tracking. When I connected the PC, the tracking stopped, and when I opened the setup window the unpark button was active and the park buttons were grayed.
I pressed the unpark, nothing really happened because the start tracking when unpark option was disabled. The park buttons remained gray.
Then I tried again to disconnect and connect the LF, and the park buttons went active. If I pressed Park, the mount stopped without going to any position -like yesterday- and the unpark button remained inactive.
I will try to get some screenshot when I do the next test, and I will also check the coordinates -I was trying another thing and I didn't pay attention on that.
-
Hi gpaolo,
Yesterday night I made the test on the parking function, then I turned off the mount.
Ok
Today, when I turned the LF on, the RA motor start tracking.
Ok
When I connected the PC, the tracking stopped,
With startup mode ON, tracking is on after a powercycle even if a park command has been sent before the power off.
So the ASCOM driver sends a parking command soon after the ASCOM connection if the mount has been previously parked (by ASCOM).
and when I opened the setup window the unpark button was active and the park buttons were grayed.
As expected...
I pressed the unpark, nothing really happened because the start tracking when unpark option was disabled.
Please enable the option to start tracking when unpark...
Then I tried again to disconnect and connect the LF, and the park buttons went active. If I pressed Park, the mount stopped without going to any position -like yesterday- and the unpark button remained inactive.
To go to park position, current mount position is to be known by the driver. In any case after a powercycle the LFEP RA and Dec coordinates are lost. If the powercycle occurs after a parking command everything should work as expected.
I would suggest:
1. to be sure to have startup mode ON (by the handbox);
2. to enable the option to make the unpark command starting also tracking;
3. to send a sync command;
4. to move (by handbox, by ASCOM handbox or by a GoTo) to the desired park position;
5. to set the park position;
6. to move to different position;
7. to park and check if the mount goes back to park position;
8. to unpark;
9. to move to different position;
10. to park (and check if the mount goes back to park position);
11. to disconnect and powercycle;
12. to connect and unpark;
13. to move to different position;
14. to park (and check if the mount goes back to park position);
Please let me know ;-)
CS
Armando
-
Thanks Armando, I will try later to do as you suggest and I will let you know!
-
I think you have checked startup mode on, however I have the phaenomenom, that startup mode Off does not work on HBX,... no glue why, but dont be suprised.
-
Hi, yesterday night I was able to mount the telescope and try the system fully assembled.
It worked as it was supposed to do, so it seems that I was doing something wrong when I was doing the test indoor. Sorry :-[
Anyway, I noticed that, after the window "Telescope is parked" appears, the setup window does not refresh and remains as if the telescope were not parked. To have the Unpark button available, I have to close the setup window and open it again. I have also noticed that there is a very long delay (2-3 seconds) between when a command is issued (park or goto for example) and when it is executed. On my USB converter I have a led indicating when transmission is in progress and I can see that the delay is between the pressure of the button and the transmission of the command. Is it something that someone else have noticed?
-
No I was watching with serial mon and could see the command comming fast, only when the park position is reached to the point where unparked is shown there is some time in between where nothing happens but slewing telescop is flashing. And this is also correct the setup is not refeshed, but you could have the park button also on the handpad screen - this one is refreshed after parking.
-
Ciao gpaolo,
Anyway, I noticed that, after the window "Telescope is parked" appears, the setup window does not refresh and remains as if the telescope were not parked. To have the Unpark button available, I have to close the setup window and open it again.
Please let me know if the attached driver solves the issue. ;-)
CS
Armando
-
Armando,
I have some problems with the focuser,... seems that the fast mode does not work... cant use it.
-
Hi the_lizardking,
I have some problems with the focuser,... seems that the fast mode does not work... cant use it.
try to use the focuser with "Enable silent mode" checked; you find the option by a click on focuser setup (position tab). I hope it helps.
CS
Armando
-
Ciao gpaolo,
Anyway, I noticed that, after the window "Telescope is parked" appears, the setup window does not refresh and remains as if the telescope were not parked. To have the Unpark button available, I have to close the setup window and open it again.
Please let me know if the attached driver solves the issue. ;-)
CS
Armando
Thanks! I will try it as soon as I can!
-
I had the silent mode activated, so maybe thats the problem,... I will try today and let you know.
-
Hi the_lizardking,
I had the silent mode activated, so maybe thats the problem,... I will try today and let you know.
I hope you're referring to the Silent mode that can be enabled next to the ASCOM handbox. If so, then disable it... ;-)
The Silent mode I was referring to is the one available in the focuser setup (Position tab). If enabled, it reduces traffic while focusing.
I suggested Rajiva to implement this focusing mode to solve a limitation that made FAST focusing not possible at all with LFEP connection over Ethernet. It can obviously be used also when connection is over USB/RS232 and frankly I see no reason why it should be disabled (the only thing to note is that this mode is not Robofocus compliant).
CS
Armando
-
No i mean the one in Focuser Setup,...
This one was selected,... I will try other way round today, maybe there is some issue but let me test first.
-
Hi Armando, sorry if I disappeared, but between vacations and bad weather I was able to use the telescope just a few days ago.
The driver now works perfectly to me, thanks for looking into that! ;)
-
Hi @all,
I noticed last night that a click on North (ASCOM handbox) button made the mount moving to the South.
Even if I've no access to my mount now, I can modify the code to manage this issue.
But I need someone can make the following tests:
1. Check if ASCOM N button moves the mount to S;
2. Press N & S buttons at the same (on the hardware handbox, not the ASCOM one);
3. Check if ASCOM N button still moves the mount to S.
It's a good idea to repeat the test after a change of SideOfPier.
Please let me know.
CS
Armando
P.s. There is no need to make a test under the sky: you can simply check if Dec coordinates (shown by ASCOM handbox panel) increases/decreases while keeping N button pressed...
-
Ok,
I just checked. The command to move to N moves to S if PierSide is East; and the command to move to S move to N if PierSide is East.
In a few words if PierSide is East the mount moves in the wrong direction...
The attached driver solves this LFEP bug. ;)
But now I'm in doubt: maybe pulseGuide command is affected by a similar bug!
I can't really check it. I'll gladly appreciate a confirmation. This possible bug could be related to the issues found by gpaolo...
When a flip occurs there is no need to recalibrate the guider. But we need to know if the controller takes into account the change of PierSide when executing the PulseGuide command... In case of bug I can make the controller executing a PulseGuide command in the opposite direction to solve the issue... But I need a confirmation...
The required test is the following one:
1. calibrate the guider;
2. make a flip;
3. start guiding without guider recalibration and check if the tracking error on Dec is properly managed.
Thank you!
Armando
-
Ok,
I made another test by a JS script. North and South PulseGuide commands work as the N and S moving commands: a North PulseGuide makes Dec decreasing on East SideOfPier (and increasing on West SideOfPier).
This working mode can be the right one for PulseGuide: if guider calibration is made only on one side, after a pier flip the reverse (let's say "wrong") motion caused by a PulseGuide command will automatically manage the occurred flip...
But the guiding software is to be properly configured since this implementation of PulseGuide is not ASCOM compliant.
As for example, If you're using Maxim DL you have to enable Auto Pier Flip (in guide panel) and Reverse X in Guider Motor Control settings (Guider advanced settings) to eliminate the need of new guider calibrations after a flip...
CS
Armando
-
Hello Armando,
today i tried to test your new driver from Nov. 4 th.
Thank you very much !!!! ;)
The direction N,S,E,W now are correct , but the pier side is the opposite of the side
i can read in my Handbox.
HB is "W" and ascom driver says "E" , its my issue ?
Best regards Rainer
b.t.w. attachment sun from today ;)
-
Hi Rainer,
HB is "W" and ascom driver says "E" , its my issue ?
What is the real side of pier?
CS
Armando
-
Hi Rainer,
if the SideOfPier reported by the HB was wrong I think the attached driver can solve the issue.
To test it you have to change rotation on Dec. If you're using normal mode on Dec then set reverse mode; if you're using reverse mode on Dec then set normal one.
Please change Dec rotation by the HB (Display menu -> Controller -> Mount Setup -> Axis Dir -> Dec -> ...) and then connect the controller by ASCOM.
While testing the driver (mainly GoTo, flip and parking commands) please be ready to stop the mount in case of need!
Thank you for your help!
Armando
-
Hello Armando -
o.k. so i will do it after rain stops ::) tomorrow morning !
Thank you !
Regards Rainer
-
Hi Rainer,
I made other small changes and uploaded the new driver on SourceForge:
http://sourceforge.net/projects/lfepascom/files/LFEP%20ASCOM%20Driver%20%281.5.3%20Beta%29.exe/download
I hope you'll find it working as expected.
Thank you again and Clear Skies!
Armando
-
Hello Armando, because of to much rain drops in the air,
I will Test the new driver on Weekend - i will report the result .
B.t.w a Great digital Click with startime - Local time would be fine
inside the LFEP -Controll panel
Best regards Rainer .
-
Hi Rainer,
B.t.w a Great digital Click with startime - Local time would be fine
inside the LFEP -Controll panel
Local hour angle is already shown. What do you mean by star time?
CS
Armando
-
Hallo Armando,
Local Hour angle is o.k., you are right,
But a nice digital clock black background and
Red digits :D mmmh,
Best regards
Rainer
B.t.w. Many rain drops , to many :-[
-
Hi Rainer,
in the meantime I applied other changes to improve the driver.
I'm trying to make the (hardware) handbox causing no ASCOM communication issues.
Now the driver should be able to communicate to the controller even if the handbox is displaying current coords (with the handbox update interval set at 2s or more). ;)
Let me know...
CS
Armando
-
Ok, I solved other driver bugs.
Making the handbox working while LFEP is connected by ASCOM obliged me to evaluate if the generic answer (received by ASCOM) is corrupted. There is the need of managing unexpected data available in the input buffer (because of the handbox showing current coordinates on the display).
So I opted for a drastic driver change: if after a readout (of the expected number of bytes) from the input buffer there is still some data available, then the driver discards the input buffer content and resends the command...
Now I see the driver working as expected on my LFEP. 8)
Unfortunately I found a new firmware bug: sending the command #14:VX# the answer length is 8 bytes (it should be 4 bytes)!
I hope this bug affects every LFEP unit and is not related to the firmware stored in my LFEP... If so the driver will work also with your LFEP units without the need of other changes...
So please let me know the length of the answer after you've sent the command #14:VX# and your LFEP firmware release.
Clear Skies
Armando Beneduce
-
Some LFEP firmwares don't properly implement IntellyTrack. In this case it's a good idea to keep IntellyTrack OFF. Maybe all LFEP are affected by this bug.
So I added an option (Telescope -> Extra) to keep IntellyTrack OFF.
http://sourceforge.net/projects/lfepascom/files/LFEP%20ASCOM%20Driver%20%281.5.3%20Beta6%29.exe/download
If you enable this option then the IntellyTrack checkbox will be disabled. Then the only way to enable IntellyTrack will be the hardware handbox but the change will be temporary: the ASCOM handbox will take care of keeping IntellyTrack OFF. ;)
I just discovered that IntellyTrack is not available at all while using UserRate. This is another good reason (together with drift compensation working only in user rate mode) to prefer User rate in place of Sidereal one.
CS
Armando Beneduce
-
Hi @all,
yesterday I took some photos by using the last beta release.
I tried RA drift compensation. Without drift compensation the mean value of guiding pulses duration on RA (taken negative on RA+) was about 8s (on one worm revolution).
After the 1st RA user rate refinement it was 120ms. 8)
HB is "W" and ascom driver says "E" , its my issue ?
Yesterday I found still the same issue with the last beta. To test it I had to set reverse rotation on Dec (as expected) and I found that orientation reported by handbox was no more like the one reported by ASCOM.
So I think that setting reverse rotation on Dec makes LFEP returning the opposite orientation (by the handbox).
Probably the command to set PierSide works contrariwise when reverse rotation is enabled...
Improving the driver is starting to become a little irritating: I think LFEP makes what indicated by the documentation and I change the code accordingly. Then I use the mount and I find something not working. Too often I find wrong documentation as the real cause of the issue (or if you prefer, a LFEP firmware bug).
Unfortunately I'm using my mount too seldom and I still have slow motors on my mount to test some features.
Anyway now I need to figure out how to make the hardware handbox showing the same orientation as the one reported by ASCOM. ::)
Fortunately these issues can be properly managed by ASCOM; or, if you prefer, there is the need to rewrite the LFEP documentation...
CS
Armando
-
Hello Armando,
I would prefer ascom ;D
Regards
Rainer
-
Hi Rainer,
Hello Armando,
I would prefer ascom ;D
No :), I meant to say that there are issues that can be considered as LFEP bugs (and so require the driver to properly manage them) or as documentation errors (that still oblige to modify the ASCOM driver).
CS
Armando
-
Hello Armando, thanks for your explanation :D
Now i understand.
B.t.w. A new question :
What means a drift compensation in detail
Drift in ra / drift in dec / or drift compensation to correct
Alignement problems of polar or azimut axis.
How to do it ?
Best Wishes
Rainer
-
Hi Rainer,
Drift in ra / drift in dec / or drift compensation to correct
Alignement problems of polar or azimut axis.
You can see Reset, Refine and Set buttons.
Both Reset and Refine buttons start measuring drift. But Reset also switches to sidereal speed (it resets user rate at sidereal speed); refine keeps current user rate unchanged (drift measurement occurs in this case at current user rate).
When drift measurement is completed you can click on Set button to apply the computed drift compensation...
But when is drift measurement completed?
1. On RA axis only after a worm period has elapsed since the click on Reset/Refine (to take into account the periodic error that could affect drift measurement). So you will see a countdown will start as soon as you'll have clicked on Reset or Refine... At the end of the measurement Set button becomes enabled...
2. On Dec you can click on Set as soon as you think enough time has elapsed since the click on Reset/Refine. So you will see a counter will start as soon as you'll have clicked on Reset/Refine. The counter is just meant to show the time elapsed/used for drift measurement...
Then the driver (on Dec) will take care of the time elapsed between the click on Reset/Refine and the following click on Set to compute the drift and the required user rate to compensate it...
The idea is simple: on RA tracking speed could be wrong; on Dec you can have drift because of a not perfect polar alignment.
So the driver, as soon as you click on Refine or Reset, starts to sum all guiding pulses duration.
After one worm period on RA you would expect 0 as the sum (I assigned negative sign to RA+ pulses and positive sign to RA- pulses). But you'll probably find a positive or negative value because of drift. As soon as you'll have applied the compensation the motor speed will change accordingly and in the next drift refinement you should find a lower (ideally 0) mean value of the duration of the pulses occurred during the refinement period...
On Dec the same happens but without a countdown: ideally Dec motor should not move at all while tracking. But if, after a Reset/Refine click and some minutes you see the sum of the durations shown is still increasing (or decreasing) then there is a significant drift that you can compensate by a click on Set. After the click, Dec motor will start moving at appropriate constant speed (it should be small) and you should see that the following guiding pulses duration will show a mean value really small (ideally 0)...
I mean to point out that drift compensation requires the use of pulse guiding (i.e. guiding by ASCOM): ST-4 guiding commands (and durations) can't be detected by the driver...
CS
Armando
-
In a few words, since IntellyTrack doens't work, I replaced IntellyTrack by the driver itself.
Even if IntellyTrack worked, the compensation by the driver should be better since it's computed after a measurement taking many minutes...
I made use of UserRate mode that was meant to be used only to track comets/satellites but that can be of help to improve tracking also on common stars moving at sidereal speed...
CS
Armando
-
Hello Armando,
Tomorrow after sleep 5 h i will try to understand.
I think a step by step list would help ?
Good night
Rainer
-
I think a step by step list would help ?
1. Start guiding by ASCOM
2. Click on Reset (on RA drift panel)
3. Start giving a look at the sum of RA pulses duration (on the same drift panel) and wait for the end of the countdown
4. Click on Set (on RA drift panel)
5. Click later on Refine and start giving a look at the sum... values should be lower then the previous ones and, at the end of the countdown, the sum should be next to zero...
The same happens on Dec but without a countdown. For Dec simply wait some minutes before any click on Set...
CS
Armando
-
Guys I would like to test also,... such a shit at the moment it looks like that here:
http://abload.de/img/fotobdav4.jpg
-
Hi @
the weather here near Berlin shit to
I hope we can see the sun in a few day's
CS Rainer
-
Hi @all,
meanwhile I'm describing some changes (available only in beta6 release) about flipping.
They are available only if you enable also "confirm" option in the AutoFlip settings panel...
You know that a flip is possible also by passing through the South Pole. And flipping through South Pole is quicker if Dec is negative...
So when a flip is going to start the driver will ask you if you prefer a flip through South Pole or North Pole...
The question is required also when Dec is positive to allow the user to take control of the flip and to exclude a flipping through S Pole followed by a flip through N Pole...
I implemented also another improvement to exclude pillar collision by the flip itself:
when necessary, the flip will make the mount moving only on RA to point to local meridian and THEN it will start to move on Dec too...
In a few words you'll see, when necessary, that moving on Dec (during a flip) occurs only after Telescope is on a vertical plane to have no pillar collisions...
I also preferred to keep flip button always enabled. Now Flip text color is red if the flip is potentially dangerous.
Sometimes the user realizes he can switch to the "dangerous side" to have all the photos from the same side (i.e. starting with telescope on East side and pointing to East if it's really mechanically possible)...
I hope you'll find flipping working as expected...
CS
Armando
-
Great Job Armando!
-
Hi the_lizardking,
A test can be of help so that I'll upload the code before going on with development. Did you try it?
CS
Armando
-
Hello Armando,
what you mean with "guiding" and drift correction ?, Guiding speed sid . with corrections f.e. autoguider
or guiding with sideral speed without any corrections .
Best Wishes Rainer
b.t.w.
fog ! instead blue and clear sky ; ((((
-
Cant do anything here right now,... only fog, snow, wind,... horrible weather since weeks.
-
Hi Rainer,
what you mean with "guiding" and drift correction ?
as already stated drift compensation requires that mount is tracking at user rate and that the autoguiding software is sending pulse guide commands by ASCOM.
CS
Armando
-
Hello,
Yesterday I tested the last update. The clouds wasn't there since a wide.
Usualy, I used to going at 100X for the goto with my CG5 original motors but now i need to fix them donw to 50X.
At 100X, my motor don't work at all, at 50X they work good but it too slow. Between these values motors don't run aconstatilly.
even if the 40V delevery is on.
I didn't change any courants values for the motors.
Did I need to change something?
CS
Patrice
Thanks I move the topic to the LFEP part.
CS
Patrice
-
Hi Patrice,
Did I need to change something?
Issues related to motor speed are obviously not related to the ASCOM driver in use: you will find the same speed limitation also by using previous releases or by moving the mount by hardware handbox.
Maybe you're using a too low current value for your motor or your battery is not properly charged (if you're using a battery to power your LFEP).
Keep in mind a too low voltage will make V40 board not working: some days ago I started to think my V40 was faulty (I can hear a louder motor noise while V40 is enabled). Then I realized the battery voltage was well under 12V... :)
You can also try to set an higher ramp value, if available.
Another cause of the speed issue could be a low temperature so that an higher load torque is required (e.g. because of bad grease or too small worm-worm wheel play).
Clear Skies!
Armando
-
As for drift compensation I used it on RA for my last photo (7x30min frames):
http://galleria.astrocampania.it/albums/DeepSky/nebulose/NGC2237%2020131207%20BENE.jpg
It's at full res (800mm f/4 - KAF8300 mono CCD) and I think tracking is pretty good so that I'm not sure upgrading motors (to increase GoTo speed) is worth it. ::)
Every time I disassemble my EQ6 I'm not sure what results will follow...
Anyway I already bought the pulleys kit and the motors. So I think I'll try them as soon as possible...
CS
Armando
-
Looks good,... however there is a samll drift but could be related to the alignment maybe.
Grats for the nice picture!
When you say we need to go over ascom, do we only need to work with an ascom camera driver going from camera to lfep or must the lfep be connected to the pc somehow??
-
Hi the_lizardking,
Looks good,... however there is a samll drift but could be related to the alignment maybe.
There is apparent coma but I think the stars are pretty round near the center-bottom part of the frame...
When you say we need to go over ascom, do we only need to work with an ascom camera driver going from camera to lfep or must the lfep be connected to the pc somehow??
Do not guide by ST-4.
CS
Armando
-
OK then Camera to LFEP ASCOM driver,... understand.
-
Hi @all,
I just uploaded a new driver on SourceForge:
http://sourceforge.net/projects/lfepascom/files/LFEP%20ASCOM%20Driver%20%281.5.3%2005-04-2014%29.exe/download
Before going to post an update notice message on this forum I'll gladly appreciate some tests mainly related to flip and parking.
Clear Skies
Armando Beneduce
-
I received no feedback about the last release. ::)
Anyway... I found a bug; a new driver is available.
CS
Armando
-
Hello Armando,
The recent weather conditions are
April like, very poor.
Thank you for your work 😀
Rainer
-
Hi Rainer,
I know that weather is not good at all...
But, if possible, we should test the driver also with bad weather so that we find no bad surprises under clear skies...
Unfortunately I can't test park and flipping and your feedback is really useful to speed up the driver development.
Anyway I hope current driver is working.
CS
Armando
P.s. You can see a file that includes "TDM" in its name is also available on SourceForge. Please ignore it: it's meant to control an I2C slave used to power Off TDM while mount is slewing. I implemented this solution to exclude possible flip/parking issues when a TDM controller is in use.
the_lizardking will use it. If someone else means to equip his mount with TDM I'll provide further details about the required hardware and I2C slave firmware requirement.
-
Hello Armando,
I just installed the new driver 1.5.3 23-04-2014. Using FW 5.88 I will send you the following feedback:
The confirmation sound, that could be heard after changing a setting with a click on apply or OK is not active any more. Now the slewing led is blinking for a while after clicking on one of the both buttons.
After setting a park position and afterwards clicking on the park button the tracking stops properly, the parking and slewing led starts blinking but the mount didn't move. Instead the driver sends the error message, you will find in the attachment.
The manual flip function I've tested with driver version 1.5.3 13-04-2014 and no error occurs. Regarding the flip function, I have two questions:
When I start the manual flip, the mount moves to a middle position, where the telescope points to the northern direction. In that position it rests for a while. Afterwards the move was competed. Is it possible, to disable that function or to shorten the time of standstill?
I miss the automatic flip function, that aligns the telescope depending on the position of the object. If the object is been located on the western side of the meridian, the telescope should be located in the east. By analysing the coords of the object, the LFEP should be able to locate the telescope in the right position. At the moment I use the manual flip function to position the telescope on the right side. Would it be very difficult, to implement such an automatic meridian flip function for all the observers, that didn't use a photographic equipment?
CS
Heinz
-
Hi Heinz,
After setting a park position and afterwards clicking on the park button the tracking stops properly, the parking and slewing led starts blinking but the mount didn't move. Instead the driver sends the error message, you will find in the attachment.
OK, I see the exception. I think you didn't enable autoflip for GoTo.
I think that if you enable autoflip for GoTo the exception doesn't occur.
Regarding the flip function, I have two questions:
When I start the manual flip, the mount moves to a middle position, where the telescope points to the northern direction. In that position it rests for a while. Afterwards the move was competed. Is it possible, to disable that function or to shorten the time of standstill?
I want to make the driver able to avoid pillar crashes.
You can enable autoflip for GoTo (and/or parking) so that if a flip is opportune it's executed. But you can also force the driver to ask for a confirmation before executing a flip. So if the driver recognizes a flip is opportune but you don't confirm the flip it won't flip. I want to exclude a pillar crash also in this case...
So I had to add other GoTo steps to manage these conditions.
Now I don't know exactly what step you're referring to... Probably you're referring to the step during which the scope is apparently not moving but you can see it's moving (slowly) to cross the N (or S) Pole. If this is the case we need to keep the driver as is; you need just to wait some seconds while scope moves at 16x to cross the Pole.
I miss the automatic flip function, that aligns the telescope depending on the position of the object. If the object is been located on the western side of the meridian, the telescope should be located in the east. By analysing the coords of the object, the LFEP should be able to locate the telescope in the right position. At the moment I use the manual flip function to position the telescope on the right side. Would it be very difficult, to implement such an automatic meridian flip function for all the observers, that didn't use a photographic equipment?
This feature is already implemented.
You can enable AutoFlip for GoTo and/or for parking. You can also force the driver to ask for a confirmation so that you can still exclude a flip if you want...
For parking you can set a parking position that is good on both sides of pier. This is the reason why you can disable autoflip for parking. If you want to park always at the same side of pier then you've to enable the autoflip for parking. Finally you can also enable autoflip for parking with confirmation required...
I realized that a pillar/tripod crash could be caused by the flip itself (e.g. scope next to tripod and pointing to W near the horizon)!
So I started to deeply modify the driver to take care of many conditions that can cause a pillar crash (the flip itself, when scope is already in an unusual position because of a lot of time passed since the meridian cross; or when a flip is "suggested" by the driver but the user doesn't confirm it; or when the user means to move to a "dangerous position" starting from a "good" one; etc. etc...).
Just for example, if you're pointing to NW with the scope on W side of pier ("bad position") and you send a GoTo to SW a flip is advisable. If you enable autoflip the driver should execute it (and move the scope away from pillar, if necessary). But I added also other steps so that if you don't enable autoflip or if you don't confirm the flip (with flip confirmation required) the scope will move upwards, then only on dec to "bypass" the pillar and finally will point to the target... Other steps occur also if you try to move to a dangerous position. Someone can prefer to park with scope pointing under the horizon... So you can see a pillar/tripod crash against the front side of the scope! The driver should manage also these conditions.
You see I added other settings (in safety tab) to define a dangerous area "around the pillar/tripod" in terms of distance on RA from local meridian when declination is not too far from Zenith's declination (you can set 2 values to define the minimum distances on Dec from Zenith). These values are used to make the driver able to "bypass" the pillar itself.
These are the main changes that I was able to test only "virtually" by CartesDuCiel since my mount is too slow (40x GoTo).
Please let me know if you find the autoflip working and if you see the driver bypasses the pillar as expected when you force the driver to make no flips or when you try to make dangerous GoTos...
CS
Armando
-
The following driver should fix the exception bug:
http://sourceforge.net/projects/lfepascom/files/LFEP%20ASCOM%20Driver%20%281.5.3%2027-04-2014%29.exe/download
http://sourceforge.net/projects/lfepascom/files/LFEP%20ASCOM%20Driver%20%281.5.3%2004-05-2014%29.exe/download
CS
Armando
-
Hello Armando,
thank you for the detailed explanation. The possibility to enter a time in the flip menu had been the reason for my confusion. Such a function I combine with photographic use only. The HW handbox of my CGEM mount didn't expect to enter a time. It is flipping dependent only on the coords of the objects.
Your explanation, that the pole crossing is moving at 16x had been very helpful. I only had to raise the speed.
The version 28-04-2014 of your driver had fixed the exception bug. The parking function now operates as expected.
The bypass – function I'm not able to test at the moment, because the shack that contains my scope isn't very large. The long scope, I'm using presently, perhaps would crash to one of the side walls.
Using E&T I've chosen a couple of stars alternating on both sides of the meridian. The mount every time flips on the right side with pole crossing at 16x.
A GOTO to Polaris was running in a different way. The scope was located at NW when I started the GOTO. The mount was running to the pole cross position and rested there for a few seconds, moving at 16x. Then it was slewing back to NW until it pointed to Polaris.
After that I started a GOTO to Mars, but that time not using E&T but the HW handbox. The mount was slewing to SE (the bad side) and pointed to Mars. That time the mount crossed the pole without moving at 16x. The whole movement was executed with GOTO speed.
When I parked the scope later on, I noticed that the SW handbox now displayed the wrong orientation (West instead of East). So I think, that it isn't good to use the HW handbox and the driver together for GOTO commands.
CS
Heinz
-
Hi Heinz,
Hello Armando,
thank you for the detailed explanation. The possibility to enter a time in the flip menu had been the reason for my confusion. Such a function I combine with photographic use only. The HW handbox of my CGEM mount didn't expect to enter a time. It is flipping dependent only on the coords of the objects.
OK.
Your explanation, that the pole crossing is moving at 16x had been very helpful. I only had to raise the speed.
Crossing the pole is at 16x speed whatever is the speed associated to 16x pad speed. ::)
Another reason why you could have thought that mount was not moving (during the flip) could be the starting position: when Dec is about +-90° you "see" a slow slewing on RA if you "follow" your mount on a sky chart...
The version 28-04-2014 of your driver had fixed the exception bug. The parking function now operates as expected.
OK. From time to time give a look at Sourceforge to update the driver. Only when I'll have properly tested the driver I'll post a notification about it on this forum with a change log too...
The bypass – function I'm not able to test at the moment, because the shack that contains my scope isn't very large. The long scope, I'm using presently, perhaps would crash to one of the side walls.
In any case while testing the driver be ready to stop the mount (a click on Stop or simply a press on any HW handbox button is enough: the driver detects the slewing has been aborted/has failed). Only the step at 16x speed required to cross the Pole requires a click on Stop (or an abort command by any ASCOM client) to be aborted. But generally crossing the Pole is quick and so it's pretty unlikely that you'll abort a slewing exactly while mount is crossing the Pole...
Using E&T I've chosen a couple of stars alternating on both sides of the meridian. The mount every time flips on the right side with pole crossing at 16x.
OK.
A GOTO to Polaris was running in a different way. The scope was located at NW when I started the GOTO. The mount was running to the pole cross position and rested there for a few seconds, moving at 16x. Then it was slewing back to NW until it pointed to Polaris.
Polaris is circumpolar and it's one of the targets that can be located "under" the plane orthogonal to your local meridian, even if above the horizon.
For this part of the sky I had to take care of other issues: front side of the scope could collide with the pillar/tripod. I think I need to test by myself the driver to figure out if some changes are required... Anyway the priority is to keep the driver safe so that no pillar crashes can occur.
After that I started a GOTO to Mars, but that time not using E&T but the HW handbox. The mount was slewing to SE (the bad side) and pointed to Mars. That time the mount crossed the pole without moving at 16x. The whole movement was executed with GOTO speed.
When I parked the scope later on, I noticed that the SW handbox now displayed the wrong orientation (West instead of East). So I think, that it isn't good to use the HW handbox and the driver together for GOTO commands.
I modified the driver so that playing by the HW handbox is possible: previously the driver crashed as soon as you started to play by the HW handbox to send a GoTo command.
But obviously I still suggest to use the PC to control the LFEP.
If you see that HW handbox shows a SideOfPier that differs from the ASCOM one I think your Dec motor rotation is reversed (Dec motor settings). I can do nothing to solve this bug. If I make the driver OK for your Dec motor cables then the users with normal (not reversed) Dec motor rotation will find the HW handbox showing a SideOfPier that differs from the ASCOM one... :)
As for parking, it's useful only for fixed observatories. And I see no reason to prefer the limited functionality of the HW handbox to control the LFEP at home...
In a few words I see the HW handbox useful on the field, when the equipment is limited and no PC/notebooks are involved, just to point using the catalogs stored on the memory card...
But if you have a PC then the ASCOM driver offers an handy control of the mount...
CS
Armando
-
I totaly agree,... if you have the change to use a PC use the ASCOM driver to run the mount. I have a fixed obs and do even not go outside anymore. The driver is meanwhile so good that it works perfect!
Also parking works fine which never worked proper with the handbox - only when you have a crazy parking position like I have it comes to probs from time to time :) . I remember when we began and we where only searching bugs,... most of them on the Handbox and we had an unfinished driver,... today Armando made the safest driver I know moving the mount very intelligent and really safe. Also you can rely on the functions,... the Log gives usefull messages and the driver catches all features, even some that on the handbox never worked...
-
Hello the_lizardking,
I totally agree too! Armando has created an excellent driver. He asked the users to test it under different circumstances. While testing, I noted all observations of mount moving to be able to send back an entire report, hoping that it would be helpful.
The using of the HW handbox should complete the test result, because it is also part of the LFEP. When I'm not testing the driver but enjoying a starry night, be insured that I'm not use the HW handbox, except for correcting instructions to center an object with the red buttons. ;)
CS
Heinz