Requesting help with Alnitak Remote Dust Cover device properties #55090
I'm sorry, I'm still fairly new to linux, and I'm still in the process of learning to use it proficiently (have to start somewhere). Your previous reply is confusing to me. Isn't the Product ID just the second part of the pair of values returned by lsusb? So the PID of our dust cover would be 6003 if that's the case. I've also never used minicom before (I actually never heard of it until you mentioned it in your comment) so I'll have to learn to use it before replying with the product ID. Again, sorry that I'm such a novice.
Requesting help with Alnitak Remote Dust Cover device properties #55107
No this is like model id returned by the device itself, it's not related to libusb. The libusb VID:PID are just generic FTDI chipsets IDs and not related to the actual device internally. So you either need to enable verbose logging before you connect and then check to see what the response is, or use minicom and type that command directly to get the response. Once I know the response, I can modify the driver to take that into consideration.
Requesting help with Alnitak Remote Dust Cover device properties #55165
Does this help?
[ 4.837184] usb 1-1.1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 4.845963] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.853574] usb 1-1.1.3: Product: Flat Fielder
[ 4.858086] usb 1-1.1.3: Manufacturer: Optec Inc.
[ 4.862859] usb 1-1.1.3: SerialNumber: A844DJ8W
Requesting help with Alnitak Remote Dust Cover device properties #55170
So I have been trying to get the product ID with the >P000 command you mentioned earlier. I have been looking for references to the >P000 command, and how to use it, but I haven't found any documentation anywhere. Is there a place where there are more detailed instructions on these commands or how to use them? I've found that it's easy to enable verbose logging when I run the indiserver (using -vvv) but when it's running there doesn't seem to be a way to issue commands to it from the command line, because the command line won't take arguments until the indiserver is stopped. Again, we aren't using Ekos due to the nature of our client. We have not tried to use minicom so that may be why we are still stuck. Using minicom also seems strange to me because it is used as a serial port communications program but our devices are connected by serial bus, not serial ports. Our dust cover is connected by USB to the CCD we are using, which in turn is connected by USB to the raspberry pi where our client and indiserver are running. Would either of those details make a difference when using minicom? Thanks.
Requesting help with Alnitak Remote Dust Cover device properties #55196
AFAIK, Alnitak uses a USB to serial chipset like all their other products so it gets assigned a serial port. You have two options:
1. Enable verbose logging in Ekos (check my signature) for Auxiliary devices and then read from the log the response to >P000 command.
2. Use minicom and execute the command there directly and read the output.
Requesting help with Alnitak Remote Dust Cover device properties #55384
Hello again Jasem,
I did git pull from the indi repo and tested by running $ indiserver indi_flipflat
This time around, the output from my flask app shows this:
List of Device Properties:
TEXT:DRIVER_NAME(Name)= Flip Flat
NUMBER:PERIOD_MS(Period (ms))= 1000.0
SWITCH:Scan Ports(Scan Ports)= Off
TEXT:ACTIVE_FILTER(Filter)= Filter Simulator
Note that the flat light property from before is not shown, which stands to reason, but there are no properties relating to the dust cap itself.
Requesting help with Alnitak Remote Dust Cover device properties #55451
The dust cover is, and has been, connected via usb to the raspberry pi this whole time. I do see what you mean that the connection switch is off. Ill do some more playing around with it and get back to you.
Requesting help with Alnitak Remote Dust Cover device properties #55456
Well Jasem, I finally got everything working. It turns out in my script the list of properties was being printed out before the connection to the indiserver was established - a simple mistake on my part. I added some time.sleep calls to wait before printing the properties, and lo and behold, the CAP_PARK property is there. The updated driver works perfectly when changing the CAP_PARK switch as well.
I'm sure I was a real nuisance to deal with, so I apologize. I really do appreciate all of your help though! Thanks for everything!