stash_old

1 minute ago, Gina said:

I gather Node-RED just sets up links.

it does send messages for a Topic - see the properties of the MQTT Output node there is a topic - node.red produces a message payload in what ever format you want

36 minutes ago, Gina said:

Could this be the problem - the output switch has no topic?  Or does the connection (link) do that?  I think I need to read up on Node-RED.

Not if you put one in the MQTT output else it uses the topic in switch to produce msg.topic - cant test MQTT right now but my test switch (with or without Topic) works

be careful of retained messages and QOS there are 3 types of broker working QOS -  retain message  https://community.openhab.org/t/clearing-mqtt-retained-messages/58221

QOS - https://assetwolf.com/learn/mqtt-qos-understanding-quality-of-service

If the Arduino end isn't printing on or off recvd then Node-red isn't

1. Sending the message at all - bit like (3) Broker would never get a message and MQTT EXP wouldn't see it either

2. The Topic is wrong - the MQTT explorer log should show the message from Node-red but the ESP would never get it

3. The output MQTT details(host address) on the switch leg is wrong - here the message would not even be seen by the broker and therefore nothing would get the to the ESP.

For 1 & 3 you need to see if the Node-Red status when you flick the switch in case it throws up an error. Plus you can send a message from the MQTT EXP simulating the switch message to see what the ESP does with it.

5 hours ago, Gina said:

Does anyone here use Node-RED and how useful do you find it?

Yep I do and its a fast RAD (Rapid App Dev) once you get used to how it works (like all things new) - like all RAD's you work with it and its ways of doijng things. Once mastered you can write Javascipt stuff as well. Hint get the ESP working first and showing data in correct packet format - JSON or RAW. Node-red "connected" just means that its talking as a client to the broker you have set up. Use the "Message" node you have to display the format ,type and content of data. I always find a quick send from MQTT-explorer can quickly test out what is or isn't working -  normally mistakes I make is to have one end RAW packets and the other expecting JSON format. First you need to make sure that your "TOPICS" are the same else clients will not speak to each other but MQTT-explorer will help there as you should see the data including TOPIC headers. There is a "catch-all" topic (top of the message tree) which will show ALL TOPICS going thru the broker and "Wildcards" - read this might help http://www.steves-internet-guide.com/understanding-mqtt-topics/

Just now, lw2689 said:

Astroberry panels? I am just using Ekos to set it up. I have no idea how to use panels, i couldn't find anything on the the desktop to do it. 

I tried that command but it wouldn't run 😕

The panels only appear if you use the Astroberry Web access to start Indiserver etc - sounds you are not using them!

Oops  ls -la /dev/*.* >>$HOME/dev-devicesnodes.txt  and perhaps just in case your permissions are all shot use sudo  ls -la /dev/*.* >>$HOME/dev-devicesnodes.txt 

1 minute ago, JamesF said:

I have a nagging feeling in the back of my mind that those messages about the MTP device might be relevant (MTP is for transferring media from portable devices I believe).  It could be that because Linux thinks it might be an MTP device and checks to see if it is that the normal path to install a serial driver fails.  I think I had the same problem some years ago and can't remember the context at the moment.

James

This maybe https://github.com/raspberrypi/linux/issues/2692

3 minutes ago, Stuart1971 said:

Actually I think you have hit the nail on the head there.....there is an issue and I think it’s affecting all converters....even more so when plugged directly into the RPI, seems better when a powered hub is used... 👍😀

Must have "grown" since I last looked! - Dont suppose you have a older SD card set up of Astroberry (not sure if the older images still exist on Radeks site) - like 1 month older. If you have this should be ok so long as you  dont do any updates.   OR

Try the fix KNRO has in this fix which seems to work for some people - but I stress they were all FDTI chips not "Others" unless you have a FDTI chip thats not being shown - so do at your own risk 😞   fix was

sudo rpi-update e1050e94821a70b2e4c72b318d6c6c968552e9a2

Are you using Astroberry panels first to set up and connect to your devices - if not try this method first and Ekos should say something like "Indiserver already started terminate" - dont terminate - i.e. NO Ekos should still load and show profile

Also do a ls -la /dev/*.* >$HOME/dev-devicesnodes.txt - then look thru for any USB device drivers. It will/should be long list!

Note their is a bug in latest Raspbian kernel  (on Indilib) with USB converters but I though it was just FDTI driver permissions - last time I looked

And when you have done Gina build one of these - https://create.arduino.cc/projecthub/brettoliver49/arduino-barometer-eb5bdd

15 hours ago, lw2689 said:

I wanted to see if it was the RPi causing the problem or the mount. Turns out it is the RPi. I have installed Kstars and ran EKOS the same as I would on RPi but on my Mac. It instantly picks everything up and I am able to control the mount and see the camera. On the Mac it looks like the below and the connection is green.. 

However on the RPi it looks like the below, with the error in the box. 

 

 

Change the logging ,rerun and dump the logs and flag it as an poss error on Indilib - does seem strange. Does this happen on the RPI when nothing but the mount is connected ?

4 hours ago, pete_l said:

Linux is not good at handling USB

Its not the fault of Linux but the USB device which either does not provide a unique serial number when using the same USB type device.

Udevadm / port mapping is normally a simple process UNLESS you have the above stated problem. As @Stuart1971 has already stated Ekos provides Serial Port Mapper which is only needed normally once after which its is far more stable than Windows.

14 hours ago, wimvb said:

The general problem in the maker society is that many tutorials and code are proof of concept, but still far away from stable ”production” versions. Software solutions may work in a specific configuration, but not generally.

Have to disagree I am afraid the "maker society" is no different than other tutorials with proof of concept. However systems like Home Assistant and many more IOT or Maker systems are just like Indilib or Ascom - created and well supported by open source developers.

While I agree that for a MQTT broker the ESP32 would not be suitable, running a simple low usage Web Server on a ESP8266 or the later ESP32 is perfectly feasable - I .like many applications  , use one to configure initial "comms" on both ESP type with no problems and it is reliable. However some "ESP" modules are better than others - I use "real" Wemos devices which I have found to be very good.

Lets face it there is nothing perfect in this world and IT is no different.

Good luck to Gina and enjoy the project - just let me know when you have  a Talking interface to your Astro set up LOL

If your really get the automation bug    https://www.home-assistant.io/                                          

IMHO run the broker on a "good" SBC (PI's > zero work for me never failed - touching hodd at this point LOL ) and plug that into a main network via the ethernet and let your network AP's do all the hard Wireless work - they have a better beam spread anyway and the device is acting as a central point(i.e. Broker running). I do tend to always have 2 matching sd cards just case one dies or I screw up the settings/software.

Dont know why older PI's are still holding there price but £B's are to be had for about £24 on Fleabay https://www.ebay.co.uk/itm/Raspberry-Pi-3-Model-B-Board-Quad-Core-1-2GHz-64bit-CPU-1GB-Ram-Wi-Fi-Blueto/114349459091?epid=2084942669&hash=item1a9fc24693:g:~f0AAOSw5J1fMUju

14 hours ago, lw2689 said:

I have the older Nexstar controller

Check the firmware as  Indi Devices  specifically states the firmware in the hand controller must be at least version x.y.z  https://indilib.org/telescopes/celestron.html

Used anMQTT set up on PI 3B (notplus) for 3 yrs very reliable - I suggest someting like MQTT-Explorer-0.3.5.exe for Windows and I forget the Linux equiv - very useful for testing/trouble shooting - especially Topic names and the dreaded "/" or "\". Plus watch out for security in MQTT broker which was a bit hot and miss (3yrs ago).

I used Node-red as the server (also on the MQTT PI) which simplified development(hrs not days to produce working web based GUI's) as many dials,charts etc all exist but there are plenty of ready made IOT for the home that incorparate weather coding plugin's (but dont need the Internet).

P.S. Unless Indigo developers have corrected the problem it will not do exposures with DSLR above  55secs https://github.com/indigo-astronomy/indigo/issues/220

4 hours ago, AstroRookie said:

Hello endlessky,

I have KStars/EKOS installed on my macbook and it is really very impressive and for a rookie a bit overwhelming, it has everything: planning, capturing, guiding and even plat solving. Cloudmakers Indogo-server is simple and fairly straightforward, but I'll try some "dry-runs" with KStars/EKOS. As for plate solving, I wonder if that is possible with a Canon 500D dslr, as it is not possible to have Live-view in combination with my slow F/10 sct (I have to be honest reduced to F/6.3 with a 63% ocal reducer). I admit, AstroRookie's first step in astrophotography is on a tight budget.

Kind regards,

AstroRookie

If using DSLR you dont need to use any index's as such but look at ASTAP (runs on Linux(RPI etc) ,Win,Mac) and only requires 1 index file normally. It is also the fastest "near" platesolving piece of software if not 100% reliable for "blind Solving". E.G  AZEQ6 + C9.25 + Canon 100d regularly gets <6 secs solve time depending how good you slews are. It is also intergrated into Ekos/Kstars.  Just a thought:-)

2 hours ago, endlessky said:

Also, does the KStars/EKOS suite work on OS X? If you want to abandon Windows

He already has - Indigo (specialiality Cloudmaker is mainly Apple oriented) is from the same camp as Indi . Indigo can use Indiserver devices. 🙂

4 hours ago, AstroRookie said:

thanks for the advice; I'm using Indigo-server because I'm to stubborn to use windows

You missed my point or I didn't explain myself (most likely me !)  - there are very few "Pure" Indigo users on SGL -  so direct Indigo knowledge would be limited. Hence my pointer to look on Indigo forum for help where you should get a better informed answer to your query and as far as I am aware no Indigo author frequents SGL (unlike Indi Forum) . 🙂

Post the question on Indigi Forum site as it depends on the mount driver / alignment subsystem and has nothing to do with CDC (other than it send the sync command). Dont think many here will be using Indigo server and its not that close to Indi in a lot of aspects.  https://github.com/indigo-astronomy/indigo/issues

FYI Note - if you are going to use 2 or more different FOV then take note of the index's for each FOV as having all the files (some 4.9GB) slows down the solving. e.g. Store all the Index's in a separate folder and amend the Astronmetry.net index folder to only contain the correct Index's for the FOV required by the Lens being used. This could make the difference between 20+ secs and 9 secs platesolving.  Also take a look at ASTAP to see if its compat with Cloudmakers (i.e. Indigo) - note Cloudmakers software has its own Index manager (to select the correct Index's) so you dont need to use ASPS Index wizard and I guess you will be running on Apple OS (MACOS) of some description anyway.

Used to but have "progressed" LOL

From what you have written I would suggest that the Ascom driver  for your version of the camera is either not loaded or the connection is faulty.

You say using Atik s/w works with the camera so one can presume that the cable /camera is ok.

Have you tried using Sharpcap or APT to verify the the correct Atik Ascom driver is loaded as it could be Astrotilla is at fault as it has not been updated for a fiar time and maybe is no longer compatible with the version of Ascom. If you use Sharpcap or APT (free mode) and they work with Ascom driver for your camera then it would look like Astrotortilla is at fault.

If none of the above work with your camera then talk to Atik they may be of some help.

Altermative is to use Sharpcap/APT or others which ,if they work in the above test, will give you Platesolving.  Bear in mind Astrotilla uses the same platesolving  backend as 80% of the platesolving out there - all based on Astrometry.net/Cygwin. ASTAP and Platesolve2 dont but do not have a direct Ascom interface - i.e. you would have to load the the image into the software and then platesolve. 

I forgot ASPS does have an ASCOM interface and as its uses Cygwin you can use the same index's - it would also test the Ascom interface for your driver  - IF LISTED

Hope that helps!

Well that all depends - I have started experimenting with narrow FOV EAA (already did EAA before) with a slow F10 /fl2350 scope and small sized chip CMOS camera - I get images(not great quality) on bright DSO's very fast <15secs BUT there is no way I could stack the images in real time as the movement is too great due to the narrow FOV and movement. So in this case guiding would help but then I am not looking for high quality Astro Pic's.

It depends what you are looking for - if its Astro high quality DSO images then unless you are prepaid to pay mega bucks for your kit then stick to normal Astrophotography IMHO. I am old school and still believe there is  a major difference between EAA and "Normal" Astrophotograhpy . I still support the old views (which no longer seem to exist on SGL) that EAA means  Electronic Viewing of DSO's with either no stacking or just real time stacking. But then thats my take on it and others will disagree.

There is room for any method but for me, EAA on SGL seems to have become too much like "normal" astrophotograhpy and not near real time Electronic Viewing. Even if KIT is evolving to narrow the gap.

Answer to your Questions IMO

1). guiding - not needed but doesn't cause problems either with EAA

2). Mount - alt or EQ will work BUT as with any mount it should be able to carry your kit with ease as you stated.

3. Camera - Mono is better as its more sensative. But I have(still do) done DSLR EAA with Astrotoaster live stacking no problem but confess to guiding(due to using DSLR) depending on the other factors invovled - DSO brightness,Wind strength,Sky quality,kit etc

4. Scope - as fast as possible but there are many variations/combinations is use with EAA.

5. Deep pockets - its can be very expensive as with all Astro stuff - if you let it 🙂

6. Portability  - if you intend to work in the field or at remote dark sites. EAA with a small ALT Mount,Fast Wide Lens or small fast scope can give great views of the night sky.

Continue doing your research as more time finding facts and deciding if EAA meets your wishes the better IMO.

Clear Skies

The Prolific chip set are known to be Crap - tech term  - when used with Windows.

You originally said you bought one of these Lynx Astro FTDI EQDIR USB which is NOT prolific chip. its a FTDI chip which ,if genuine, is know to have very very few problems with Windows 10 (or Linux or Mac).

Put the Prolific chipped cable in the correct place - The Bin - harsh but just look at the hard facts - these chips cause problems (especially the older ones!). The Synscan software and Ascom are being used by lots of people happily on Windows 10. The odds are in favour of the software being OK. 

Thats why FLO/Lynx  stopped selling Prolific based USB cables.

37 minutes ago, BrendanC said:

Alternative, non-Prolific USB-serial converter (which probably wouldn't work anyway but tried it nonetheless)

Rebooting is useless when you have hardware problems - best always to power off ,count to 30 and switch back on without the new cable (non Prolific) being inserted until Windows has loaded and got its head togetner.

Anyway Good luck.

Clear Skies !

And any help can only really be given with Screen prints as stated before of your step by step workflow etc. 

Ascom drivers are only used by clients - e.g. APT ,CDC etc so loading Synscan App PRO (and it has to be PRO version) does not depend on Ascom at all and wont cause issues no matter what state Ascom is in.

You have installed ASCOM haven't you? - thats not the sysscan ascom driver but the base Ascom software - here on the web page right hand side.    https://ascom-standards.org/Downloads/Index.htm    If you have there is a Diagnostic  program you can run from the Ascom menu which will check your installation and show any errors - maybe you should run that and see if it gives any errors .

The only other thing to suggest ,besides checking event viewer  , is to check Windows permissions !

The older version of Ascom installer did have some problems with not installing C++ Dist from Microsoft but I beleive this is not the case today.