Hi Durval,

I tried both Zero and Zero(w) with the same result.

I also tried "overclocking" CPU AND SD card but I didn't use a "fast" SD card(Samsung or Scandisk 99mb transfer rates) - just a std cheap SD card but still,IMHO,too slow when Ekos was used!

Without Kstars/Ekos but GUI running it was just usable even over VNC but no Astro stuff - except for the WiFi drop outs (there was a bug on early Zero(w) I believe ).

Extra memory always helps so 512mb is the limiting factor I guess - didn't do any bench marking as it was a "i winder if it will" moment.

Read More...

"I do not read manuals!" - nobody did before 1990's and electronic bullitin boards (pre cursor to Internet) - as by the time the "manual" and the associated pages of "updates" arrived by POST (thats the old fashion letter type) you had figured it out and the manual/updates were out of date anyway - LOL. Bit like Wright brothers - ok maybe not!

Like you write up - nice one.

Read More...

Tried to use PI Zero so slightly better than the PI you are using - findings

1. Zero with GUI and mount control plus DSLR using Ekos runs but very very very slow.

2. Zero with NO GUI and just running Indiserver to control the above but with everything else (Ekos or whatever) running on another device (old Vista Laptop) ran better but as Zero (default) has only WiFi it wasn't very reliable.

3. Zero as (2) but just used to control mount and Long USB cable to camera it was fine but again Wifi not reliable.

So I guess in short if you want everything "yesterday" then the answer is no chance, if you can put up with slow response but relying on WiFi then (2) will work depending on your camera/resolution etc.

But there again if you have no other option and are bored during lockdown (whereever you are) try it out - at least its something to do (and learn)

Read More...

It may help :

1. I Use one in Obsys like attached picture - it uses either Wifi or Wired (I use wired) but the wifi can act as an AP see below abount comment on network usage

2. I would not,IMHO, use it on the Indi Attached PI Wifi network or attached directly to your PI as it will/could have a direct effect on your processing power and Network performance. USB Web cams have the same effect plus power usage.

3. Mine does have a Infra red LED's so you need to switch it off during actual imaging. So maybe the good old Analogue Samsung 435 I used to use was better as it didn't have the LED's

4. Its useful to watch the clouds approaching LOL when you wonder why your image is suddenly poor!

You can get the "baby Cams" which again use Wifi or Wired and if using Wifi just need power supply (mostly 12v) or perhaps one the DIY ESP32 web server cams www.instructables.com/Getting-Started-Wi...Streaming-Video-Usi/ , PI Zero (or other) with PI CAM noir - last 2 not going to get HD quality - if reqd.

I find mine useful in many ways .

Read More...

Hi Jasem,

I realise there are many drivers (for all sorts of devices) but I was thinking more in the line of a few "Indi Standard" generic devices - one per type maybe - that people can test there devices against before writting a new Indi driver (may not need too as the Standard Generic might be spot on). They may even use the Generic protocol therefore saving more devices to support. Lets face it for example a standard Focuser is a focuser and cant really function very differently even if the "commands" are different . Might also save a lot of unneccessay duplicated documentation which people sometimes hate to do .

Again just a thought

Read More...

Why doesn't Indi provide basic "generic" drivers for most devices that would allow developers, such as the above, to "bend" there devices to fit. Yes some functions within a driver will have to be dummy actions but providing a generic driver allows quick conversion of existing non Indi devices. Longer term they can then be improved.


Just a thought!

Read More...

I will be looking at you MQTT implmentation with interest as I use MQTT regularly. However there is no way,IMHO, "Blobs" of any size will (or should IMHO) use MQTT. Trying to send Blob's does one of two things

a. Stops (OK to a trickle) all other MQTT traffic as you have to set buffers so large to get the Blob transfer within a reasonable time.

b. Using smaller buffers ,i found , just means very very long download times (Note my testing was with RPI acting as a Broker and using Python clent on Windows as receiver, RPI as a client as the Publisher ).

The above does depend on file sizes and small JPG would be fine!

Most other devices,i have have used, work pretty well except for a few devices (but really thats down to driver protocol problems - e.g. Moonlite focuser protocol and the temp reading times out too quickly!)

An alternative maybe,would be to just send the file name(and associated IP address or DNS name) of the Blob and/or initiate another protocol to broadcast/stream the file.

For Internet or distributed Indi I think MQTT has a few advantages IMO - all local working(one SCB) not really IMO.

Nice One

Read More...

Surely a simpler method without coding would be to use the "inbuilt" networking ability of Indi (e.g. chaining).Then ,perhaps using the newer Compute 4 (they have EMMC storage) RPI's, create a dedicated Large Cmos Camera server but using "command Line" Indiserver only (NO GUI,System X) to maximise resources .

The initial capture(s) could be stored on these dedicated Large Cmos servers and transfered in "background" mode so not to effect camera capture speeds. Any conversion could then be done on the "other" Indiserver(s) which would have had resources freed by moving the Large Cmos camera.

I accept this would mean extra hardware (RPI's)/networking(wired hub unless you rely on 5GH wireless) hardware costs,perhaps slower image viewing due to transfers but it would be with the minimal amount of software changes to existing Indi structure - until 64bit drivers are created.

Just an Idea !

Read More...

My take / experience - The Astroberry panels (left hand side browser screen) start the Indiserver on the machine as addressed in the browser( DNS/Hosts or IP). So normally this is a remote machine but can if you start the browser on the remote machine, via say VNC, and input 127.0.0.1 then the Indiserver is started,if using Panels, on the "Local" machine.

OK thats daft i hear you say - well not entirely if you dont use Kstars/Ekos or dont use/load the GUI desktop on the remote machine as this still enables you to start your indiserver with the correct "Astroberry" profile (and connect / start/restart via the left Panel in you browser. Not using the Linux Desktop saves resources if you wish to use something like CCDCIEL or CDC(remotely) which will happily talk to 1 or many Indiservers at the same time.

However if you use Kstars/Ekos then as soon as you choose a profile and connect etc Ekos see's Indiserver is already running hence the message you get so long as the profiles match there shouldn't be a problem and you can answer YES to use the existing Indiserver as Kstars/Ekos should just connect to the drivers already loaded so long as the drivers chosen in the profiles are the same.

Last time I asked Radek I think he said the profiles(Ekos/Astroberry panels) were completely separate but this may have changed.

One could argue rightly,in my view, that it would make more sense,if you are to use Kstars/Ekos on the remote machine via VNC, just to start Indiserver from Kstars/Ekos on the remote machine (the one you are VNC'ing too) and not use Astroberry Panels to select and start a profile/Indiserver.

Radek will correct the assumptions that are incorrect - though most are based on actual usage

Read More...

IMHO its a possible bug in the driver - i have the same issue but if i go into indi settings and disconnect the driver and then reconnect immediately it connects no problem. Might be a timimg issue in the driver as the driver behaves without issues after that. Note I am NOT using Ekos but using CCDCIEL remotely so is not exactly the same as the Orig Thread creator.

This assumes that everything else is correct in the authors set up - cables,power etc etc.

Read More...

In the UK Lindy(and EU) sell good quality cables which I have not had problems with and have worked where others have failed - abd unfortunately they cost more - www.lindy.co.uk/cables-adapters-c1/usb-c449/usb-3-1-c1533 They have been around a Looooong time

Read More...

Ask Robert Brown (author) directly on sourceforge.net/projects/arduinoascomfocuserpro2diy/ if no answer here

Read More...