Actually, I've just discovered the Auto-debayer flag under Camera&FilterWheel>Options>FITS>Auto-debayer.

Tx.

Read More...

I have this same problem with the DSI III pro (ie monochrome) on Kubuntu 20.04. Will this same fix work for that too, and how should I install it?

Tx

Steve.

Read More...

Steve replied to the topic 'PyIndi without IndiClient class' in the forum. 4 years ago

Hi Stefan,

Sorry for the delay, my computer broke and I had to buy a new monitor.

I'm sure you saw this:

#!/usr/bin/env python

# for logging
import sys
import time
import logging
# import the PyIndi module
import PyIndi

# Fancy printing of INDI states
# Note that all INDI constants are accessible from the module as PyIndi.CONSTANTNAME
def strISState(s):
    if (s == PyIndi.ISS_OFF):
        return "Off"
    else:
        return "On"
def strIPState(s):
    if (s == PyIndi.IPS_IDLE):
        return "Idle"
    elif (s == PyIndi.IPS_OK):
        return "Ok"
    elif (s == PyIndi.IPS_BUSY):
        return "Busy"
    elif (s == PyIndi.IPS_ALERT):
        return "Alert"

# The IndiClient class which inherits from the module PyIndi.BaseClient class
# It should implement all the new* pure virtual functions.
class IndiClient(PyIndi.BaseClient):
    def __init__(self):
        super(IndiClient, self).__init__()
        self.logger = logging.getLogger('IndiClient')
        self.logger.info('creating an instance of IndiClient')
    def newDevice(self, d):
        self.logger.info("new device " + d.getDeviceName())
    def newProperty(self, p):
        self.logger.info("new property "+ p.getName() + " for device "+ p.getDeviceName())
    def removeProperty(self, p):
        self.logger.info("remove property "+ p.getName() + " for device "+ p.getDeviceName())
    def newBLOB(self, bp):
        self.logger.info("new BLOB "+ bp.name.decode())
    def newSwitch(self, svp):
        self.logger.info ("new Switch "+ svp.name.decode() + " for device "+ svp.device.decode())
    def newNumber(self, nvp):
        self.logger.info("new Number "+ nvp.name.decode() + " for device "+ nvp.device.decode())
    def newText(self, tvp):
        self.logger.info("new Text "+ tvp.name.decode() + " for device "+ tvp.device.decode())
    def newLight(self, lvp):
        self.logger.info("new Light "+ lvp.name.decode() + " for device "+ lvp.device.decode())
    def newMessage(self, d, m):
        self.logger.info("new Message "+ d.messageQueue(m).decode())
    def serverConnected(self):
        self.logger.info("Server connected ("+self.getHost()+":"+str(self.getPort())+")")
    def serverDisconnected(self, code):
        self.logger.info("Server disconnected (exit code = "+str(code)+","+str(self.getHost())+":"+str(self.getPort())+")")

logging.basicConfig(format='%(asctime)s %(message)s', level=logging.INFO)

# Create an instance of the IndiClient class and initialize its host/port members
indiclient=IndiClient()
indiclient.setServer("192.168.1.105",7624)

# Connect to server
print("Connecting and waiting 1 sec")
if (not(indiclient.connectServer())):
     print("No indiserver running on "+indiclient.getHost()+":"+str(indiclient.getPort())+" - Try to run")
     print("  indiserver indi_simulator_telescope indi_simulator_ccd")
     sys.exit(1)
time.sleep(1)

# Print list of devices. The list is obtained from the wrapper function getDevices as indiclient is an instance
# of PyIndi.BaseClient and the original C++ array is mapped to a Python List. Each device in this list is an
# instance of PyIndi.BaseDevice, so we use getDeviceName to print its actual name.
print("List of devices")
dl=indiclient.getDevices()
for dev in dl:
    print(dev.getDeviceName())

# Print all properties and their associated values.
print("List of Device Properties")
devices={}
for d in dl:
    print("-- "+d.getDeviceName())
    devices[d.getDeviceName()]={}
    lp=d.getProperties()
    for p in lp:
        print("   > "+p.getName())
        devices[d.getDeviceName()][p.getName()]={}
        if p.getType()==PyIndi.INDI_TEXT:
            tpy=p.getText()
            for t in tpy:
                devices[d.getDeviceName()][p.getName()][t.name]=[t.label, p.getType(), t.text]
                print("T       "+t.name+"("+t.label+")= "+t.text)
        elif p.getType()==PyIndi.INDI_NUMBER:
            tpy=p.getNumber()
            for t in tpy:
                devices[d.getDeviceName()][p.getName()][t.name]=[t.label, p.getType(), str(t.value)]
                print("N       "+t.name+"("+t.label+")= "+str(t.value))
        elif p.getType()==PyIndi.INDI_SWITCH:
            tpy=p.getSwitch()
            for t in tpy:
                devices[d.getDeviceName()][p.getName()][t.name]=[t.label, p.getType(), strISState(t.s)]
                print("S       "+t.name+"("+t.label+")= "+strISState(t.s))
        elif p.getType()==PyIndi.INDI_LIGHT:
            tpy=p.getLight()
            for t in tpy:
                devices[d.getDeviceName()][p.getName()][t.name]=[t.label, p.getType(), strIPState(t.s)]
                print("L       "+t.name+"("+t.label+")= "+strIPState(t.s))
        elif p.getType()==PyIndi.INDI_BLOB:
            tpy=p.getBLOB()
            for t in tpy:
                devices[d.getDeviceName()][p.getName()][t.name]=[t.label, p.getType(), str(t.size)
                                                                 ]
                print("B       "+t.name+"("+t.label+")= <blob "+str(t.size)+" bytes>")
print(devices)
# Disconnect from the indiserver
print("Disconnecting")
indiclient.disconnectServer()

This is what I use and it works fine.

Regards

Steve.

Read More...

Steve replied to the topic 'PyIndi without IndiClient class' in the forum. 4 years ago

What difference does it make? I imagine they both work. The first one is more Pythonic and in the longer term you will find it easier to maintain.

If you write procedural code, like your second example eventually it will become more spaghetti-like and you split it into classes to maintain it. Much easier to start with classes.

Sorry to lecture you.

Regards,

Steve.

Read More...

Finally, the following command had no effect:

<code>
indi_setprop "SynScan.EQUATORIAL_EOD_COORD.RA;DEC=10;80"
</code>

Read More...

Hi People,

I've just done a new INDI install on a newly installed RPi3b+ with up-to-date Raspbian connected to a SynScan mount via the handset cable. I also upgraded the Handset to 39.xx. I then installed PyIndi-Client and wrote a quick microservice to call from my custom app.

Broadly things work. As I have said many times, INDI is a tremendous labour of love and I want to make it work. Here is a list of my tests:

1) Indi connection:
- the little server app works and starts the correct profile with SynScan and CCD simulator.
- It can be remotely managed from a webpage on my PC with http://192.168.1.105:8624/.
- Ekos on my PC connects to it and shows the right devices.
- PyIndi connects and shows the right devices.
- If I disconnect and reconnect in Ekos, it says /dev/ttyUSB1 already in use by another process and I have to reboot the RPi.
2) SynScan tests.
- SynScan connection works. When SynScan powered down, INDI times out and reconnects when powered up.
- GEOGRAPHIC coordinates broadly work, although at some stage the altitude switches from 88m to 127m

> GEOGRAPHIC_COORD
       LAT(Lat (dd:mm:ss))= 50.8672
       LONG(Lon (dd:mm:ss))= 359.663
       ELEV(Elevation (m))= 127.1

I haven't chased this down any further. The error shows on Ekos and the handset.
- Set time works, get time does not. The clock on Indi does not update, although the handset is correct. Ekos and the control panel show the wrong time always, apart from the second the time is set.
- Tracking broadly works. There are some random issues, for instance I have encountered situations where the mount is tracking, but the displays (on the handset, on ekos and in PyIndi-Client are all updating wrongly. I can't repeat this, sometimes it does it, sometimes not. It doen't cause a problem because of the next issue.
- Sync almost never works, and this is my main problem. It almost never works with Ekos, it never works with PyIndi-Client.
- Move NS or EW works everywhere. Change slew rate works everywhere.

So, in summary, if I can't sync, I can't share coords with PHD2, and that is my main requirement. It means I have to manually enter the DEC in PHD2 and use the ST4 port on the camera for guiding.

But apart from that, it works, and it's usable and it's neater than the solution I had before.

If I can help, please shout.

Regards

Steve.

Read More...

Steve replied to the topic 'Canon EOS400D not connecting to PC' in the forum. 4 years ago

Hi,

I have old cameras that connect to Linux, like the Canon 350d (older than the 400D) and also a NIkon D5000. I'm sure it's something simple like:

- dodgy cable,
- flat battery,
- etc.

The PMP setting shouldn't make any difference. Maybe it could get locked if you have automount on, but lsusb should still work.

Does it work at all, even without a USB cable?

try dmesg and see if there are any helpful messages.

Sorry.

Regards

Steve.

Read More...

Hi Guys,

Well this is a very one-side conversation. Here is my update so far. I have rebuilt my RPi3b+ several times with:

Ubuntu-Mate 20.04 64bit: very slow, almost unusable.
Ubuntu-Mate 20.04 32bit: still very slow, didn't continue.
I didn't try the 18.04, maybe that would have been OK.
Raspbian (most recent release mid-2020): Seemed fastere.

installed rlancaste github installation for Rpi3. Very slow and hung several times. Changed compiler flags from -j (.... -2) to -j(....-1) and then -j(.... -0). The compile finally completed with one error on weather.cpp. I didn't worry so much.

The issue with -j (which is the number of processors to use) was caused by memory utilisation. Even running at 25% CPU utilisation, memory utilisation was 70% at times. Obviously more processors pushed it even higher.

KStars, PHP and Indi seemed to install OK and I can detect hardware and loop photos, which I couldn't before. The RPi3b, seems a little under-powered, but the big lesson was I needed to upgrade Raspbian before I could install KStars/Indi etc. I should probably also buy an RPi 4. But the RPi 3b+ is still good enough. A 240 sec exposure will always take 240 secs, and a faster processor won't change that.

Good luck to anyone reading,

Regards

Steve.

Read More...

Steve shared a photo. 4 years ago

Steve has liked an Album 4 years ago