ok Max....that seems to make sense with what I'm experiencing. I was using the commands that Gonzo referenced (and which work for Ubuntu). Guess I'll need to wait for the next stable release to pick up what I want as I haven't worked through getting a PI4 development env running....

Read More...

Can someone post (or repost) the commands needed to update to/from the nightly and stable distros in Raspian/buster? It's been too long since I used nightly on the Pi4, and now the ubuntu commands don't seem to work for the Pi4 for the latest release(s). The apt-add-repository command for ppa:mutlaqja/indinightly complains that it can't find a distribution template for Raspian/buster. If someone can remind of the needed commands for Raspian/buster (SM OS), that would be appreciated. Thanks!

Read More...

Doug S replied to the topic 'HA and local Meridian' in the forum. 3 weeks ago

Not sure what kstars version you're running, but 3.5.0 (Beta) for Linux does not seem to exhibit any problem showing correct HA values in the position tab under details. I get positive values right of the meridian when facing south, and negative values left of the meridian when facing south. This is proper/expected behavior when using +/- 12 hour HA values (as opposed to 0-24 hour values). Cheers, Doug

Read More...

It is possible that your temperature sensor isn't fully supported yet (driver). Your earlier posted logs may be picking up the temperature via the weather temperature reading (which was added to the focus module to support focus analysis logging). The change did not get factored into the delta-T code update as I recall. This might explain your logs saying that there's no focuser temperature sensor.

See this post for a bit more background (note that the code was changed after the post...so the log outputs are a bit different now).
www.indilib.org/forum/ekos/6901-how-does...erature.html?start=0

Read More...

Doug S replied to the topic 'Can't get into focus anymore' in the forum. 1 month ago

Hi Jerry, On first glance, your HFR values are outrageously large. I think all the algorithms struggle with donuts (i.e. focus so far out that it's hard to tell what direction to go). I would recommend a manual search (first time is always the hardest) through the focus range, watching how HFR changes. When you finally find a good starting point, then run the algorithm (which ever you use, but I recommend linear) again. I wouldn't consider running the algorithm at all until you get inside of HFR=3 or better. You could have a HW problem, but the SW will not like those HFR values....

Read More...

The OP started this chase with a memory crash. If you now think this is a USB3 issue, please see this post on RF interference (2.4Ghz wireless only):
www.indilib.org/forum/general/6576-pi4-u...erference.html#59667

Read More...

ok, we're getting to a different topic from the crash, but here's a tip about PHD2. Assuming your PHD2 profile is setup correctly, then start the PHD2 app but DON'T connect. Just bring up PHD2 on the desktop. Then, assuming your Ekos profile is correct for PHD2, go into the guide tab and push the connect button. That should connect Ekos to PHD2, and PHD2 to the mount and camera. Sometimes the state machine between the two (Ekos & PHD2) can get confused. If this happens, just disconnect from the Ekos side, and reconnect again via the guide tab connect button. Once you are connected, it should stay connected. IMO, you probably should get into the habit of disconnecting and reconnecting from the Ekos guide tab (not the PHD2 side) if you don't already. I've seen it work fine connecting from PHD2 to Ekos, but I experience more problems with interface states when done that way.

Read More...

Just to be clear....Don't use the package updater app on the desktop (doesn't work). Use this command in a terminal instead:

sudo apt-get update && sudo apt-get -y dist-upgrade

If running this command brings a bunch of packages, it might be advisable to reboot the PI before running your test.....

Read More...

After you run your tests, if you are still experiencing the crash, I recommend creating a support ticket on the SM OS site. Jasem will respond and help to resolve. Having the full logs will be helpful. Good luck, Doug

Read More...

Didn't mean to suggest that your issue is power related....it was a side note about long term stability. Looking at the log, it seems clear that a memory stomp is occurring, and it's bad enough to corrupt the stack. It's not clear whether memory has been exhausted, or it's just a memory bug that your configuration/setup has tickled. If you are getting 70 subs, what about trying a test where you setup for 2 sets of 50 subs. Does that run clean? If it does, it will give a hint that memory exhaustion is occurring. You probably should plan to have a terminal window up as you're running, and run the memory free command a few times as the job is running to see how memory is being consumed. That will give you a good clue as to what's going on. I would do this for both tests (2x50, and the 70 crash). You want to catch this just prior to the crash in the 2nd case, and then after the crash. The output will be along the lines of:

$ free -h
total used free shared buff/cache available
Mem: 3.5Gi 654Mi 2.0Gi 170Mi 921Mi 2.7Gi
Swap: 2.0Gi 0B 2.0Gi

Read More...

A couple of thoughts: Are you running the most up-to-date distro of SM OS? If not, I would say that it's definitely advisable to update. If you are running an older SM OS distro, are you allowing the FITSviewer to pop-up? If so, it could be a possible culprit (only for older releases). I used to experience crashes with older releases, but find the newest release remarkably stable (especially now that fitsviewer issues have been addressed).

A couple of probably unrelated thoughts, but things to consider for more reliable service long term. You want to be sure your power bank is providing enough juice to the Pi4. Spec is 3amps @5V. If you're sharing power from 1 bank to 3 devices, you should make sure that full spec power for all devices is capable of being delivered (even though nominal draw after boot will be less). Generally, I wouldn't trust the PI4's USB ports to power devices. Theoretically, yes, but practically and reliably, no. Ideally, you should consider a powered USB3 hub. Cheers, Doug

Read More...

I agree with Wouter that balance in both axes should be the goal. I can't fully see your dovetail gear setup, but I'm left wondering whether you could re-distribute and/or dead-weight the dovetail a bit more to achieve balance. The dovetail itself seems symmetric enough; how far out of balance do you think you are in DEC? You don't seem to be carrying that much weight; I would think you still have plenty of headroom to adjust. About the calibration steps, besides the cal plot, you can look in the guidelog (can't remember if you need to enable verbose & file mode or not). The calibration section of the log will show the step size magnitudes. I use PHD, but the internal guider has a similar plot/log



Read More...