Update - this is an issue in OnStep itself - confirmed with working SD card running on different version of mount FW....ignore this issue

Read More...

Update - reverted back to 1.8.6 - no change, so it is not INDI. Turned on verbose logging and the commands appear to be sent from using set absolute position - so this leads me to lower communication or perhaps syntax...but again no error return code. I also turned OFF BT connection from phone app just in case it was a control contention = same result.

Read More...

Latest code compiled from master - both KStars and libindi
Running on AstroBerry - PI4 4gig
All devices fine - mount operation fine using OnStep
EKOS KNOWS the focuser is there and reports position correctly.
Use the IN or OUT or set absolute position and the numbers in the GUI change but the focuser is not actually moving
Use the OnStep app on phone connected by bluetooth and the the numbers reflect position set in EKOS BUT I CAN move the focuser with the in/out buttons on that app (EKOS reflects the numbers updated via the phone app so comms are fine) - this means the motor drivers and base commands in the drive/mount are OK

To be honest it feels like there is some code commented out as there are NO errors or warnings, and everything operates visually as if it is actually doing work - almost as if it was stubbed out for testing somewhere - have been running through code but have not seen anything yet - were there any recent changes to focus?....

My OTHER build on PI4 8gig was built from source but a few days earlier and was focusing correctly (meaning actually moving) - I built libindi within the past 48 hours on the non working unit

Thanks for the quick thoughts in advance :-)

Read More...

Hey Stewart...if you have not seen FB yet I can report that the new build on PI4 8GIG using Astroberry and 128g SD and also booting from 500g mSata vis USB3 all all good and stable - FULLY updated with Raspbian and I also built latest Kstars + stellarsolver on the PI. Have had no issues in over 24 hours of constant load testing (does anyone need that many darks :-) ).....I have started doing a diff of services running SM vs AB and the first that popped up was X11 was NOT running on the AB as it comes installed with VNCserver. That Boot issue we have both encountered I am starting to suspect was nothing to do with drives or size but more related to order of boot services and timing (perhaps via USB you get dragged a little as it is not the original way a PI knows to boot and there could be race condition there that gets triggered - or as I loved to troubleshoot years ago NIC and Graphics incompatibilities which at least in windows ended with BSD) - anyway - eventually I will start breaking the AB setup by turning on services to match SM until it dies -

Read More...

AstroNerd is friends with JAMIE FLINN

Thanks - I like living on he edge :-)....I keep a horde of SD cards with different version so I can also get back to running while I debug things

Read More...

Build of both complete and back to 3.5 beta! Yahhooo. Park works, and now to test - my point in all of this is to find the diff between astroberry and smtellarmate that is causing the issue related to boot and any drive larger than 64gig - now I can comparatively test...thanks for the help

Read More...

Again - you are rockstar! successful build of stellsolver and the make is in progress now for Kstars
Will close this one when complete :-)

Read More...

HI Jasem...
I have set up a brand new astroberry install - it is reporting 3.4.3 KSTARS but I know it is not latest as it still has that wonderful crash-on-park with OnStep bug which you have fixed.....I need to either find a way to get your nightly build or as I am doing now, try to compile form GIT - when I do this I am missing STELLARSOLVER....however there apparently is no package I can find to install it!.....I am between a rock and hard place here:
1) is there wa ys to install your nightly build on astroberry
2) where or how can I find stellarsolver for raspbian OS
3) am I just pooched until you release and update that astgroberry ppa sets up?

Thanks in advance!!!! Jamie

Read More...

JAMIE FLINN created a new topic ' Dashboard cannot connect' in the forum. 4 months ago

Hi...

I have my SM OS on PI4 8gig - fully updated and running fine except for DASHBOARD connection. I can connect and operate on VNC and noVNC but the dashboard is always showing connection failure after loading the initial structure of the site. I have confirmed port 3000 is LISTEN and can also use nc to connect to my IP and port 3000 with successful connection
EKOSLIVE also connects
SM phone app cannot find the unit on the network

Can you advise on the services required for this to operate (I known ekolive is one but perhaps there are others not started?) - are there any ways to test locally on the PI

Since all other parts are working I can only assume the site itself or the "server" is not running

Thanks in advance
J

Read More...

Trying to capture for you - after the initial faults I ran 17 hours straight shooting darks...no issues. at the end of that test I restarted and was killed 3 time on start up but had no logging on - running now under debugger and shooting - if it dies I will send along

Read More...

Hi Jasem - I have done a load of testing based on the release yesterday - basically a 24 hour load test. no longer crashes on load of devices but I did hit 3 segfaults after about 2 hours of running and shooting for each crash....in the last log I notices that message queueing was involved in the logs, so on a whim I ran without debugger and disabled ALL logging: since that point I have been running almost 12 hours shooting with both cameras and no crashes or issues!!!! I am fairly certain the race condition you nailed yesterday has a twin in the logging structure somewhere.

Read More...

JAMIE FLINN replied to the topic 'Kstars keeps crashing' in the forum. 5 months ago

Crash after about 1.5 hours of image gathering: - SM OS...RPI4 8Gig:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xafb86090 (LWP 6091)]
[New Thread 0xaa2d7090 (LWP 6092)]
[New Thread 0xa9360090 (LWP 6093)]
[New Thread 0xa735f090 (LWP 6094)]
[New Thread 0xa51ff090 (LWP 6095)]
[New Thread 0xa23f4090 (LWP 6096)]
[New Thread 0xa17da090 (LWP 6097)]
[New Thread 0xa0dff090 (LWP 6098)]
[New Thread 0xa05fe090 (LWP 6099)]
[New Thread 0x9fdfd090 (LWP 6100)]
[New Thread 0x9f5fc090 (LWP 6101)]
[New Thread 0x9ecb7090 (LWP 6102)]
[New Thread 0x9ccb6090 (LWP 6103)]
[Thread 0x9ccb6090 (LWP 6103) exited]
[Thread 0xa17da090 (LWP 6097) exited]
[Thread 0x9fdfd090 (LWP 6100) exited]
[Thread 0xa0dff090 (LWP 6098) exited]
[New Thread 0xa0dff090 (LWP 6116)]
[New Thread 0x9fdfd090 (LWP 6139)]
[New Thread 0xa17da090 (LWP 6141)]
[New Thread 0x9ccb6090 (LWP 6143)]
Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
0x00a44d9c in INDI::BaseDevice::messageQueue[abi:cxx11](int) const ()
#0 0x00a44d9c in INDI::BaseDevice::messageQueue[abi:cxx11](int) const ()
#1 0x006602b6 in INDI_D::updateMessageLog (this=0x2c3cfe8, idv=0xa99140a8, messageID=<optimized out>) at ./kstars/indi/indidevice.cpp:293
#2 0xb4b64c68 in QMetaCallEvent::placeMetaCall(QObject*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#3 0xb4b68bec in QObject::event(QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#4 0xb54a09c4 in QWidget::event(QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#5 0xb545ddb4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#6 0xb54662a8 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#7 0x02c3cfe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Read More...