My personal experience was that BT is even more unreliable than Wifi connections but it could also be just delusionHelgeMK wrote: Hm..does it mean that the BT connection is not good enough to support guiding?
Ok, thanks, I will try to keep the error below 2' or so. My exposures are usually currently not above 120 secs and my focal length is 547mm, so no very big magnification.
Read More...
Hi
I just wondering what are your best results with EKOS Polar Alignment Assistant, and what results do you think are sufficient for a good session?
I had a previous session where I was able to get down to 20'' (8x50 guide scope, ASI174MM Mini), but my last session was ~5'. What is your limit where you would re-do an alignment?
Read More...
cheer!
must have missed that in my fork.was removed on August 17th 2017
So far ... it seems to work, in my opinion you can close the issue on github.
Just some things in your code I want to mention :
- maybe change NULL to nullptr?
- maybe change from -std=c++0x to c++11?
indi_wiringpi_gpio
- I always have to add this crypt flag to CmakeLists.txt
(
github.com/magnue/indi_wiringpi_gpio/iss...suecomment-379486642
)
indi_servoblaster_cap
- you should check to include <cstring> as I get compiler errors without it (gcc-6.x)
- I had to remove the code in "ServoBlasterCap::EnableLightBox" that checks if cap is parked.
I cannot activate the light of my flatfield-dustcover if closed but I have to, to make flats, maybe you can implement
some kind of checkbox to disable this check.
- maybe enable issues page on github for that repo so than I can bother you with my problems there
Read More...
I maybe made a bit of progress.
This "Uninitialised value was created by a heap allocation" (wiringpi_gpio.cpp) seems to be related to the part
in the updateProperties() function where you test for NULL:
if (InputDigitalLP[i]->lp != NULL)
defineLight(InputDigitalLP[i]);
if (OutputDigitalSP[i]->sp != NULL)
defineSwitch(OutputDigitalSP[i]);
WiringPiGPIO::WiringPiGPIO()
{
for (int i = 0; i < NUMBER_OF_PINS; i++)
{
InputDigitalLP[i] = new ILightVectorProperty;
OutputDigitalSP[i] = new ISwitchVectorProperty;
// added
InputDigitalLP[i]->lp = NULL;
OutputDigitalSP[i]->sp = NULL;
//
}
OutputPWMNP = new INumberVectorProperty;
setVersion(0,1);
setDriverInterface(AUX_INTERFACE);
}
Ok, thanks Magnus_e.
In the meantime just out of curiosity and for personal pleasure I am playing with valgrind and it found some issues:
#valgrind --leak-check=full --show-leak-kinds=all --trace-children=yes --track-origins=yes indiserver indi_wiringpi_gpio
...
2018-04-10T07:36:51: Driver indi_wiringpi_gpio: ==4988== Conditional jump or move depends on uninitialised value(s)
2018-04-10T07:36:51: Driver indi_wiringpi_gpio: ==4988== Uninitialised value was created by a heap allocation
2018-04-10T07:36:53: Driver indi_wiringpi_gpio: ==4988== Invalid read of size 8
Ok, with 2017-07-05-raspbian-jessie.img (gcc-4.9.2) indi_wiringPi_gpio works.
Magnus_e I bet if you update your gcc or use any recent distro for Raspberry I am sure it will
crash on your system too.
It seems something changed from gcc-4.9.x to gcc-?? that made your driver unusable.
If I stay on gcc-4.9.2 (jessie) I think it will be only a matter of time until something indi related requires >gcc-4.9.x
and I will be back at this issue.
I think the issue has nothing to do with the systeminfo tabs, I removed that code completely but the issue persists.
It must be something in wiringpi_gpio.cpp.
I will try to take a look at valgrind, maybe I can get a hint where the problem originates from but I currently only get some kind of restarting loop if I try it with:
valgrind --trace-children=yes indiserver -v indi_simulator_telescope indi_simulator_ccd indi_wiringpi_gpio