Get Connected!

Come and join our community. Expand your network and get to know new people!

View All Events
Derek created a new topic ' Teamviewer: commercial use detected' in the forum. 15 minutes ago

Anyone out there use team viewer to manage a remote site? I use it to remote-desktop into the observatory PC which runs Kstars.
A couple of days ago I got a popup saying "commercial use detected" and its prompting me to buy a licence. I thought I should pay but its actually pretty expensive and I'm not sure I qualify as commercial use. The observatory doesn't make any money :-)

Anyone else get this? Are there any alternatives?



Wolfgang Birkfellner replied to the topic 'ttyUSB0 issues on OnStepp and raspi4' in the forum. 34 minutes ago

well - the strange thing is that two device claim ttyUSB0, this has to be in the udev rules. otherwise, you should see ttyUSB0 and ttyUSB1 ... bluetooth is a last resort, rather. maybe you can find out which other device also has a CP20xx built in (they are very widespread). that might be a first step ...
yours wolfi


Clive Stachon replied to the topic 'uploading images to remote (client?)' in the forum. 2 hours 10 minutes ago

A non intrusive way to transfer files using Samba and Windows can be provided by any number of Windows "Sync" programs - One such example provided by a Microsoft employee is Robocopy - there are plenty of others too (some not free) . They will not impact on your network is its decent (5ghz 700mb or preferably a wired GB connection.

There is also Synctoy also from Microsoft and Fastcopy - the latter is supposedly very good large files copy but I have no experience of Fastcopy.

its free so you can give it a try and see if it has any effect - seem to remember it had a GUI that also allowed "priority" setting to not effect your network

So long as you can see the directory where your images are stored you can use the above.

Slow network then use a Windows formatted USB3 SSD drive.

I think that is what you were asking for :-)


Steve Fox replied to the topic 'Serial Timeout with Moonlite Focuser' in the forum. 3 hours 29 minutes ago

I have the same problem with serial timeout errors with the Moonlite BUT the focuser on my setup doesn't work at all, i.e. it doesn't move on command - see log file below. It used to work ok and I've not _consciously_ changed anything! I've done a bit of troubleshooting - I'm on a MacBook Pro running Catalina 10.15.2 with Kstars 3.3.8. The log file below is from a debug session when attempting to move the focuser. Everything appears ok in that the messages seem correct but the focuser hasn't actually moved. The slip clutch is correctly tightened and the focuser works fine in a Virtualbox VM running Windoze 10 and the Moonlite non-ASCOM utility, and it moves to the correct positioning when instructed, just not when using indi - this indicates to me that the USB-serial driver is operating correctly. I don't know whether the serial timeout errors are connected with the focuser not moving or a just a red herring. I really don't want to be running a whole VM just to operate the focuser - please help!

INFO 0.005846 sec : Session log file /Users/sjf/.indi/logs/2020-01-21/indi_moonlite_focus/indi_moonlite_focus_13:19:49.log
DEBUG 0.589597 sec : Connecting to /dev/cu.usbserial-AH0741BL @ 9600
DEBUG 0.595000 sec : Port FD 3
DEBUG 0.595055 sec : Connection successful, attempting handshake...
INFO 1.621624 sec : MoonLite is online. Getting focus parameters...
INFO 1.621717 sec : MoonLite is online.
DEBUG 1.622472 sec : Configuration successfully saved for DEVICE_PORT.
DEBUG 1.623259 sec : Configuration successfully saved for DEVICE_BAUD_RATE.
DEBUG 1.623954 sec : Configuration successfully saved for CONNECTION_MODE.
DEBUG 1.624754 sec : CMD <:GP#>
DEBUG 1.636696 sec : RES <0CDC#>
DEBUG 1.637842 sec : CMD <:C#>
DEBUG 1.638346 sec : CMD <:GT#>
DEBUG 1.652646 sec : RES <FFB8#>
DEBUG 1.653716 sec : CMD <:GD#>
DEBUG 1.668746 sec : RES <02#>
DEBUG 1.670760 sec : CMD <:GH#>
DEBUG 1.684650 sec : RES <00#>
INFO 1.685278 sec : MoonLite parameters updated, focuser ready for use.
DEBUG 1.685359 sec : Toggle Debug Level -- Driver Debug
DEBUG 2.124542 sec : CMD <:GP#>
DEBUG 2.147706 sec : RES <0CDC#>
DEBUG 2.148503 sec : CMD <:C#>
DEBUG 2.148857 sec : CMD <:GT#>
ERROR 5.150571 sec : Serial read error: Timeout error.
DEBUG 5.152576 sec : Toggle Debug Level -- Driver Debug
DEBUG 5.152615 sec : Toggle Logging Level -- Driver Debug
INFO 5.152642 sec : Session log file /Users/sjf/.indi/logs/2020-01-21/indi_moonlite_focus/indi_moonlite_focus_13:19:49.log
DEBUG 5.153272 sec : CMD <:SF#>
DEBUG 5.153383 sec : Configuration successfully loaded.
DEBUG 5.653010 sec : CMD <:GP#>
DEBUG 5.678123 sec : RES <0CDC#>
DEBUG 5.679221 sec : CMD <:C#>
DEBUG 5.679852 sec : CMD <:GT#>
ERROR 8.683086 sec : Serial read error: Timeout error.
DEBUG 9.189409 sec : CMD <:GP#>
DEBUG 9.208189 sec : RES <0CDC#>
DEBUG 9.209259 sec : CMD <:C#>
DEBUG 9.209836 sec : CMD <:GT#>
DEBUG 9.224254 sec : RES <FFB8#>
DEBUG 9.729849 sec : CMD <:GP#>
DEBUG 9.751508 sec : RES <0CDC#>
DEBUG 9.753162 sec : CMD <:C#>
DEBUG 9.753699 sec : CMD <:GT#>
DEBUG 9.767570 sec : RES <FFB8#>
DEBUG 10.273960 sec : CMD <:GP#>
DEBUG 10.294702 sec : RES <0CDC#>
DEBUG 10.296336 sec : CMD <:C#>
DEBUG 10.297073 sec : CMD <:GT#>
DEBUG 10.310490 sec : RES <FFB8#>
DEBUG 10.813842 sec : CMD <:GP#>
DEBUG 10.837936 sec : RES <0CDC#>
DEBUG 10.839679 sec : CMD <:C#>
DEBUG 10.840579 sec : CMD <:GT#>
DEBUG 10.853849 sec : RES <FFB8#>
DEBUG 11.359650 sec : CMD <:GP#>
DEBUG 11.380931 sec : RES <0CDC#>
DEBUG 11.382562 sec : CMD <:C#>
DEBUG 11.383194 sec : CMD <:GT#>
DEBUG 11.396870 sec : RES <FFB8#>
DEBUG 11.898703 sec : CMD <:GP#>
DEBUG 11.923818 sec : RES <0CDC#>
DEBUG 11.924885 sec : CMD <:C#>
DEBUG 11.925430 sec : CMD <:GT#>
DEBUG 11.939881 sec : RES <FFB8#>
DEBUG 12.444137 sec : CMD <:GP#>
DEBUG 12.467019 sec : RES <0CDC#>
DEBUG 12.468277 sec : CMD <:C#>
DEBUG 12.468893 sec : CMD <:GT#>
DEBUG 12.482940 sec : RES <FFB8#>
DEBUG 12.987349 sec : CMD <:GP#>
DEBUG 13.010051 sec : RES <0CDC#>
DEBUG 13.011122 sec : CMD <:C#>
DEBUG 13.011629 sec : CMD <:GT#>
DEBUG 13.026001 sec : RES <FFB8#>
DEBUG 13.528378 sec : CMD <:GP#>
DEBUG 13.553076 sec : RES <0CDC#>
DEBUG 13.554083 sec : CMD <:C#>
DEBUG 13.554610 sec : CMD <:GT#>
ERROR 16.555771 sec : Serial read error: Timeout error.
DEBUG 17.056871 sec : CMD <:GP#>
DEBUG 17.067395 sec : RES <0CDC#>
DEBUG 17.068458 sec : CMD <:C#>
DEBUG 17.069020 sec : CMD <:GT#>
DEBUG 17.083316 sec : RES <FFB8#>
DEBUG 17.585430 sec : CMD <:GP#>
DEBUG 17.610838 sec : RES <0CDC#>
DEBUG 17.613126 sec : CMD <:C#>
DEBUG 17.614309 sec : CMD <:GT#>
ERROR 20.614740 sec : Serial read error: Timeout error.
DEBUG 21.117363 sec : CMD <:GP#>
DEBUG 21.140707 sec : RES <0CDC#>
DEBUG 21.141801 sec : CMD <:C#>
DEBUG 21.142421 sec : CMD <:GT#>
ERROR 24.143032 sec : Serial read error: Timeout error.
DEBUG 24.143766 sec : CMD <:SN0000#>
DEBUG 24.144436 sec : CMD <:FG#>
INFO 24.144512 sec : Focuser is moving to position 0 <--- It is currently at position 3292 which is correctly displayed in the Focus module
DEBUG 24.644759 sec : CMD <:GP#>
DEBUG 24.654891 sec : RES <0CDC#>
DEBUG 24.656314 sec : CMD <:C#>
DEBUG 24.657006 sec : CMD <:GT#>
DEBUG 24.670921 sec : RES <FFB8#>
DEBUG 24.672463 sec : CMD <:GI#>
DEBUG 24.686930 sec : RES <00#>
INFO 24.687801 sec : Focuser reached requested position. <--- Everything appears ok but the focuser hasn't actually moved!
DEBUG 25.188753 sec : CMD <:GP#>
DEBUG 25.213879 sec : RES <0CDC#>
DEBUG 25.214851 sec : CMD <:C#>
DEBUG 25.215368 sec : CMD <:GT#>
DEBUG 25.229836 sec : RES <FFB8#>
DEBUG 25.732975 sec : CMD <:GP#>
DEBUG 25.756937 sec : RES <0CDC#>
DEBUG 25.758225 sec : CMD <:C#>
DEBUG 25.758801 sec : CMD <:GT#>
DEBUG 25.773024 sec : RES <FFB8#>
DEBUG 26.277202 sec : CMD <:GP#>
DEBUG 26.300106 sec : RES <0CDC#>
DEBUG 26.301145 sec : CMD <:C#>
DEBUG 26.301632 sec : CMD <:GT#>
DEBUG 26.316032 sec : RES <FFB8#>
DEBUG 26.820430 sec : CMD <:GP#>
DEBUG 26.843187 sec : RES <0CDC#>
DEBUG 26.844274 sec : CMD <:C#>
DEBUG 26.844816 sec : CMD <:GT#>
DEBUG 26.859172 sec : RES <FFB8#>
DEBUG 27.361538 sec : CMD <:GP#>
DEBUG 27.386445 sec : RES <0CDC#>
DEBUG 27.388083 sec : CMD <:C#>
DEBUG 27.388850 sec : CMD <:GT#>
ERROR 30.392654 sec : Serial read error: Timeout error.
DEBUG 30.897912 sec : CMD <:GP#>
DEBUG 30.916538 sec : RES <0CDC#>
DEBUG 30.917649 sec : CMD <:C#>
DEBUG 30.918134 sec : CMD <:GT#>
ERROR 33.918501 sec : Serial read error: Timeout error.


Steve Crossman replied to the topic 'Nikon DSLR conflict' in the forum. 3 hours 54 minutes ago

Jasem, this is the same issue I reported to you about 2 months ago with the D7500 where it would switch to JPG fine, which prompted you to get the D3400 for testing.

I found that using NEF + JPEG normal in the camera would enable it to save as NEF. Selecting just NEF would result in it switching back to just JPG fine being saved to the SD card in the camera.

The setting in the INDI control panel would reflect very odd characters.


Wouter van Reeven replied to the topic 'uploading images to remote (client?)' in the forum. 4 hours 13 minutes ago

I'd advise you to let Ekos store the images as close to the camera as possible, meaning on the RPi hard disk or a USB drive attached to it. Transferring large files over a network connection (and in this context 32 Mb is pretty large) introduces a latency since Ekos will wait until the image has been stored. Is there a specific reason why you want them transferred automatically? If it is for inspection, for instance, then I'd advise to install some image viewer on the RPi and inspect them there via VNC. If it is for processing then you might as well wait until all images have been taken but that's up to you of course.



Paul replied to the topic 'uploading images to remote (client?)' in the forum. 4 hours 14 minutes ago


what you have to try:

- make a shared folder on the windows pc
- on the raspberry mount that shared folder to a local folder (google access windows folder from Linux, that will show several ways, but i donr't know if all of them are correct ...)

Then in the kstars that directory should be used in kstars. Files will then automatically to the windows directory.



Ronald Scotti replied to the topic 'uploading images to remote (client?)' in the forum. 4 hours 41 minutes ago

ok, I am running the Astroberry Server on the Rpi and I access it by through a Chrome webpage on the Desktop which is Windows 7. Or I could access thru VNC. I have set up Samba on the Rpi and I can physically move the files myself from the Rpi to the Windows machine, but I was looking for a way to do it automatically. Perhaps being able to run a background program (like an ftp command) on the Rpi after it captures a (scheduled) image, so the image files moved off the Rpi.

I have a 32 Gb SD in the Rpi, so having the images on it is probably not a big deal for any nights work. I just thought I was missing something in the setup.



Pep replied to the topic 'ttyUSB0 issues on OnStepp and raspi4' in the forum. 4 hours 47 minutes ago

Hi wolfi,

I'm sorry but today raining a lot in my country and I can't acces to the "dome" (a way to named my telescope covert)

When I can access to the telescope I 'll try it.
At the moment I attach another picture where you can see that really there are two devices on ttyUSB0, device with serial number 0001 is the onstey device.

For other hand, I lisent that is possible to use a Bluetooth like a serial port in astroberry... Then could connect onstep by bluethoot, doesn't it? But I don't know how to do it. Some one know how to do it?


Mr Jacques Prince replied to the topic '1.4.6 release - impressions, problems, etc. Please post.' in the forum. 6 hours 2 minutes ago

ar2star2 wrote: Jaq,
Install Real VNC Viewer on the Windows machine, connect the Pi to your home network and run everything on the Pi4 it is more than capable. You can also put Real VNC Viewer on your phone or tablet & monitor the progress there if you like.

I personally found that the guiding performance wasn’t as good when using it as a server client set up due to lag over the network, unless I ran PHD2 directly on the Pi via the ST4 cable. But that’s a bit of extra work to start PHD2 before you connect the server, again this can be done over VNC if needed.

I found I don’t need a static IP on the network just use the address shown in the Stellarmate tutorial video Stellarmate.local I think from memory.

At least doing it this way you’ll get results.

Try it first with the simulators, then connect the other equipment 1 item at a time and make sure it works before saving the configuration, then shutting down and restarting the Pi before connecting the next item. Doing things this way helps isolate problems with an individual piece of kit.

Good Luck


Hi Alan

Your giving me a little ray of hope. Ill try this. Tell me one thing... Wireless connectivity: If using VCN on my laptop is there any difference if i use it via home network or hotspot. I would have thought the latter was more direct and more stable?




Paul replied to the topic 'uploading images to remote (client?)' in the forum. 6 hours 8 minutes ago

Yes that is correct, but will only work if Kstars is run on the desktop computer. (For VNC / RDP it will be different)



AstroNerd replied to the topic 'uploading images to remote (client?)' in the forum. 6 hours 33 minutes ago

CapnRon wrote: I am running the Astroberry Server on an Rpi-4 and I am accessing the server from a desktop in the house over ethernet to the Rpi-4. Is it possible to only capture and upload the images to the 'remote' desktop so they don't stay on the Rpi? I have tried "Upload" - Local with the Remote window showing this: //Ron2012PC/users/ron/temp (a shared directory in the desktop). But this does not work. I have also tried giving it the remote computers IP address on the local home network and that does not work. It seems like the intent of this File Setting is to do what I am asking, but I cannot figure out how.


You need to set ekos to upload to “client” and not remote, as the rpi is the remote device in your set up, and your PC is the client....there is a setting in ekos for this... :)


Thomas Pfenninger replied to the topic 'Guiding calibration with too small star movement' in the forum. 8 hours 11 minutes ago

I will try this tonight, also to connect with the experimental driver.

Do you tend more towards a problem with the mount itself than to a problem with software?


Paul replied to the topic 'uploading images to remote (client?)' in the forum. 8 hours 26 minutes ago


depends on how your setup is.
- What OS is your desktop machine
- Kstars on desktop machine and remote indi. ( Thats easy, just configure upload to client)
- Acces by VNC or RDP to the rpi its get more complicated. (If both systems are Linux setup nfs and share a directory, if it is windows you will need to set up samba on the pi to get access to a shared folder on the windows pc, but that can take lot of experimenting)



Jasem Mutlaq replied to the topic 'Guiding calibration with too small star movement' in the forum. 8 hours 29 minutes ago

Yes it should be the same... so if the mount moves with these pulses then maybe it's not moving enough? or there is some backlash issue? At night, find a star and then issue these commands and see if you can notice somewhat noticable motion. The guide calibration only needs few pixels of motion in both axis to recognize the trend and calibrate correctly.


Thomas Pfenninger replied to the topic 'Guiding calibration with too small star movement' in the forum. 8 hours 32 minutes ago

No, I try try this, but I will do it tonight.
What I did is moving the mound with the direction buttons in the manual guide module in PHD2. These buttons send a pulse command and the mount actually moves. The implementation of the lx200AP driver limits the pulse length to 999ms but I could see the coordinates change when I clicked to any of the direction buttons. The move was very small but I could see (and hear) that the mount moves.
Are these buttons in PHD doing the same as the direction buttons in INDI's guide tab?


Jasem Mutlaq replied to the topic 'Guiding calibration with too small star movement' in the forum. 8 hours 41 minutes ago

Right, if you go to the GUIDE TAB in the driver in INDI Control Panel and enter some pulses there manually then press SET, do you see any changes in the RA/DE coordinates? for example, set NORTH to 3000 and press SET, the DEC should slightly change. Do you see that?


Thomas Pfenninger replied to the topic 'Guiding calibration with too small star movement' in the forum. 8 hours 44 minutes ago

I tried it once or twice to connect with the experimental, but I remember that I was not able to connect my mount (but I don't remember the log messages anymore).
As far as I know, I should not use the experimental driver with my mount with the CP3 controller. Is this wrong? My controller is more than 10 years old...


Jasem Mutlaq replied to the topic 'Guiding calibration with too small star movement' in the forum. 8 hours 49 minutes ago

Did you try LX200 AP Experimental driver?


Thomas Pfenninger replied to the topic 'Guiding calibration with too small star movement' in the forum. 9 hours ago

I forgot to mention an important detail: I use a MacBook with macOS catalina to run Kstars, PHD2.