pask replied to the topic 'New Driver: Pegasus UPB' in the forum. 1 month ago

Hello Jasem, all indilib contributors & users !

I am just seeing this post and another older discussion on that UPB driver, and I have a little question :
The driver looks very fine and I have some friends using it.
The previous product of this company was "Intelli Power Box" which has almost same features and a very similar software is existing (for Windows and Android, but not on linux)
I am unfortunately the owner of one of this "older" box (which work very fine). The main difference is a connection thourgh BlueTooth rather than USB.
I sucessfully connect the device in bluetooth and get it as a "virtual" serial port (rfcomm1 for example).

Seems the UPB driver (ultimate Power Box) crashes when i try to connect it (i would suppose due to the fact it is awaiting a USB connexion and not a serial ?)
Do you know it would be easily possible to use that driver in a different way to connect to the serial port of that box ?

I am sure many users of IPB would be interested to make it work as the UPB.. and if i can help in some ways i would be happy

Best regards,
Pask

Read More...

Hello,
I did add the nightly repository of indi.
i did an apt-get update
then i checked indiserver version (still 1.7.2)

started kstars etc.. once connected to the camera, there were no change on the indi control panel of the 20D.
i tried to shoot, still photo on the CF mem card ...
(maybe i did a mistake ?)

Pask

Read More...

Thanks Jasem !!

Yes it stays in the camera mem card after indi gets it.
I will ask in parallel if there's a reason for the widget "capture target"

let's try the latest build, thanks !
Pask

Read More...

Dear All,

I was trying to install my pi3 box for astro with a 5D3 prior to switch to an old 20D due to some issues on the 5D3 (other topic open on gphoto2 GIT), anyway :

On the indi control panel now connecting the 20D, i don't see the option to write the file on the camera RAM or SD card (which is a CF btw), neither i see the option to keep the picture on the camera or to automatically delete it. (as i don't have big CF card i can use on that camera, i will be limited if i need to stop from time to time the sequence to delete manually the file on the camera)

Is there a limitation on the 20D to not be able to write only in RAM and transfer it to the pi3 ? or any other reason ?

Here attached is the log/debug of the kstars files as well as the indi_ccd driver one

Thank you very much for your help !!
Pask

Read More...

pask replied to the topic 'Re:Plate solving issue in EKOS' in the forum. 3 years ago

Hello everybody,

My turn to jump to this thread as well, let me expose my "little" issue which is a problem in plate solving also :
Well, i spent two nights trying to solve this plate unsolving but in vain :'( ... i stayed at 1hr from my home in the middle of a field from 6PM to 6AM this morning (a bit hard for me to have my eyes open now loool) ...very frustrating to spend all nights trying to get the first step done ...but welll this is also why we like astronomy ;)

Issue :
- doing a capture & solve will never solve the capture.
- starting even a polar algnment is the same, not solving
BUT
- doing a capture ( in the module of capture, in a sequence or a preview that i saved) and then use "load & slew" will work in about 5sec !! (with the exact sky portion captured on both way)

-> from both test it is the exact same position and same exposure etc....

my setup is this one :
- skywatcher 254/1200 (+skywatcher coma corrector) with only canon EOS 5D3, no guiding.

one curious fact about the canon is, you can find 2 data for its resolution :
- 5760x3840 for a 36x24mm sensor giving 6,25microns
- 5796x3870 / 36x24mm then 6,22microns
Calculatin FOV gives : (103' x 68') - for both characteristics

I noted one weird thing :
- when i do a load&slew : it shows in the status zone that it starts the solver with that options : -H 108.966 -L 65.8275
- when i do capt&solv : options are mostly the same ...except H & L : -H 113.446 - L61.8794
Seems that from capture&solve it allows a bigger window...why ?
-> i tried to modify the options line in the "solver option" part of the aligment module, but it gets erased each time i start a capture&solve (i did not find from where it erase it)
-> I tried in the astronometry option (from the "option" button in the bottom right part of the aligment module) : i tried to uncheck "auto-update FOV" and modify the value of the FOV there but i did no see any change, each time the option line ("-o ....") is erased ... just like it was computing the FOV tolerance directly from the fresh capture
-> Is there a tolerence in the code that is different from "capture&solve" to "load&slew" ? Reversing the data gives me a +/- 5% for "capture&solve" and +/- 10% for "load&solve" !

-> so I try directly the solve-field command on the terminal ... from the same picture and just changing the H or L options ... the issue is on the H size ... the bigger one allow the picture to be directly solved in 5sec ... the initial H value does not solve at all (i increased the timeout to 5 and 10min..)

-> Then i noted the astrometry version was 0.67 ... i went to the website and in the middle of the night downloaded the latest sources (0.74) i did all the procedure from the website to install it : the short version failed at some points (i suppose some dependencies for compiling were missing) but the long version worked fine... i restarted kstars/ekos etc.. and ... well the version displayed in the status bar at launch of the alignment module is still 0.67 !! :'( :'( :'( i can't understand ... anyway no more time for that... :

As the sun was rising :'( ... i was short in options ... so idid trick the latest thing i could => i reversed the FOV formula to modify my telescope Focal length to match a option H of 113 !!
The focal was then 1146mm (instead of 1200mm) ... it solves !! but i have a warning saying "the calculed Focal length is 1082,x please change for better accuracy), i change the length, i redo the solving, then it ask me to change a little more the focal length, but still around 1082-1084mm ..(and 1082 is the exact value that gives directly a FOV of 113 .. strange)

Well ... that"s all my investigatio ... i ended up doing a polar alignment with the sunrise.. it was beautiful .. and i got my vector to adjust my alignment ! (well i missed it coz i was really too exhausting ... so i packed up everything and drove back home to sleep a few hours !!

Well ... thank you for reading me (long email, i tried to make it the most detailed and explain all i did .
@Niki and others : did you check the H & L options the solver gets to solve your picture ? (maybe it's same thing ?)

Any help will be more than welcome ... we have a big astro event tomorrow with all association of my region ... i would very love to be able to participate and most of all i would love to show the great bundle kstar/ekos/indi which is for me just a pure diamond of open developpment !!!

Pask,

Read More...

Well thank you Jo for your time and explanation!
I learnt a lot about the gphoto lib with this and it's highly appreciable. !!

So you right in mRaw & jpg it was all OK (except with the dev-driver that i found today) -- but honestly i did not try the sRaw before, for me if mraw&jpg were fine the sraw should have beeen also....
But making the full detailed test for the tmpfiles.. i discovered the sraw doesnt pass to the rpi3 ! Strange....

I posted the same results to gphoto issue team.. keeping finger crossed it will give thdm some ideas !

I will keep posted any progress here for the sake of the community and if anybody has the same issue .. (i would love to know if anybody with 5d3 & pi3 get same results btw ..)

Best regards,
Pask

Read More...

Muchas gracias otra ves Jo ! :)

So i did many tests .. and the results are ... weird ! .. here the thing :

dev-driver (2.5.15.1 & 2.5.16.1) :
RAW/mRAW/sRAW => Err70 on the camera, and tmpfile=0ko
JPG => OK fully

stab-driver (2.5.15 & 2.6.16)
RAW = blocked at some % like 26% (see file : tmp-RAW-stab-blocked) size 3.1Mo
mRAW = fully ok (see file : tmp-mRAW-stab-OK) size 8.3Mo
sRAW =!!! blocked at some % like 30% (see file :tmp-sRAW-stab-blocked) size 2.6Mo
JPG = fully ok (see file : tmp-JPG-stab-OK) size 655ko

Very strange to see the sRAW doesn't pass !!! And i did the test 3x for each format, and i get the same result each time, with same size of tmpfile !

Read More...

Thank you very much Jo for all these inputs,

Well i am just cooking the dinner (making my head to breath a bit out of gphoto & rpi3 !! loool) - i will look better your inputs in a few...

my morning message was related to the issue i open on GIT regarding gphoto2 in fact, where i attached the debug file.
You can read the exchnage and see the file there : github.com/gphoto/gphoto2/issues/127
(i just recently send a new message with the new debug file...

the "unknow event" is trange but i see them also when it is a success with the jpg. The trouble is after that and after the exposure...

I am right now trying to install a ubuntu astro (astronomy linux distrib) to a hardrive and i will try it on my laptop (to see if the laptop has same issue this would take out the rpi3 possibilty)

hoping Marcus or other people could check from gphoto2 side ..
I will come back to your message later tonight ;)
thank you very much for taking time to look & remember your experiences ;)

Read More...

Sorry.. just waking up and i thought i was o. The git issue part :((
Mea culpa jasem !

Read More...