I have a remote Raspberry Pi which I connect to from my MacBook over VNC.

This late afternoon I tried connecting but was not able.

In looking at the outdoor unit there is a red light which shows that the Pi is at least getting power.

The VNC connection is hanging.

The Mac has a way of connecting to Stellarmate like a Remote Desktop, but it doesn't show the Stellarmate connection is available over the network.

When typing a ping to stellarmate it says that ping cannot connect to Stellarmate.Local.

I rebooted my MacBook.

I rebooted my outdoor setup with the Pi.

Could there still be a simple reason for there being no connection?

This is the 1st time that I've been disconnected beyond the time it took for Stellarmate to load up.

This is frustrating:  I solved the issue at hand, yet I most certainly haven't solved the problem.

Giving up on the fact that I knew things were not going to get back online by themselves, I made a guess that this was a port related problem.

I've already posted a couple varieties of this recurring problem.
Pegasus Connection Dropped
3 serial devices want to share same

Tonight was no different in the respect that it was a port related issue.  I removed all of the USB connections to the PI and wouldn't you know the VNC connection was good finally.

I turned off the Pi device.

I replaced the 1 connection that I copied the exact Serial ID to the connection tab in the INDI Control Panel.

I Turned back on the Pi.  I next opened VNC and there are no connection issues.

I turned off the Pi again and brought up the next device, shut the Pi back down and this time I brought up my last serial device.  This time everything was fine.

My issue is likely solved for the evening but I am afraid that anytime I turn on Ekos I am succeptable to port failure issues.

I know where I want to connect all my devices in the USB slots.  I have it all labeled out as well.

Is there any way to lock down all of the ports in Ekos?

 

So today I implemented the by-id serial links in INDI. It should be in StellarMate v1.5.8 which would be released in a few hours.

Jasem:  That almost sounds like major news!

How would this differ from what is used now?

I am familiar with the Stellarmate Serial Port Assignment which seems to work as long as there aren't 2 different serial devices that have the same identity.

Thank you very much for the heads up, I will certainly look to try this.




 

It is. I recommenced you download and flash SM OS 1.5.8 to start on fresh grounds. KStars is not yet released on Mac/Windows but will be soon in a couple of days after beta testing is complete. If I understand the serial/by-id correctly, then you don't need to use the serial port mapper. But I have to check more and see how it behaves when using complex setups with Pegasus + hubs connected togeather.

I can certainly test this out with my tandem Pegasus devices.  The EQMod also doesn't play well with these devices.

I will try everything from scratch to see if this comes in clean.  (Of course I don't know if you can even bring in old profile settings from a new card).

I'll do this tonight as I'm stuck with another setup related issue.

Thanks!  This could really help the user friendliness of Ekos.

I'll keep you posted if I run into any serial related snags.

Jasem:  I installed the SM OS 1.5.8 this evening.  I did see a number of issues at least in the way my setup came up, however there is one thing that seemed to work quite well.

The 1st thing that I observed when I turned on the SM OS 1.5.8 is that there was a considerable amount more lag.  I don't know whether this is due to something that I did or if this version is causing more latency.

I saw something that I never noticed before.  On the top right there was an icon that said Stellarmate 1 and another that was Stellarmate 2.  It appears from this that perhaps you would be able to launch a couple instances of Ekos for a couple different telescope setups.  This wouldn't be causing the latency would it?

In the Ekos setup I added all of the devices.  I also added all of the physical devices after powering down.  I powered back up to see if it might connect without issues; unfortunately it failed to connect at all.

Next after powering down I disconnected all but one of the serial devices.  This allowed me to connect to Ekos, yet the connection of that one serial device failed.

Eventually I brought up all of the devices.  Unfortunately the serial device connections failed.

In looking at these devices they held separate USB0, USB1 and USB2 identities.  This was good.  I also noticed that the serial device unique name was in the lines above the USB entry.

When I typed in the udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1 script I discovered that my EQmod was actually USB0.  I changed this from USB1 (which was assigned by default) to USB0 and the EQmod connected.

Thinking that this might solve the connection issue for the remaining Pegasus devices I typed in udevadm info -a -n /dev/ttyUSB1 | grep '{serial}' | head -n1 to find that USB1 was the Pegasus Focus Cube.  So that also likely meant that my remaining Pegasus Pocket Power box was USB2.

I changed the PPBA to USB2 and the Focus Cube to USB1.  I tried to connect these but the connection failed.

That's where I left it this evening.

Tomorrow I will try connecting the serial device that I believe should be 1st (the PPBA) by itself to see if the USB assignment under udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1 changes or not.  I would actually like the EQmod assignment to be last instead of 1st as it can be turned off while plugged in.

If the USB slots for my serial devices are locked in I will likely start over a new profile and attempt to get this with preferred USB assignments.

Another thing that I'm personally appreciative of is that you made a couple items in the Pegasus Focus Cube that I pointed out to you yesterday and made them changeable fields.

Thank you so much for working on this more stable serial USB project.  It appears there still needs to be some tweaking with the SM OS 1.5.8.  Most troublesome to me is the latency that I personally observed, yet with more locked in Serial port assignments this appears to be a good step in the right direction.

NOTE:  If there is any flaw that is seen in the way I set my devices up let me know and I will try it the better way and feedback how this did or didn't change something.

Hi Paul, thanks for the feedback. I identified the issue with the performance and pushed a quick hotfix please update all packages and install the update. Furthermore, I will reupload the image in a few minutes after I verify the fix. Basically a new service to control Raspberry GPIO was consuming CPU, so disabled it for now until we can investigate it further.

Each device should have a unique identity now under Connection tab. Can you post a screenshot of what you got?

Jasem:  I have started up Ekos with the early version of SM OS 1.5.8.  As I was thinking of the possibility, in bringing up the different devices in the INDI Control Panel did do some switching around of the Serial port USB assignments.  There is one oddity that I will bring up.  The peculiar thing was that everything did come up this time.  As per yesterday's lesson I waited until the 2 Pegasus devices came up and were assigned and connected prior to turning on the power switch for my EQ6R Pro mount.  There was quite an oddity that I will point out which you will see is specific to the EQ6R Pro EQMod device.

Below you will see the Pegasus Pocket Power Box in the connection tab.

This registers as USB0, and above this line you can see what apparently is the unique Serial ID specified.

 

Below this you will see the connection tab for Pegasus Focus Cube.  This registers at USB1.  (Small note: The backlash assignment that I'm sure I saved reverted back to 1 on the right space even though it retained the number I entered (30) on the left side space). Likely the reason there is a message telling me to Enable Backlash; which is enabled.

 

The EQ Mod callout is a little different as you will see.  Yesterday this device occupied USB0 which I did not really want.  When I delayed this devices connection from the EQ6R Pro power switch it is interesting to see that it did not keep yesterday's assignment, yet part of it seems to want USB0 on the right side box.  The left side box appears to have copied over the unique Serial ID unless I'm mistaken.

The peculiar thing is that will all of the apparent confusion every one of the 3 Serial ID devices shows up as being connected.

This is what shows up for the EQMod tab under connection.

 

I will download the new SM OS 1.5.8 hot fix but I will wait a little while before installing just in case you would like to see any other setting with the older SM OS 1.5.8.

 

You need to click one of these button to set it as the active port, then connect. If connection is OK, then it should remember to use this unique port next time. You can also double make sure by going to Options --> Configuration --> Save.

Sorry for not replying back sooner but today I've been under the weather because of the effects of the Covid vaccine.

I'm not understanding the procedure that you are suggesting.  I believe that you are suggesting setting ports up as their unique Serial ID.  1 thing I am seeing as I try to set each port is that typically each of the Serial Devices wants to snag USB0 port.  I'm not sure what the procedure might be to 1st assign one of these devices to USB0 and then after it is set how I would assign the next Serial Device as USB1, and the last Serial Device as USB2.

I do have the hot fix installed now.

They try different ports if the connection fails, but you can prevent this by setting "Auto Search" to OFF. Then it's pretty clear. For EQMod, it's already selected as "Prolific Technology..etc". For PPBA and FocusCube, it's already listed in the port name, so each driver you simply click the corresponding button to copy the full serial ID to the Port property, then set Auto Search OFF to Options --> Configuration --> Save and that's it.