ahhhh, I get it now, thanks. The hose makes sense.
Magnus, would you mind posting a picture(s) of your hack ?
thanks for the reply. I saved what I thought was the guide log to a user selected directory on
my pi running SM OS. It was well after midnight and my brain fog has left me with no idea
how I did that save to file... probably the save button under the drift plot on the guide page.
The file is comma delim unquoted text: csv. Here are the first few lines
Frame #, Time Elapsed (sec), Local Time (HMS), RA Error (arcsec), DE Error (arcsec), RA Pulse (ms), DE Pulse (ms) 0,3.731,10:38:49 PM,0,0,0,0, 1,5.381,10:38:51 PM,0.726482,-0.0765854,-59,0, 2,8.741,10:38:54 PM,0.333473,-0.962496,-27,128, 3,10.674,10:38:56 PM,0.660558,-0.607185,-53,0, 4,14.013,10:39:00 PM,0.0650261,-0.279312,0,0, 5,15.993,10:39:01 PM,-0.594562,-0.475873,48,0,
FWIW, I rarely get guiding working that well either (I use an Atlas Pro, which I believe is pretty similar to the HEQ5 pro, though not sure).
Some of it depends on the seeing and the sky position of your target.
I find, though, that using the GPG RA guide algorithm helps me.
Are you using that?
BTW, GPG RA guiding resets every time you slew, and it can take 15 minutes after a reset to get to its optimum performance.
my SCT rig is much heavier but I hope to improve guiding after removing the guidescope and
Without checking every thing, no more than 3KG or 3.5KG I would say.
thanks for replying inline and yes the LR plot. Animations might be useful for explaining guide performance in visual
terms. I develop software for medical image analysis / review and find interpreting
changes statically or over time visually is insightful. I read a number of posts here and on CN around guiding
issues and having experienced poor guiding performance and wanted to review my data
in phd log viewer but the .csv file I saved from Ekos would not load. I can review prior .activity files in
Ekos but a review in phd log viewer may be more helpful for now.
A typical session: I work at 1 or more imaging targets. My process is (after PA) to select, slew to,
capture and solve with guide scope / camera then loop on the main camera and nudge the mount to
center the target, then start guiding with dithering every frame or some other periodicity. The
analysis tab shows sections of guiding followed by gaps due to other activity: finding a different
target, focusing, dithering etc., so within an acquisition session there are "rms gaps". I want
to plot the rms scatter for that session cumulatively (ie, ignoring gaps) or in time progression
via animation. I am also unclear on semantics since it could depend on workflow. What if the user
determines that for now: ala file explorer apps wherein you ctrl click for individual (in time sequence)
sections and shift click for the whole shuhbang?
what is the weight load on your mount ? I am payload overloaded and can only get that rms response
from the new SEP guide algorithm under optimal sky conditions and certain targets regardless of camera
the analyze tab in Ekos is great! thanks for adding this very useful and informative feature. A few remarks/ques:
- from the timeline graph of the guide activity, I can click on a section and view the rms scatter plot. Is
it possible to ctrl or shift click or some other select action to plot multiple segments ?
am guiding with dithering, which breaks up the rms record, but would like to see the rms plot for the whole guide session
- playback of the guide rms scatter plot showing accumulation of data points ?
- can the data be exported to a phd2 log viewer readable text file ?
I see nothing wrong with your plans ... but I haven't tried what you are suggesting so have no experiential
knowledge to share. The only other thing I suggest with the pi build is to monitor your ram and cache
mem usage while the compile and linking is going on. I didn't clue in on the cause of my builds failing until I actually observed
the pi running out of resources. I didn't get the error you are seeing, so even increasing swap mem may not
be the solution. If you haven't tried conky for desktop monitoring your system, you can use the file attached and
setup instructions here ( tinyurl.com/mf33uvn ) and elsewhere.
I found this solution and variants thereof on a few threads you may also try :
sudo apt purge binutils
sudo apt remove make
sudo apt autoremove
sudo apt install build-essential
:~/Projects $ sudo rm -rf indi
and change this
:~/Projects $ git clone --depth=1 github.com/indilib/indi.git
:~/Projects $ git clone github.com/indilib/indi.git
then remove your build and cmake it again (RelWithDebugInfo instead of Debug)
BTW, highly enjoyed your post on building the remote box ... very cool!
a diff on your CMakeCache.txt shows its the same as mine, just you are missing libgmock.so ... you can apt install if
you want but I don't think that matters. What is weird is the very first line of calling cmake to refresh... that indicates
a git error of some kind. Can you delete the git clone of indi, reclone it, make sure its on master branch, rm -rf your indi
build dir and start again ?
you are doing everything correctly AFAIK. Can you cd into your build directory and enter
and post the result here. What does lsb_release -a say ? And finally, can you post your CMakeCache.txt
from the indi build dir ?
i built indi and kstars on pi 3B+ two days ago using github master branch but
with build type RelWithDebugInfo. I also had to set my swap space to 2Gb. First time
through on building kstars with all other default options in CMakeCache.txt set I would
get the linker bombing out so I turned off testing and it built to completion and could run
FWIW, while tinkering around with my Pi 3B+ I imaged raspbian OS onto a USB SSD drive, compiled
indi, kstars, phd2, phdlogger and ekosdebugger. Jasem, can you add an ekosdebugger icon and .desktop file to
your github repo ? Great work as usual BTW!
I want to re-purpose an unused SynScan GPS mouse to provide gps functionality to a raspberry pi running KStars
but have no idea how this would work. The mouse has a MINI-DIN female to 4 pin Grove connector cable. The
other cable that comes with is a MINI-DIN male to RJ12 for connection to the hand controller. I don't use the HC
since I have an EQDir cable running from the pi to the mount, hence the thought of re-purposing the mouse.
I popped the case apart and can see the Grove connector attaching to a matchbook sized PCB. The PCB has
a thin metal shield/cage that prevents reading any chip info etc. but at the connection interface on the PCB
I can read off the following beside each of the 4 wires:
BLK : GND
I believe this is ground, power (what voltage?), receive and transmit. The connection to the PCB could be replaced
with a 4 pin Grove connector to jumper set ( tinyurl.com/y3pmbkyu ) and then connected to the pi's GPIO.
Any suggestions on how to proceed ?