when I connect my mount USB-serial cable the dmesg output gets appended with:
[ 616.155293] usb 1-1.2: new full-speed USB device number 6 using dwc_otg [ 616.288255] usb 1-1.2: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00 [ 616.288268] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 616.288278] usb 1-1.2: Product: USB-Serial Controller [ 616.288288] usb 1-1.2: Manufacturer: Prolific Technology Inc. [ 616.291691] pl2303 1-1.2:1.0: pl2303 converter detected [ 616.297204] usb 1-1.2: pl2303 converter now attached to ttyUSB0
Also might worth to mention that log messages per device are empty unless I try "LX 200 Basic" driver , it says: "2020-03-25T15:35:48: [ERROR] Error communication with telescope. "
For all other "ETX*" or "LX*" labeled drivers the log on device tab in INDI Control Panel is empty but main Ekos Setup log window just says "LX200 Autostar is disconnected." (i.e. here I tried LX200 Autostar).
I tend to think that it doesn't like RS232-4pin cable from iOptron.
Forgot to mention - I used USB-Serial cable from my iOptron mount. I don't think it should be a problem as it is standard cable and there is the same 4pin socket on Meade hand controller.
So I've got a Meade ETX 90 Maksutov-Cassegrain for planetary imaging, asteroids hunting, camping trips, fun with kids and etc. This one comes with Audiostar hand controller (the speaking one).
Unfortunately, I wasn't able to connect this mount to INDI - tried drivers labeled as "ETX90", "LX200 Autostar" and other "LX*", no luck.
I feel like they've updated a firmware for "Audiostar" line. Please see photo of boot screen in attachment.
Can you advice if it is supported or not?
I will be happy to participate in driver development if it is not supported!
Thank you! Yes, I like that place too - the box is not obstructing any motions or access during polar alignment, and it is just one thing to carry.
Your box looks pretty cool. Active cooling - this is something I will have to think about when summer comes!
Just wanted to give a small update about the "shoe box" project. I bought another more reliable plastic container and got everything nicely secured in my "shoe box", but eventually I gave up with this idea
Mostly because of two reasons:
1. I found that my mount with that box is loaded good above 50% of capacity which is no go
2. The box cracked when temperature was below 0 C
So I decided to go with a different setup - pls see attached. All power supplies are in the box attached with bungee to my mount on counter weight side. The RPI and cables are on OTA.
I think it worked out well - it is pretty tidy and easy to deploy and start alignment/imaging, low budget and works.
Also, I am experimenting with short USB-cables and powered USB-hubs at the moment. You can see them on my avatar picture.
Thanks for showing interest to INDIHUB project, glad you liked the idea and see the potential!
Answering your questions:
- You are right - at this point it is "friend-to-friend" deal at the moment. There is no way to discover other hosts on network at the moment (we will change it soon). We are planing to add directory of hosts where users will be able to "book" time for remote imaging sessions or see things like host's feed of images/equipment/weather forecast/feedback/rank and etc. Please note, hosts won't have to be in that directory but still can contribute images (this is our tool indihub-agent "solo" mode).
- INDIHUB will be processing all contributed images, turning them into data and provide this data as an Open API to anyone interested. Any data set will have a trace pointing to from where that data was extracted (raw images) and how (pipeline of open sourced algorithms). We see INDIHUB as a great resource of data for Space sustainability projects like trusat.org . According to governance - we plan to move in direction where INDIHUB is more decentralized and governed by hosts. Potentially, by utilizing blockchain/Ethereum when INDIHUB web-portal will act as a DApp powered by "open-sensor" nature of INDIHUB (anyone can setup equipment and connect it without asking any permission or any kind of registration).
- Yes, the server side will be open-sourced. I think it has to be open sourced as there are so many ways to process images, I can't even imagine. I think both data acquisition (agent) and data processing (server side) should be open-sourced and powered by people.
Let me know if I missed anything or you have more questions!
Btw, I know about LSF and SatNOGS and have been following your project for a while - I think it is a great effort and initiative!
I think INDIHUB-network is a similar project - we are giving opportunity to contribute to everyone who has a telescope on backyard and desire to contribute.
However, while doing so, INDIHUB as a network will also provide some new astro-photography experiences so hosts can benefit - i.e.:
- remote imaging sessions, so network hosts will have more clear skies, no need to travel with equipment, ability to try other equipment without buying it
- automatic processing/stacking for image sequences
- recommendations for equipment to improve experience and image quality
- hosts will see detailed reports about how the images are used and contributed to discoveries/projects and etc.
Just for the info - the new version of indihub-agent v1.0.3 is released: https://github.com/indihub-space/agent/releases/tag/v1.0.3
- agent doesn't act as a reverse TCP-proxy any more, just connect your INDI-client directly to INDI-server as you usually do
- HTTP RESTful control API added - get status or change agent modes via simple HTTP API without restarting agent
- Websocket API added - open WS-connections to INDI-server from web-apps easily
- broadcast mode is removed as for now - I've realized that it is not that easy to broadcast INDI-traffic properly so any INDI-client can understand it, also user experience flow is not clear so decided to postpone this work
Just to let you know - indihub-agent is open sourced!
Link to the repo: https://github.com/indihub-space/agent
Don't forget to download new release from: https://github.com/indihub-space/agent/releases or from the wen-site!
Particularly filtering of all incoming commands to equipment (in share-mode) will be here: https://github.com/https://github.com/indihub-space/agent/blob/master/proxy/proxy.go#L135-space/agent
Also, please node that syntax of CLI params is changed a bit - the mode is now set by "-mode" param with possible values:
- "share" - open remote access to your equipment via INDIHUB-network of telescopes, so you can provide remote imaging sessions to your guests.
- "solo" - use you equipment without opening remote access but equipment is still connected to INDIHUB-network and all images taken are contributed for scientific purposes.
- "broadcast" - broadcast you imaging session to observers watching it via INDI-clients, in this case without any equipment remote access and sharing (experimental).
- "robotic" - open remote access to your equipment to be controlled by scheduler running in INDIHUB-cloud (experimental).
I.e. to run indihub-agent in solo mode:
./indihub-agent -indi-profile=profile-ABC -mode=solo
According to solo-mode - it is almost pure TCP reverse proxy but allows you to contribute imaging material (to be used for machine learning on cloud side). So in that mode you connect your KStars to indihub-agent proxy listening on `localhost:7426`!
No problem! Hopefully we will see indihub-agent as one of useful (but optional!) components of INDI-stack.
Wow, you observatory looks pretty cool. Now I understand your concerns!
I totally agree - terms and conditions should be covered and described on indihub.space as part of signup application. Also, every observatory should have manual/guide for guests - describing what can be done and what not, so guest can put check mark that manual "was read and agreed". In case of any accidents - we have a full log what was done and guest should be responsible if log shows this. Also, in the future - INDIHUB as a platform might be covering expenses for hosts in these cases (if we ever get any funds for this).
I think it is a good idea about owner of the observatory having this "sign"/"tick" to acknowledge that equipment is ready. In fact indihub-agent must prevent sharing-mode completely if this option is not set by owner as "ON". At the same time I believe we have a great capabilities to protect equipment - in ideal case owner should easily configure how observatory can be used.
Good point about nightly INDI/Ekos builds - sharing equipment must be available only on latest stable release!