In the past, some functions returned a pointer to an object, which could later refer to a nonexistent object.
Currently, BaseDevice has a built-in shared pointer that eliminates this problem.
To maintain backward compatibility, BaseDevice has the operator-> which is used by various code snippets. BaseDevice and Property/PropertyXXX should be passed as values, not as pointers.
The "->" operator will be marked as deprecated in future versions of the library.
The example below follows the latest trends.
void IndiClient::newDevice(INDI::BaseDevice baseDevice)
{
IDLog("New Device: %s\n", baseDevice.getDeviceName());
auto interface = baseDevice.getDriverInterface();
if (interface & BaseDevice::TELESCOPE_INTERFACE)
{
IDLog("New Telescope: %s\n", baseDevice.getDeviceName());
}
}Read More...
With high probability, I can say that indi_gphoto_ccd was recompiled for an older version of the library. Using a new library requires recompiling programs that use it.
Read More...
Hi!
Actively browsing the sources, I know that for some time, the mechanism of local connection via a file (AF_UNIX) has been introduced to the `INDI Core Library`.
This may explain why a reboot helps. Please note the /tmp/indiserver and other /tmp/indi* files.
Read More...
Ah yes, I get it. I am currently using a powerful laptop to record videos at full bandwidth.
I have not found a simple solution to additionally be able to control from a smartphone without using the Internet.
From what I remember Ekos Live connects to the server, but does not create the server itself, although now I can see several different projects 
Thanks for the quick answer, I understand that many implementations of similar solutions are also troublesome to maintain.
Read More...
Hi Jasem, Hi everyone!
Today I want to share my idea with you and know if it will be useful to you.
Who needs it for?
Sometimes when observing, especially without the use of a camera, it is necessary to move the mount slightly or to improve the sharpness using, for example, the
Bahtinov mask
.
This is where the control becomes problematic when the eyesight is directed to the eyepiece lens.
In Ekos, you can use, for example, "Mount Control", but looking through the eyepiece, it is difficult to manipulate the mouse on the screen and hit the appropriate button.
Solution:
The idea is a wireless / wired handheld controller that could be a smartphone.
The application is a simple website using Vue.Js 3.0 that can be hosted anywhere.
Following the Plug & Play principle, I put a simple web server in the KStars project itself on port 1080, which displays this page.
Locally (you can test quickly):
Open a browser and go to http://localhost:1080 on the same device as running KStars with the "ManagerWebSocket" branch.
Wirelessly:
On a remote device that is on the same network as the computer and KStars, type http://<ADDRESS_IP_KSTARS>:1080/ in the browser.
Wired:
Connect your phone via USB to the computer with KStars and select USB Tethering in your phone's settings.
Now you can access the website by typing http://<ADRES_IP_KSTAR>:1080/ in your browser
How it works?
On port 1081, communication takes place via the WebSocket protocol using the Json format.
The appropriate Json structure specifying the module, function, and arguments is sent to port 1081, then the function is searched for and executed.
If the function returns a type, it is returned in the same structure.
For example, if we want to call a function:
// Adjust focuser offset, relative or absolute
void adjustFocusOffset(int value, bool useAbsoluteOffset);{
ekos: {
focus: {
adjustFocusOffset: [100, false]
}
}
}Modules are upgradeable over time, currently "mount" and "focus" are used.
See kstars/ekos/managerwebsocket.cpp
/* ... */
auto args = QJsonDocument::fromJson(message.toLatin1()).toVariant().toMap()["ekos"].toMap();
if (args.count() == 0)
return;
QVariantMap result;
s_invokeModule(m_manager->mountModule(), "mount", args, result); // mount
s_invokeModule(m_manager->focusModule(), "focus", args, result); // focus
/* ... */
if (!result.isEmpty())
{
QVariantMap resultMap;
resultMap["ekos"] = result;
client->sendTextMessage(QJsonDocument::fromVariant(resultMap).toJson());
}
/* ... */What do you think about it?
The code is written, I decided to clean it today and share it.
I personally use it. If you like it and you have any suggestions on what I can improve, I can take care of it.
Branch:
KStars feature/ManagerWebSocket
Read More...
256MB should be enough. However, for testing, it's worth increasing if you hear that they've been doing something with buffers.
Please confirm that everything is fine for the newest INDI / INDI-3rdParty builds with the old library.
LD_PRELOAD=/path_to_library/libASICamera2.so.1.16 indiserver indi_asi_ccdRead More...
Yes, I mean 1.17.
I am not getting detailed information from ZWO, I am trying to establish cooperation with them. I am working on the libASICamera2Boost library. Unfortunately, each camera has a different implementation and it's hard for me to keep developing without the original library source.
In original library (1.17), there are probably larger double buffers used for communication with the camera.
The usbfs_memory_mb value should be at least '6 x Resolution'. For now, these are guesses, I need to analyze the library more.
Anyway, to rule out a memory problem, I suggest temporarily increasing the usbfs_memory_mb value and testing indi with different ZWO libraries.
For example:
sudo sh -c 'echo 512 > /sys/module/usbcore/parameters/usbfs_memory_mb'
# test for biggest camera
# sudo sh -c 'echo 1024 > /sys/module/usbcore/parameters/usbfs_memory_mb'
# Test different versions of the ZWO library.
LD_PRELOAD=/path_to_library/libASICamera2.so.1.16 indiserver indi_asi_ccd
LD_PRELOAD=/path_to_library/libASICamera2.so.1.17 indiserver indi_asi_ccdRead More...
In the latest SDK, the problem with damaged frames during long exposure is fixed.
Probably it required more library modification and maybe something got corrupted.
I still offer cooperation for ZWO, unfortunately without success.
Read More...