Ron DeBry replied to the topic 'Touptek Camera SDK Major Update' in the forum. 2 days ago

Basically the same here - *except* I always use Low Noise Mode ON. I have never seen a reason to not use it.
I also run my heater at 4, because I had problems with frost forming on the sensor window. Mine is an early Risingcam, and I believe they may have improved the heater in newer versions.

I do fine at offset 300, but there's no harm in a bit higher, either.


Ron DeBry replied to the topic 'Sudden failure of Touptek driver' in the forum. 2 weeks ago

No one ever replied - which is understandable given that I now know what happened. I switched to using the Omegon Pro driver, which works fine. After updating to 3.6.9 I figured the toupcam driver for my installation should be repaired and had another try - with the same weird result.

But, when I checked the statistics in fits viewer (which I guess I had not done when it first showed up), I had separate R G and B stats. The problem, as it turns out, was that my toupcam driver had somehow set to RGB mode instead of RAW-16. How? Who knows. But it is fixed now.


Ron DeBry created a new topic ' Sudden failure of Touptek driver' in the forum. 2 months ago

Risingcam IMX571c camera
This is a weird one. I had not used my setup since mid-December. Today I was doing some indoors testing with ways to take flats. One of my test exposures failed to leave "Capturing". This is not (unfortunately) all that unusual. The driver eventually crashed, so I stopped and restarted KStars & Ekos. From then on, any exposure looks like:

Stopped and restarted a couple more times. Tried capturing a dark a flat and a light - all the same. Shut down all power and rebooted. Still the same. I have used the camera previously with the Omegon driver, so I loaded that profile. That works normally.

Updated all the software, including of course to the latest KStars main branch build. Still corrupted images with the toupcam driver.

Is it possible to replace just the touptek driver, in case the file itself somehow became corrupted?

I don't see anything too odd in the log from when the crash occurred.

File Attachment:

File Name: log_11-36-04.txt
File Size: 456 KB


(I assume you are using the newer Polar Align where the scope does not need to be pointing at the pole)

I usually start near the meridian and typically Declination 60° or so (but the declination is totally unimportant). I start near the meridian because the most important thing is that the polar align RA rotation must not *cross* the meridian (it seems to ignore all safety stops and will happily just keep going and crash the scope into the tripod). So if I happen to start on the east side, the rotation must be to the east and vice versa.

Sometimes there are clouds in one part of the sky, so I polar align on the other side. Some people might also have a tree or a building in the way on one side, so they need to be able to specify the other side.


Ron DeBry replied to the topic 'Omegon Pro / Touptek drivers' in the forum. 4 months ago

Thanks. I downloaded the file - I assume this requires building from source? Guess there's a first time for everything (not tonight, though - luckily I haven't disassembled the rig in a while and I have 3-week-old flats that still work).

Though I thought that a fix had been committed, so I was expecting it in the current nightly build.


Ron DeBry replied to the topic 'Omegon Pro / Touptek drivers' in the forum. 4 months ago

I loaded the nightly build today and still see an issue with flats and the touptek driver (Risingcam 571c camera):


Ron DeBry created a new topic ' Analyze tab - fixation of "focus"' in the forum. 5 months ago

"Focus" in quotes because I'm talking about the numbers displayed for, e.g., hfr and # of stars (the two I pay most attention to). When the session starts, the numbers update as each new frame comes in. But once I have clicked on any particular frame or focus run (whether intentionally or incidentally), the numbers remain focused on that specific frame or focus run.

Is there something to click to 'reset' the Analyze tab so it again always shows the values for the most recent frame?


The CEM40 has been through several iterations with respect to usb port locations. Note that everything is USB 2. The USB 2 Type B socket on the main housing is where your computer connects to the mount.

A major wrinkle is that CEM40s seem to not want to work directly connected to a Pi4 USB3 connector, so try with a USB2 hub in between. Not sure how the Pegasus device interacts, I have no experience with that.

The USB-A connectors on the saddle are from an internal hub. You can connect a camera to that and it will be connected to your computer through the main mount USB connection. In the newer models like yours, the iPolar also connects through the on-board hub and does not have a separate connector.


Update: My current theory is that there is firewall setting or configuration getting in the way.

With the mini-pc connected to my home network and the firewall active, VNCViewer works fine from either my laptop or desktop.
With the mini-pc running its hotspot and the firewall active, I cannot connect reliably. I have ports 5900, 5901 and 5902 open for tcp. Some times VNCViewer will connect and show the ubuntu desktop, but there is no mouse or keyboard control from the viewer.

So I can work around by disabling the firewall when I go out to remote image.


I've been googling away. Unfortunately my linux skills consist primarily of hoping it all works without much intervention...

It appears that ubuntu does not arrive with a DHCP server, so one must be installed separately. Apparently the most common is isc, though isc says it is no longer maintained and one should use kea. kea looks way more complicated to configure, but it that's what is need I shall have a go at it.

It is still a total mystery to me how it ever worked in the first place (and why it stopped working), if it is indeed true that there is no built-in DHCP service. I have searched through Rob Lancaster's astropi3 script for ubuntu (which I used for my installation), and find nothing about installing any of the DHCP servers or configuring DHCP.


Yes, we appear to be on the same page now.

The mini-pc is fully updated
I have tried both a laptop and a desktop windows pc, neither obtains an ip address, neither appear in the arp -a device list
I just created a new hotspot - same behavior


Hi Euripides, thanks for thinking about this.
This is correct. The ubuntu mini-pc uses its highest-priority wifi connection to connect to my home wifi network. It obtains an ip address, can access the outside world and I can use VNC Viewer to remote-control it by connecting to BEELINK::5901. No change here, this has always worked.
This is only partly correct. When I turn off my home wifi, ubuntu correctly creates a wifi hotspot according to its second-priority connection setting. On my windows laptop (and also on a windows desktop pc) I see the hotspot and can connect to it. The windows box says "Connected", but does not obtain an ip address from ubuntu. On the ubuntu machine, arp -a shows no connected devices.

Sorry for being unclear. There is no 3rd situation like this, only #1 and #2.



I am not very knowledgeable about networking, so I am easily stymied. I used Rob Lancaster's installation script for my Ubuntu mini-pc installation. At home Ubuntu connects to my wifi and I connect from windows using VNC Viewer.

Away from home, Ubuntu uses that same wifi to establish a hotspot. That works, and I can connect my laptop to the hotspot. However, I cannot get a VNC connection to work (have tried multiple viewers).

This all worked correctly last fall - same laptop, same mini-pc and I am obviously unsure what exactly changed in the interim. The windows laptop, when connected to the Beelink's wifi hotspot, does not have an IP address. I'm guessing this has something to do with the problem. How can I determine if Ubuntu is configured to act as DHCP server? "Connection Information" for the hotspot shows In the Settings for the hotspot, IPv4 Settings tab, all the fields are blank.

Thanks in advance for any pointers to the right direction.


Ron DeBry replied to the topic 'Scheduler endlessly recycles job' in the forum. 10 months ago

Certainly worth posting. Maybe also a screenshot of the scheduler tab.

My RC is sitting on the shelf for now, as I acquired a 130mm refractor. Haven't sold the RC yet, so I still want to keep up with how Ekos works for the wavefront collimation. (frac has a bit of a violet problem - not terrible, more like just enough to annoy me and keep me from selling the RC yet)