Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_2018_sp_banner.thumb.jpg.a4fa178de7d36660e48f7eb1205319eb.jpg

Recommended Posts

Some of you already know this, having followed my threads on the indi-forum and maybe the zwo users group.

A while ago I started testing INDI on a 64 bit Rock64 sbc, to replace my Raspberry Pi. The advantage of using a Rock64 computer is that it is a faster machine and it has USB3. ZWO recommends using their cameras on USB3 machines to reduce amp-glow. Amp-glow in their cameras is (partially?) caused by the slow read out when using USB2.

Installing the indi library and getting that to work wasn't much of an issue, but I never got the zwo efw to work. After some discussions on the zwo forum, the bug was identified (cross compiler problem) and solved. Jasem Mutlaq of INDI updated the library, and now it all works.

Here's a write up of how I installed everything:

-------------------start of write up-------------------------

Rock64 ubuntu installation

Installation downloads to my windows machine:

download xenial-mate-rock64-0.5.10-118-arm64 from
https://github.com/ayufan-rock64/linux-build/releases
This is a stable release
extracted using 7zip
written to sd-card using win32diskimager

(Btw, this is not the final release, see below)

Booted the Rock64:
this starts the mate desktop (default login is rock64/rock64, but yo might want to change the password at least)
connected to hdmi, tplink usb device connects to wifi.
in the network manager for the wifi network (that's where you've set the SSID,
passkey), allow the network (wifi) connection for all users

Installation of indi:

installed indilib full and kstars bleeding, see the ubuntu instructions on the
indilib website.

Next is to install the indi web manager:

Installed pip:
sudo apt-get install python-pip
This installed an older version. However, upgrading did install the newest.

Tried installing indi web manager, but got a compilation error:

Python.h - no such file or directory.

Solution: install Python-dev

$ sudo apt-get install python-dev  // this is for python 2.7

(for Python 3.x use:)
$ sudo apt-get install python3-dev

171104: installed latest pre-release 0.6.x in order to get access to usb3
patches

EFW doesn't work with rock64. Tried a lot. Among other things, building indi from source.

Reinstalled SD card several times, trying several pre-releases. The Ubuntu release I use now is:

Ubuntu 16.04.3 LTS (GNU/Linux 4.4.77-rockchip-ayufan-136 aarch64)

 

... project on hold, waiting for ZWO fix and work getting in the way ...

171208: after communicating with ZWO (zwoug forum) and on the indi forum, the
filter wheel issue is solved. It turned out to be a cross compiler bug in the
asi driver for the wheel. ZWO issued a fix that was implemented by Jasem
Mutlaq of INDI. All I had to do was update and upgrade the system. Now it
works fine.
 

-------------------end of write up---------------------------

Image download seems faster than on the Raspberry Pi. So far I've only tested
it with a USB2 cable in the USB3 connector (the USB3 cable has a kink). But
setting the bandwidth in the indi control panel of Ekos to 100, I seem to get a
substantially faster download of captured images to my computer.

No first light yet, due to clouds (isn't there a "sudo apt-get upgrade" for that?)

 

For those of you willing to try this, installation should be trouble free if you use Ubuntu and connect to the indi repository. Just install and upgrade should get you a workable solution.

And what about the amp-glow?

Well, so far the only test I've been able to do is indoors with an uncooled camera, using a USB2 cable in a USB3 port. As I mentioned, I set bandwidth in the indi control panel of the camera to 100, and seem to get a fast download time to my laptop (camera --> usb3-ish --> Rock64 --> wifi --> laptop). But there's still amp-glow. This isn't a magic bullet; all I hope for is an improvement. And even if it doesn't reduce the amp glow, I still can squeeze out a few more exposures per session if download time is shorter. And with short exposures, that makes a difference. 

Hope this can be of use to someone.

Edited by wimvb
  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites

Its of use to me Wim. I noticed your thread on the Indi forum about it. If I can find a reliable and compact Indi h/w and s/w configuration that allows high speed planetary imaging (implying USB3) then I'll take the plunge. I'm very interested to see how you get on with your Rock 64 once you replace the kinked cable!

Tony

Share this post


Link to post
Share on other sites

... not to mention: get clear skies. That's another "kink in the cable".

I will follow up here, once I have something.

Share this post


Link to post
Share on other sites

Thanks Wim, I've managed to install everything in a Rock64, but I had other issues installing the web manager, it required the support tools which weren't automatically installed. I've even managed to install XRDP, so can control a desktop from anywhere on the local LAN.

Couple of pointers for this board:

it's touchy on power supply, it really does need 5v @ 2.5A, so I'll probably drive it off a LM7805T which in turn is driven from the general 12v supply...

Every so often it keeps throwing errors with some obscure kernel devices, but hasn't fallen over yet...

Now to let it soak test for a few weeks before building it into an enclosure with DC regulators \ USB hubs etc., for deployment on the mount....

  • Confused 1

Share this post


Link to post
Share on other sites
5 hours ago, Dr_Ju_ju said:

I had other issues installing the web manager, it required the support tools which weren't automatically installed.

On my RPi, I don't use web manager anymore. When I have both my asi cameras hooked up, web manager consistently starts two drivers, and my guiding won't work. So I only start indiserver from the command line.

With the Rock, I haven't tried this yet. Lack of clear skies ...

The support files (pip and python dev tools) were a little tricky, but I got it to work.

Edited by wimvb

Share this post


Link to post
Share on other sites

And here's a short follow up:

Last sunday we had clearish sky, at last. Enough to test the Rock64. The ASI filter wheel works, I was able to do a complete sequence of NGC 7438 (a very uninteresting cluster)

(80 x 15 s L, 40 x 30 s RGB)

ngc7438_RGB_clone1.thumb.jpg.13909446eb8cff17894dd1c23d2605fa.jpg

The wheel performed well.

Another issue turned up, for some reason I couldn't get guiding to work. The guide cam (also an ASI camera) was unresponsive. It may have been operator error, I haven't tested any more.

The Rock is faster at booting up, and image download to my laptop (via wifi) is faster than the RPi. But I didn't see any improvement in amp glow.

In the mean time, I've also bought a new usb3 cable, but only after the clouds moved in again.

I did manage some speed tests while shooting darks. Saving images to the local computer (running indiserver), rather than the client, speeds up imaging considerably. I will put this to the real test during my next imaging session, with usb3 cable.

In the mean time, I also tried to install PHD2 on the Rock64, but without success.

On my RPi, (also running Ubuntu) I can just connect to the PPA (pch/phd2) and install. On the Rock, this doesn't work. I always get a message that the package can't be found ("unable to locate package phd2").

The usual remedies (apt-get update, or adding the ppa to the sources.list file) don't work. And investigating further, it seems that the ppa isn't in the lists.

https://www.ubuntuupdates.org/ppas

But it is on launchpad:

https://launchpad.net/~pch/+archive/ubuntu/phd2

More to investigate ...

Share this post


Link to post
Share on other sites

Hi Win

Thanks for you persistence on this. I`m looking to get a Rock64 just for the USB3. Gigabyte LAN is welcome as well. I hope the next RPi will have all this and more:smiley:

Graham

Share this post


Link to post
Share on other sites
1 hour ago, Fellside said:

I hope the next RPi will have all this and more:smiley:

Looks like being a long way off......

Share this post


Link to post
Share on other sites

I've read somewhere on the indi forum that RPi with usb3 is still a few years off. But haven't seen anything about it on Raspberry pi forums.

But if more people start using usb3 sbc's, these will catch up with the Pi in terms of stability.

At the moment, I don't know if any issue is because of the os, or application software.

With the few clear nights we've had, I won't rely on just the rock64. Fortunately, swapping to the Raspberry pi only takes a few minutes.

Share this post


Link to post
Share on other sites
On 16/12/2017 at 16:27, Dr_Ju_ju said:

it's touchy on power supply, it really does need 5v @ 2.5A, so I'll probably drive it off a LM7805T which in turn is driven from the general 12v supply...

A LM7805T is a linear regulator and is only rated at 1A (some manufacturers are 1.5A) and would be getting mighty hot dissipating all that power dropping from 12V... unless I am missing something?

Share this post


Link to post
Share on other sites

True, I should have put LM1084.... unless I stick with the 7805 with a current sink 

Share this post


Link to post
Share on other sites

Yes, the 7805 would need a power transistor or two, to handle that current. I also considered a step down converter when I bought the sbc, but settled on a 5V/3A mains adapter, just because of the power loss issue. I wonder if a switched step down converter would work.

Share this post


Link to post
Share on other sites

For a Pi3, I'm using a standard eBay buck convertor, which drives the Pi & its attached 250 GB disk et al, with no issues & excess heat etc.

 

Share this post


Link to post
Share on other sites
On 2017-12-11 at 03:50, tonyowens_uk said:

Its of use to me Wim. I noticed your thread on the Indi forum about it. If I can find a reliable and compact Indi h/w and s/w configuration that allows high speed planetary imaging (implying USB3) then I'll take the plunge. I'm very interested to see how you get on with your Rock 64 once you replace the kinked cable!

Tony

Cable replaced, but unfortunately no change regarding the clouds. With my latest test (usb2), I left the images on the sbc, rather than downloading them to the indi client. So, this is fastest I can get at the moment:

Indi on rock64 is faster than RPi

Save captures on the rock, transfer them after the imaging session

Usb3 rather than usb2

 

That's all so far. Merry Christmas to you all.

Share this post


Link to post
Share on other sites

I'm veeeery happy to announce that phd2 now also works on the Rock64 under ubuntu mate.

This is the way to it set up:

sudo add-apt-repository ppa:pch/phd2

sudo apt-get update

sudo apt-get install phd2

 

Previously, there was no arm64 build for phd2 on ubuntu. But with tremendous help from Patrick Chevalley, I managed to build phd2 from source. Patrick then added the arm64 architecture to the ppa build.

 

On the downside: I'm completely clouded in (no surprise there), so I can't test it.

Share this post


Link to post
Share on other sites

Can I ask, what maybe a silly question, and appologies if it is.... but if controlling the rock or rpi from a seperate linuxlaptop,  (as I do) then can you just install INDI on the rock or rpi or has Kstars / Ekos still got to be loaded even if not going to be used...?? :) 

Share this post


Link to post
Share on other sites
29 minutes ago, LightBucket said:

Can I ask, what maybe a silly question, and appologies if it is.... but if controlling the rock or rpi from a seperate linuxlaptop,  (as I do) then can you just install INDI on the rock or rpi or has Kstars / Ekos still got to be loaded even if not going to be used...?? :) 

It's not silly, but I can guess the reason: with your setup you will need your laptop to stay always connected to the Rock64/Raspberry server, otherwise it won't be able to shoot on its own.

I'm currently working on a web INDI sequence to get rid of this requirement though (and all the VNC setup as well), stay tuned.. :p

 

Share this post


Link to post
Share on other sites
3 hours ago, GuLinux said:

It's not silly, but I can guess the reason: with your setup you will need your laptop to stay always connected to the Rock64/Raspberry server, otherwise it won't be able to shoot on its own.

I'm currently working on a web INDI sequence to get rid of this requirement though (and all the VNC setup as well), stay tuned.. :p

 

Forgive me for being really thick, but still non the wiser, why can’t I just connect direct to the indi  server with my Linux laptop, why do I have to have Kstars / Ekos Installed on the rpi at all...?? When I use the version on my laptop for imaging, the rpi is Just there to connect devices to, with INDI drivers and then serve the laptop..

Maybe I am not explaining this very well.. :)

Share this post


Link to post
Share on other sites
6 hours ago, LightBucket said:

Can I ask, what maybe a silly question, and appologies if it is.... but if controlling the rock or rpi from a seperate linuxlaptop,  (as I do) then can you just install INDI on the rock or rpi or has Kstars / Ekos still got to be loaded even if not going to be used...?? :) 

if you control the rpi/rock from a laptop, you don't need kstars on the rpi/rock.

 

2 hours ago, LightBucket said:

Forgive me for being really thick, but still non the wiser, why can’t I just connect direct to the indi  server with my Linux laptop, why do I have to have Kstars / Ekos Installed on the rpi at all...?? When I use the version on my laptop for imaging, the rpi is Just there to connect devices to, with INDI drivers and then serve the laptop..

Maybe I am not explaining this very well.. :)

All your hardware (camera, mount, focuser, guide cam, obsy roof, etc) talks to a computer through drivers. These drivers are controlled from the indi server. The hardware, drivers and server are on the Raspberry Pi (or Rock). This configuration can talk to all kinds of clients. One possible client is Ekos in Kstars. Another possible client is PixInsight.

The idea behind indi is to separate the client program from the hardware drivers by introducing an extra layer, the server. Indiserver is the bridge between hardware on a linux platform, and a client program on any other platform (Mac, linux, windows). Since hardware and client are on two different machines, there's no need to haul a laptop out to the telescope setup. This also opens up for remote operations. And it's possible to use a faourite client program.

But, as @LightBucket wrote, if you lose the connection between client and server, you lose the imaging session. By running the (Ekos/Kstars) client software on the same computer as the server, you get a solution that is independent of connection stability.

If you find Ekos/Kstars too demanding for a Raspberry Pi, you need a lighter client, which doesn't use as much cpu resources. I guess this is what LightBucket refers to as the web sequence he is developing. 

 

Share this post


Link to post
Share on other sites
13 hours ago, wimvb said:

if you control the rpi/rock from a laptop, you don't need kstars on the rpi/rock.

 

All your hardware (camera, mount, focuser, guide cam, obsy roof, etc) talks to a computer through drivers. These drivers are controlled from the indi server. The hardware, drivers and server are on the Raspberry Pi (or Rock). This configuration can talk to all kinds of clients. One possible client is Ekos in Kstars. Another possible client is PixInsight.

The idea behind indi is to separate the client program from the hardware drivers by introducing an extra layer, the server. Indiserver is the bridge between hardware on a linux platform, and a client program on any other platform (Mac, linux, windows). Since hardware and client are on two different machines, there's no need to haul a laptop out to the telescope setup. This also opens up for remote operations. And it's possible to use a faourite client program.

But, as @LightBucket wrote, if you lose the connection between client and server, you lose the imaging session. By running the (Ekos/Kstars) client software on the same computer as the server, you get a solution that is independent of connection stability.

If you find Ekos/Kstars too demanding for a Raspberry Pi, you need a lighter client, which doesn't use as much cpu resources. I guess this is what LightBucket refers to as the web sequence he is developing. 

 

You swapped the nicknames, but yes, that's what I was meaning :D

 

Share this post


Link to post
Share on other sites
5 hours ago, GuLinux said:

You swapped the nicknames, but yes, that's what I was meaning :D

 

Oops

Share this post


Link to post
Share on other sites
6 hours ago, GuLinux said:

You swapped the nicknames, but yes, that's what I was meaning :D

 

I don’t mind, it makes me look more intelligent.... 🤔

Share this post


Link to post
Share on other sites

I've been using a 64bit ODroid C2 running ubuntu with everything running on it - including astrometry (132GB of SSD based indices)! 

I don't use a seperate client-server topology - instead simply keep it all on one system then remote desktop into it from which ever system over WiFi.

 

Share this post


Link to post
Share on other sites

Yes, that should work. I believe that Jasem Mutlaq from indilib does the same on a raspberry pi. But the odroid should be considerably faster. With this confuguration you're less dependent on wifi stability. But 132 GB in star data? That seems a lot.

Share this post


Link to post
Share on other sites
7 hours ago, NickK said:

64bit ODroid C2

Does the Odroid 64bit now support "real" 64bit working Linux (plus lack of 64bit software) ? - it didn't 2 yrs ago. 

The Odroid N looks like a mighty beast if the price is right - USB3 ,4gb ddr and Sata3 support - plus too early to say if Indi would work but it does use rk3399.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

By using this site, you agree to our Terms of Use.