wotalota replied to the topic 'Driver development question' in the forum. 5 days ago

Ed,
rolloff simulator does not actually use an external device, it provides the framework and simulates the action of opening and closing. I have a driver developed from the simulator that might proved a starting point for you to use.
github.com/wotalota/indi-rolloffino
There is a html sub-directory that provides and overview if you copy that to a local directory. It works via an Arduino controller, various versions of which are provide.
If you were thinking of directly using Raspberry Pi GPIO connections I have one that does that using pigpio but it is not yet fully debugged, it still has a timing issue at startup.
/Tom

Read More...

wotalota replied to the topic 'Connectivity Issues Nikon DSLR' in the forum. 2 weeks ago

With the variability of your symptoms and thinking that the Nikon might be sensitive to power supply issues suggest it could be power related. Might be worth ensuring your 12V supply is not overloaded. Using a Nikon AC adapter would resolve the question either way.

Read More...

wotalota replied to the topic 'Connectivity Issues Nikon DSLR' in the forum. 2 weeks ago

I had problems when trying to power Nikon via a Pegasus power box. Using the original Nikon plug-in adapter cleared things up.

Read More...

Helmut,
If the RockPi4c board uses a Broadcom SoC, search to see if pigpio has its own forum or ask in the Raspberry Pi forum. Otherwise there seems to be little prospect of being able to use pigpio with the RockPi4c.
Tom

Read More...

Helmut,
If I am looking at the right thing, 3rdparty/indi-asi-power overview indicates it is using the pigpio interface to access the GPIO pins. pigpio normally runs as a daemon process. To confirm it is installed and running try the command: "systemctl status pigpiod". Could also check the KStars log for pgpiod startup error message about not able to find or initialize the library.
/Tom

Read More...

I was curious about that too, looked at it for the AP driver:
There is _one_ binary installed, lx200generic, for all LX200 drivers.
The variant's binaries (including ap_experimental) are links to that one indi_lx200generic.
When the requested driver image invokes the linked indi_LX200_generic executable the original
specific driver name is passed in. The main function will fetch from std args the binary name
and In lx200Generic:ISInit() it creates a new instance of LX200AstroPhysicsExperimental.
The implementation is running within the generic binary.

For example:

else if (strstr(me, "indi_lx200ap_experimental"))
{
IDLog("initializing from Astrophysics Experimental device...\n");

if (telescope.get() == nullptr)
telescope.reset(new LX200AstroPhysicsExperimental());
}
\

INDI::BaseDevice
^
INDI::DefaultDevice
^
Telescope GuiderInterface (libs/indibase/inditelescope.h / libs/indibase/indiguiderinterface.h)
^ ^
LX200Telescope includes lx200driver (getCommandSexa etc) in generic and library?
^
LX200Generic
^
LX200AstroPhysicsExperimental includes lx200ap_experimentaldriver

Read More...

I noticed a problem with my rolloffino driver when using the Observatory Unpark button. I would like to ask a developer if the following is really an issue or am I looking in the wrong version/places. It appears that Observatory and Dome drivers might be directed to different definitions.

KStars: kstars/indi/indidome.h

typedef enum
{
DOME_IDLE,
DOME_MOVING_CW,
DOME_MOVING_CCW,
DOME_TRACKING,
DOME_PARKING,
DOME_UNPARKING,
DOME_PARKED,
DOME_ERROR
} Status;

INDI: libs/indibase/indidome.h

typedef enum
{
DOME_IDLE, /*!< Dome is idle */
DOME_MOVING, /*!< Dome is in motion */
DOME_SYNCED, /*!< Dome is synced */
DOME_PARKING, /*!< Dome is parking */
DOME_UNPARKING, /*!< Dome is unparking */
DOME_PARKED, /*!< Dome is parked */
DOME_UNPARKED, /*!< Dome is unparked */
DOME_UNKNOWN, /*!< Dome state is known */
DOME_ERROR, /*!< Dome has errors */
} DomeState;

Read More...

Just a heads up. I took the option of upgrading an Odroid being used for weather monitoring to ubuntu 22.04.
Lost use of Vantage weather station and local sensors using usb connections via the rules.d interface. Seems to have been solved by removing /lib/udev/rules.d/85-brltty.rules which was conflicting.
/Tom

Read More...

More thought.

Even though the Rolloffino does not call for INDI builds is does clone the source files needed for 3rdparty build into a development area.
It would be better/safer if you used another Raspberry Pi as a development machine. Then you know the only two files introduced onto the Stellarmate are the ones you place there.

Read More...

Gord,
You do need to build on a Raspberry Pi.
I have not tested with Stellarmate only with KStars/Ekos and ubuntu running on a Raspberry Pi.
Follow the Rolloffino INSTALL directions and run the build on a Raspberry Pi. It will create the files listed at the end of the directions.

- /usr/bin/indi_rolloffino The driver executable
- /usr/share/indi/indi_rolloffino.xml Identifying the roof driver to Ekos.

If you do the build on Stellarmate it will attempt to write them directly. If you built elsewhere on some other Raspberry Pi they would need to be copied to the Stellarmate machine.
So it is not the kind of install that will be modifying libraries and such, adding a couple of files should not harm anything. If in Stellarmate's Ekos profiler you do not see Rolloffino added as an option under Domes, it indicate the above .xml file did not get to the correct place.

Anyone know if there is a problem with these assumptions??

Read More...

wotalota replied to the topic 'Crash when taking image' in the forum. 4 months ago

Run with all devices listed in the Ekos profile..
The 11-37-17 logs: On startup it indicated indi drivers were already running, Selected the restart them option.
Auto connect worked except for the FP1 flipflat. Pushed its INDI connect button and that is when it crashed.

The 11-53-28 logs: Manually killed the still running drivers and ran the test again.
All devices connected. Went to the Ekos camera tab. Add a 3 second exposure and a count of 5, then run.
Seemed to complete one image then crash. The drivers left running shown below include the fp1, a ccd driver is missing.

tg@astro:temp$ ps -ef|grep indi
tg 40951 1 0 11:53 pts/0 00:00:00 /usr/bin/indiserver -v -p 7624 -m 1024 -r 0 -f /tmp/indififoa1974ea0
tg 40952 40951 0 11:53 pts/0 00:00:00 indi_lx200ap_v2
tg 40953 40951 0 11:53 pts/0 00:00:02 indi_asi_ccd
tg 40954 40951 0 11:53 pts/0 00:00:00 indi_asi_wheel
tg 40955 40951 0 11:53 pts/0 00:00:00 indi_deepskydad_af3_focus
tg 40956 40951 0 11:53 pts/0 00:00:00 indi_rolloffino
tg 40957 40951 0 11:53 pts/0 00:00:00 indi_weather_safety_proxy
tg 40958 40951 0 11:53 pts/0 00:00:00 indi_watchdog
tg 40961 40951 0 11:53 pts/0 00:00:00 indi_pegasus_ppba
tg 40963 40951 0 11:53 pts/0 00:00:00 indi_deepskydad_fp1
tg 40964 40951 0 11:53 pts/0 00:00:00 indi_astrometry
tg 41249 21094 0 12:00 pts/2 00:00:00 grep --color=auto indi
tg@astro:temp$

Read More...