First attempt with Astroberry/INDI - Didn't go so well.

[upahill]

Managed to find a Raspberry Pi 3 v1.2 at a carboot for £3 and suprisingly it worked so figured it was about time I gave Indi/Kstars/Ekos a go. The aim is to have the majority of stuff mounted on the scope as whilst my previous setup works having multiple leads trailing to a laptop is a pain.

So far I managed to:

• get the Autofocuser i built (myfocuserpro) sort of working through Indi - there is a lot of backlash but thats more a mechanical issue that software.
• the canon 1200 is recognised and takes shots (although the driver is randomly crashing requiring a reboot to fix)
• plate solving works about 2/10 times with remote option, and never with local.

My problems / questions are:

• The Altair GPCAM im using for guiding is recognised, but will only show an image if binned 4x4, this is leaving me with very pixelated shots where noise and stars are almost indecernible. I was using the EKOS guiding module, did try PHD but didnt get anything from the camera at all. Does anyone else use the GPCAM on INDI?
• The canon, gpcam, eq6 and focuser (arduino) are all connected to the Rasbpi directly. Im concerned there isn't enough power in those ports to handle everything (although its only really the gpcam that is 'powered' by it) Could this be causing the lack of 1x1 images from the guidecam?
• I have downloaded the indexes for Astrometrey that it said I needed, through the dialog - but still getting errors with platesolving saying that they are missing, anyone else ever had to fix this?
• Last night I struggled getting platesolving/alignment working, but when I had the first point done I would slew to a target and try and solve/sync that. First time I tried it was the first time I crashed the mount - it seems there are not limits like EQMod had, do they get up seperately?

Any help, tips, advice, gotchas greatly appreciated. The raspberry is a little underpowered I fear but if this turns out to be a workable solution for me I can consider getting a better machine to strap to the scope.

T.I.A

Edited May 13, 2019 by upahill

[upahill]

Another night of testing and I think im getting used to it a bit more, it is struggling to run with limited RAM though, issues converting CR2 I think for processing.

The main issue is still Ekos crashing when it loses connection to the INDI server - I guess this is likely due to lack of resources too.

Might have to wait till I have a more powerful test system than a raspberry pi.

[feilimb]

I have been running Indi and KStars on my Raspberry Pi 3B for a few years.  There have been plenty of glitches, but for the most part it is pretty stable. In my setup I have 4 peripherals connected directly via USB cables to the Raspberry Pi:

EQDir cable to mount (HEQ5, has it's own independent power source)

QHY5L2 Mono (guide camera, which I can use either 1x1 or 2x2, etc.)

Pegasus Pocket Powerbox (has it's own independent power source)

ASI294MC Pro Camera (has it's own independent power source)

As you can see from above, the only peripheral needing power is the guide camera, which is very similar to your setup.  I previously used a Canon 450d (with internal battery), and had no power issues.  In the Indi forums, I think it is generally recommended to have a DC powered USB hub, but in practice I have not found it necessary.

Since many of your questions are specifically on the Indi/Ekos software I think you will likely get more response directly from their forum: https://indilib.org/forum/indi-library.html

Best of luck!

Note: I also run KStars itself on the RPi3, and perform the imaging via VNC connection.  KStars runs ok, but I have had crashes of it happen during imaging sessions.  It would be more stable to run KStars on a different machine, and just have Indi server running on the RPi3, the downside being that you are the mercy of your network speed for image download (eg. when using the Focus Module and capturing continuous images, it is slower transferring 'live' images across network).

Edited May 14, 2019 by feilimb

[upahill]

1 hour ago, feilimb said:

Note: I also run KStars itself on the RPi3, and perform the imaging via VNC connection.  KStars runs ok, but I have had crashes of it happen during imaging sessions.  It would be more stable to run KStars on a different machine, and just have Indi server running on the RPi3, the downside being that you are the mercy of your network speed for image download (eg. when using the Focus Module and capturing continuous images, it is slower transferring 'live' images across network).

This might be the way to go. As you said I didn't think the power draw on the board was that bad, might try and find a better power block for the Rpi though just in case.

Network speed isn't an issue as I have cat6 running out to the pier. I have been launching INDI/Ekos using Kstars and assume that it will now work the other way, eg I find some way to start INDI on its own, and then Run EKOS/Kstars on my indoors machine setting the connection to remote.

Downloading from Camera to Pi has been a big bottleneck, especially if set to raw. If I lower it to jpeg to speed up focusing then I lose the option to shoot raw for the routines. Lots more tweaking I think but at least the forecast is clear for tonight again.

Thanks.

[feilimb]

6 hours ago, upahill said:

... I find some way to start INDI on its own, and then Run EKOS/Kstars on my indoors machine setting the connection to remote...

I can recommend the excellent Indi Web Manager for starting up/shutting down Indi Server and Device Profiles via a handy web interface:

https://github.com/knro/indiwebmanager

You can install Indi Web Manager and have it start automatically on Pi bootup as a system service, then from your 'indoors machine' in a web browser, browse to eg: http://your_pi_ip_address:8624  to start Indi Server and appropriate Libraries.

[don4l]

I've just moved to Indi in the last month.

I've given up with Ekos/Kstars because they seemed too closely connected to the Indi server.  The server and the "client" (Ekos) should be completely separate.  This caused me some problems with software crashing.

 

I've been using CCDCiel instead, and after a short learning curve, I am getting along brilliantly with it.  For astrometry, I have both Astrometry.net and ASTAP.  If you are having problems solving, then have a look at the FITS header in an image file to check that the focal length and pixel size  are set correctly.

 

I started with the Pi 3+. but quickly came to the conclusion that it couldn't move large files around quickly enough. 

I'm now using a refurbished Dell Laptop ( cost £230.00 from Dell) and it does the job perfectly.

 

To start and stop the Indi server I use "IndiStarter" https://sourceforge.net/projects/indistarter/

There is also a simple client "Indigui" which allows clear control of the individual drivers.  I think that IndiGui is included with Indistarter.

I haven't managed to figure out the limits yet, but I did have a problem with the park position.  The default position was pointing somewhere silly, which caused the mount to "crash" the ota into the tripod.  To fix this I powered up the mount in its home position.  I started Indi, and on the EQMOD driver I went to the Site Management tab.  There (beside Park Options) I clicked  "Current" and then "Write Data".  This seems to have fixed it.

 

 

 

[upahill]

1 hour ago, feilimb said:

I can recommend the excellent Indi Web Manager for starting up/shutting down Indi Server and Device Profiles via a handy web interface:

https://github.com/knro/indiwebmanager

You can install Indi Web Manager and have it start automatically on Pi bootup as a system service, then from your 'indoors machine' in a web browser, browse to eg: http://your_pi_ip_address:8624  to start Indi Server and appropriate Libraries.

Thanks for this, for testing im going to keep astroberry running on the pi so im guessing I can install this alongside

1 hour ago, don4l said:

I've just moved to Indi in the last month.

I've given up with Ekos/Kstars because they seemed too closely connected to the Indi server.  The server and the "client" (Ekos) should be completely separate.  This caused me some problems with software crashing.

 

I've been using CCDCiel instead, and after a short learning curve, I am getting along brilliantly with it.  For astrometry, I have both Astrometry.net and ASTAP.  If you are having problems solving, then have a look at the FITS header in an image file to check that the focal length and pixel size  are set correctly.

 

I started with the Pi 3+. but quickly came to the conclusion that it couldn't move large files around quickly enough. 

I'm now using a refurbished Dell Laptop ( cost £230.00 from Dell) and it does the job perfectly.

 

To start and stop the Indi server I use "IndiStarter" https://sourceforge.net/projects/indistarter/

There is also a simple client "Indigui" which allows clear control of the individual drivers.  I think that IndiGui is included with Indistarter.

I haven't managed to figure out the limits yet, but I did have a problem with the park position.  The default position was pointing somewhere silly, which caused the mount to "crash" the ota into the tripod.  To fix this I powered up the mount in its home position.  I started Indi, and on the EQMOD driver I went to the Site Management tab.  There (beside Park Options) I clicked  "Current" and then "Write Data".  This seems to have fixed it.

 

 

 

The aim was for something small like the Pi, I had a laptop before but really wanted everything mounted semi-permanent to the OTA. If the Pi can't handle it then I might need to look at a mini-pc or beefier SBC. If im restricted to using a full pc then I may as well stick with what I know

Thanks for the tip on setting up Park position, and the FITS header info - neither of which I have configured so could well be part of the problem.  

[upahill]

Had another go last night, this time using Kstars/EKOS on my indoors PC, connected to the Pi on the scope over ethernet. Worked fine once I got everything setup. I did have Kstars crash on the windows machine once and not sure what caused that but I got to the end of an imaging run whilst guiding without issue after that.

Platesolving online still only worked intermittently, fits header appears to be ok, im considering adding a mirror of astrometry.net to my home server and using that instead - its got more grunt than then Pi and uploading to it will be faster. I got astrometry.net installed on a Virtual Machine, but not the API/website side of things yet.

Guiding worked but still having to bin 4x4 to get anything out of the camera which is weird.

Until plate solving is figured out I cant really build an alignment model for the mount, so havent bothered trying to sort out parking properly etc. If its clear this evening I might have another go.

[feilimb]

30 minutes ago, upahill said:

Had another go last night, this time using Kstars/EKOS on my indoors PC, connected to the Pi on the scope over ethernet. Worked fine once I got everything setup. I did have Kstars crash on the windows machine once and not sure what caused that but I got to the end of an imaging run whilst guiding without issue after that.

Platesolving online still only worked intermittently, fits header appears to be ok, im considering adding a mirror of astrometry.net to my home server and using that instead - its got more grunt than then Pi and uploading to it will be faster. I got astrometry.net installed on a Virtual Machine, but not the API/website side of things yet.

Guiding worked but still having to bin 4x4 to get anything out of the camera which is weird.

Until plate solving is figured out I cant really build an alignment model for the mount, so havent bothered trying to sort out parking properly etc. If its clear this evening I might have another go.

Ouch, it seems like you're having quite a few problems.  I use 'local' for plate-solving option in the Alignment Module on my RPi 3 without any problems.  I wonder if it is something daft like the user permissions on the files which were downloaded for platesolving, I can take a look at mine later and see what owner / permissions they have. 

Is the focal length and aperature of your guide scope definitely set correctly within Ekos, and correct corresponding plate-solving files area available locally? (I can't recall off hand where you need to set these, maybe at the bottom of screen in the Mount module).

Regards a beefier SBC, the Rock64 (https://www.pine64.org/devices/single-board-computers/rock64/) is used by some Indi users. I have one myself but haven't migrated my Indi setup to it yet, the disadvantage over RPi 3 is that it has no on-board Wifi adapter, and only 3 USB ports but advantages are that 1 of those ports is USB3.0 (much faster image download) and the RAM and processing power are greater for a price which is comparable to RPi 3B+.  There are a number of distros available, I think I have Ubuntu 18 on mine but I could be wrong on that

Edited May 15, 2019 by feilimb

[upahill]

4 minutes ago, feilimb said:

Regards a beefier SBC, the Rock64 (https://www.pine64.org/devices/single-board-computers/rock64/) is used by some Indi users. I have one myself but haven't migrated my Indi setup to it yet, the disadvantage over RPi 3 is that it has no on-board Wifi adapter, and only 3 USB ports but advantages are that 1 of those ports is USB3.0 (much faster image download) and the RAM and processing power are greater for a price which is comparable to RPi 3B+.  There are a number of distros available, I think I have Ubuntu 18 on mine but I could be wrong on that

I looked at the Rock64 and the USB3 is an attractive feature. My other consideration was getting the Pi 3B+ which has a slightly faster CPU - and then using something like this hub hat to give me a powered USB hub with 9 extra ports Now if that hat was USB 3 and could go on the Rock64 it would be a winner!

Its taking about 15 seconds to transfer a captured sub over the network to the client machine (thats from the moment it finishes on screen to appearing in the folder, so assume that includes download from camera time too) I dont mind that, but it does slow down focusing and guiding.

The best solution is just going to be a beefier mini PC, more ram, USB3 all round and then have just the USB3 hub strapped to the scope with one lead down to the PC I think.

Il give the onboard plate solving another go. I will need to redownload the indexes I think as I cleared some of them last night to test and then gave up and went to bed 🤣 Connecting remotely to INDI probably removes the need to have a full blown astroberry install on the Pi and I could go for a slicker headless install.

 

[rickwayne]

I find that platesolving works quite well for my guide camera on the Pi, not so much for the main (20 MP) one. I have had it work, mind, but it's slow and doesn't always solve. Five things:

1. In some cases the lack of index files will only slow solving, rather than kill it, as the software has to search for its image within larger footprints rather than find it quickly within smaller ones.
2. Do ensure that the astrometry index files are actually in the correct place.
3. Try selecting your guide camera and solving with that. The smaller image should make it more palatable to the Pi, and will serve as a smoke-test. Depending on how well your guide and main scopes are collimated, it might even be all you really, truly need.
4. Check the command-line parameters that Ekos is passing to astrometry. In mine, I have it downsampling 16x.
5. Are you seeing reasonably focused stars in the images it's trying to solve? Poor focus can make it spin endlessly (go on, ask me how I know...)

I have to say that, having tried it with the Pi and with a 2018 Retina MacBook Pro, one of those things is a lot less frustrating than the other. But one of them will run all night on about seven electrons, and the other gives me maybe two hours of imaging and it's Tango Uniform Mode Time.

Edited May 15, 2019 by rickwayne

[feilimb]

Also, when plate-solving with the main camera, ensure you using Binning 2x2 to reduce the workload / speed up the solve.

[upahill]

1 hour ago, feilimb said:

Also, when plate-solving with the main camera, ensure you using Binning 2x2 to reduce the workload / speed up the solve.

It wont let me bin the main camera. Only the guide camera, and only when guiding. In fact anything other than 4x4 on the guide camera and I get no picture at all.

[rickwayne]

Well, that is annoying. Normally "they" say don't bother binning your main camera unless it's a CCD, it just cuts down the number of pixels without any improvement to signal/noise. But here cutting down the pixel count is exactly what we want!

Downsampling should produce a similar result, but offloading the binning to the camera (if that worked) would necessitate less CPU time downsampling, in addition to speeding up the image download.

That's a pretty annoying hit.

[upahill]

57 minutes ago, rickwayne said:

Well, that is annoying. Normally "they" say don't bother binning your main camera unless it's a CCD, it just cuts down the number of pixels without any improvement to signal/noise. But here cutting down the pixel count is exactly what we want!

Downsampling should produce a similar result, but offloading the binning to the camera (if that worked) would necessitate less CPU time downsampling, in addition to speeding up the image download.

That's a pretty annoying hit.

On a similar thread I had thought about changing the camera format to JPEG instead of Native (CR2) or FITS, which does speed up download time from camera, but I can only do that in the backend - and it applies to all settings, so my main subs then become JPEG

Im pretty sure its passing a downsampling command through to its built in Astrometry but will need to confirm.

[upahill]

Well tonight was one of those "Right its all going on eBay" nights....

I managed to eventually setup a VM on my server running Ubuntu and after a lot of tweaking got the Astrometry-api-lite setup installed giving me a fully working astrometry clone on the network.

Setup the gear, tinkered to get the solving working for quite some time but it did work, so Pi running INDI, Server VM running astrometry and my Windows machine running Kstars/EKOS...

Guiding was better tonight, didn't need to bin either which was weird and good. Got focuser to operate, still need to get to grips with the autofocus system (I think this is more a problem with backlash on my setup) - got the mount aligned after a few attempts and a few hard resets.

Went for an imaging run as a test, and after the first sub came in Kstars/EKOS just dissapeared. 🤬

It's done this before, but always waits until everything is working as it should.

So since its 1am and the clouds have rolled in I decided packing up was the best thing to do until I cool down a little.

[rickwayne]

Oh. My. Your maturity and restraint serve as a model to us all. EBay, nothing, I would have been more like "It's all going ON THE MOON" and started hurling things.

I can't say I haven't had KStars and Ekos roll over and die on me. But at least on the Mac it's uncommon. On the Pi...maybe once every other imaging session. If I'm checking it, no huhu, I just miss a bit of imaging time till I get it back up. If not...lunar astronomy. I am saying.

[alacant]

On 22/05/2019 at 02:48, upahill said:

Kstars/EKOS just dissapeared

Hi. Oh dear. 

Too many variables? Suggestion: Lose the rpi for now and throw some decent resources at it. Get indi-ekos-kstars all on the same box; e.g. a laptop running ubuntu 18.04. Once you're familiar with it, then may be a better time to delegate parts of it -e.g. the indi server only on the rpi- to lower resource.

On 14/05/2019 at 18:13, don4l said:

a refurbished Dell Laptop

+1

 

[don4l]

I was getting odd results with the platesolving.  Sometimes I couldn't platesolve an image at all. Other times I would swap from Astrometry.Net to ASTAP, or visa versa to get it to work.  Last night I started dark subtracting before solving and it kicked into life.  Images that wouldn't solve at all suddenly solved in under 2 seconds.

This probably depends on how noisy your camera is (mine has some real humdinger hot pixels).

 

[upahill]

Well touch wood it has been working so far tonight. I redid the coupler on the focuser which is going to have to be replaced but seems to be the cause of the majority of issues with that. Its a flexible coupler made of some sort of aluminium putty. Will replace with a solid one I think and some better quality grub screws.

Set the binning on guide camera in the driver rather than through EKOS and that has enabled guiding images to come through much better. So im guiding now. It's at 1.78" RA but that could be due to lack of dark subtraction and a combined star/hotpixel.

It hasn't crashed yet, and the platesolving server is working perfectly and solves blind in about 30 seconds with no load on the raspberry pi.

As far as proof of concept goes im getting happier with it, and I think a more powerful mini pc running ubuntu would be the next logical step. Want to future proof a bit and get something with plenty of USB3 throughput that will run on 12v

 

 

Edited May 27, 2019 by upahill

[feilimb]

I commend your persistence sir, and am glad it is starting to work out! I've had my share of eBay nights also and know that feeling.. Hope it starts to settle down now in consistency via all the knowledge gained.  That looks like a nice sub with good guiding above by the way!

[upahill]

Thanks, its the first time I have used FITS, used to getting CR2 files to stack. This appears to be a whole'nother ball game. All I have managed to do with the stack so far is produce some very grainy results. It's only 30x180s that I managed last night, with darks but would normally get better results 🤔

Something to play around with whilst it rains

[quantOnaut]

Hi, 

i have my kstars/ekos system running on rpi4 from Nvme usb3.1 drive, super fast!

ZWO cams with usb3 bandwith-100 no problem

download times 6Da DSLR in less then a second

i have purchased a second pi4 

 i have to deal with 2-3 driver crashes per night

refurbished Dell was not a good investment :-) 

[teoria_del_big_bang]

On 13/05/2019 at 18:27, upahill said:

My problems / questions are:

• The Altair GPCAM im using for guiding is recognised, but will only show an image if binned 4x4, this is leaving me with very pixelated shots where noise and stars are almost indecernible. I was using the EKOS guiding module, did try PHD but didnt get anything from the camera at all. Does anyone else use the GPCAM on INDI?

I know this is from a year ago but I am just starting the same struggle with astroberry and Ri4 and my main issue is also not being able to guide with Altair GP130 Mcamera.

If I try to use it just through Ekos then it works fine as a camera but whether I use PHD2 or the Ekos guiding it just times out and does not take an image.

Apart from binning did you get this to work ?

Steve

[TerryMcK]

Have you tried the camera in 8bit Steve? I know my ZWO ASO120MM works ok on 8bit in Windoze PHD2 but sometimes times out in 16Bit. Might be worth a punt in INDI!