×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Issue with Serial Devices wanting to share USB0

  • Posts: 92
  • Thank you received: 1
This entire weekend I have been trying to solve an issue which cropped up where several devices want to snag the same USB number.

Just prior to this post for a short while I thought that I may have solved the issue, but unfortunately that became unraveled.

Prior to this everything was stable with my setup.  Yesterday I made the decision that it was time to take my setup outdoors for the 1st time.  While it was in my house I used Telescope Simulator for my mount.  Prior to taking the unit outside I changed my equipment profile to where I switched the Telescope Simulator for the EQMod which will be used with my EQ6R Pro.

Immediately everything came unglued between 3 serial devices which include the EQMod, Pegasus Focus Cube and the Pegasus Pocket Box Advanced.  Nothing would connect.  It looked like every device was vying for USB0, yet it also appeared that the focus cube and EQMod might be competing for USB1 as well.

Not very long ago I was helped in solving a very similar issue, but that time it was between the Focus Cube and the PPBA.   Pegasus Connection Dropped .  The solution ultimately was to copy the unique Serial ID and place it in the INDI Control Panel under the PPBA device connections.  When I made this change I was able to designate USB1 for the Focus Cube.  The PPBA had USB0.

So, everything was working just prior to adding the new device for the EQ6R Pro.

I have tried numerous ways in which to separate each device by it's own USB.  I tried manually mapping, the Stellarmate Serial Port Assistant, etc...

Just a short while ago I was excited to see that in listing out the serial id, that the EQMod wasn't listed as USB0 it was listed under USB1.  In the following image there is a red box around USB0 which is what I assigned to the PPBA.  There is another red box around USB1 which I am assuming is the EQMod.  (As nothing besides the PPBA and the EQMod was plugged in).

 

When I listed by typing /dev/serial/by-id however it seemed likely that both devices were assuming USB0 as they both register Port0.

Just in the happenstance that I was wrong I copied the serial sequence line for the EQMod and inserted in the INDI Control Panel under the EQMod connections.

 

As can be seen this did not achieve any USB separation, the device still is not connected.

I have no understanding of using Linux commands.  I have copied and pasted my way this far.  Hopefully understanding enough to follow directions properly.

Is there anything in my post here that suggests that I did something incorrectly?  Is there any possibility that I am close to fitting the final pieces together?

The other idea which has been suggested is using UDEV to assign permanently each device to it's USB location.  Even though I have read the tutorial on this site I can't say I fully understand the implementation of it.  I'm willing to try this if someone can explain the terminal sequences or other inputs that might be involved in doing this.
2 years 11 months ago #70203
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 92
  • Thank you received: 1
I worked a long time on this.  I think that for the moment at least that everything is finally connected properly.  I'm not really sure what I did makes sense so I'm not sure it will hold.

Even though I tried this earlier and it didn't work I went back to the Stellarmate Serial Port Assistant and claimed the EQMod as /dev/mount.  (On my opening slide I had attempted getting the Serial ID string and inserting this in the INDI Control Panel).  After doing this it initially acted quite flaky, but eventually it allowed me to connect and I saved this.

This made the Focus Cube the last hold out.   I had changed it's USB designation to USB2 to avoid what I thought there was a conflict with the EQMod using USB1.  In fact one time I recorded that EQMod was on USB1 when I did the "udevadm info -a -n /dev/ttyUSB1 | grep '{serial}' | head -n1" entry.

When I did the above command to USB2 there is surprisingly where I found the EQMod.

So, from there I did the above command to USB1 again and surprise, surprise that is where it said the Focus Cube really was at.  I just changed the USB designation from 2 to 1 and the Focuser found itself.

Hopefully that is the last of the USB jumping around for a while.  I have 2 of the 3 Serial components somewhat locked down.  (The Focus Cube USB port could still drift theoretically).

I'm not opposed to further modifying this for stability purposes but (after documenting what I have) at last I can shift to something else for a while.
 
2 years 11 months ago #70205

Please Log in or Create an account to join the conversation.

  • Posts: 276
  • Thank you received: 52
Hi NorthMIPaul,

How are you powering your USB?
Direct from motherboard, un-powered hub, powered hub?

If power is drooping too low on the USB interface, devices will re-enumerate which may explain what you are seeing.

What does dmesg show, are devices coming and going?

Gene
2 years 11 months ago #70215

Please Log in or Create an account to join the conversation.

  • Posts: 92
  • Thank you received: 1
OK, this is truly messed up.

This morning I went through connecting to EKOS.  Right away there was a conflict between the PPBA and Focus Cube as both did not connect.

Eventually the PPBA did connect, yet the Focus Cube did not.

The message I noticed when opening the Focus Cube tab was that the USB1 port was already being used.

 

When I entered  udevadm info -a -n /dev/ttyUSB1 | grep '{serial}' | head -n1 to expose what was actually using USB1 I was very surprised to see that it was the PPBA device???

What is very surprising is not only that this was USB0, but much more surprising was that I earlier mapped the unique Serial ID code directly into INDI as you can see below with the Ports.

 

I thought that by copying the string found in “/dev/serial/by-id " into the INDI Control Panel in the port area would not only secure the PPBA's connection to the USB slot that it was plugged into, but that it also would lock the USB0 to this device.

For the USB assignment to shift for what I thought was locked in, it really makes me wonder what if anything this accomplished and if there truly is a way to lock in all of the USB assignments.  This worked wonderfully the 1st time as it separated the PPBA from the Focus Cube.  By me juggling in the EQMod the whole stability got destroyed.

Knowing that the PPBA shifted to USB1 (with this time turning the equipment on) I could shift the Focus Cube to USB0 and perhaps it might connect everything up again, but then this just becomes a tail chasing task every time turning the equipment on.  I really would like this to just come up where everything just remembers it's assignments.

NOTE:  Just out of curiousity I went back in to see what truly was using the USB0, as I should have checked from the beginning.  I was surprised to see that the EQMod which I mapped using the Stellarmate Serial Port Assistant grabbed control of USB0 from the PPBA.  So not only does copying the Serial Id string (which I did for the PPBA) not retain it's USB port, the Stellarmate Serial Port Assistant (with the EQMod device) also did not retain it's USB port. 

Gene:  I am powering the Pi USB ports through the PPBA device which also includes it's own USB Hub.  I'm not sure how I might verify whether power is indeed coming in low in the USB interface.

I did type the dmesg command and I got the following message.

 

I am very limited in understanding Linux commands.  I do see that there is some type of an error however. 
Last edit: 2 years 11 months ago by Paul Imm. Reason: Added new finding
2 years 11 months ago #70218
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 276
  • Thank you received: 52
Hi NorthMIPaul,

Would need to see the full output from dmesg.

Try a
dmesg >/tmp/dmesg_output.log

And attach the file /tmp/dmesg_output.log

As far as USB enumeration, when powered up devices may enumerate to a different TTY, the big problem comes about when they re-enumerate after initial enumeration but -not- because of an unplug/replug. Dmesg output should provide some clue for the second part.

Which of the above are you seeing? Different TTY when power up but device stays where it starts or changing after having a value at powerup?
2 years 11 months ago #70220

Please Log in or Create an account to join the conversation.

  • Posts: 92
  • Thank you received: 1
Gene:  Upon noticing that the EQMod mount stole USB0 from the PPBA it gave me an idea which is related to the USB powering.  I wondered what might happen if I initially powered up from my battery with the EQ6R Pro not turned on.  (I have been leaving this button on every time I have powered up).  When I did this I verified that the PPBA snagged the USB0 port.  As soon as I turned on the EQ6R Pro power it snagged it's proper USB2 port!  All 3 serial devices connected.

In retrospect perhaps I should have been turning off the EQ6R Pro power prior to pulling the battery plug.

I don't know whether this might answer your question, but it appears the USB ports get snagged as they power up.  I don't see evidence of shifting when it is powered up, unless I do something to shift them such as when I used the Serial Port Assistant.

When I copy the dmesg >/tmp/dmesg_output.log line nothing comes up.

At this point I am good with the setup so I could hold off until I am struggling with the ports assignment again.  If you think there might be something telling to learn from the dmesg sequence however I would need a little coaching on the exact things to type.  I'm very linux illiterate.
2 years 11 months ago #70221

Please Log in or Create an account to join the conversation.

  • Posts: 276
  • Thank you received: 52
Hi NorthMIPaul,

Good on not changing after powerup!

Would not need the dmesg unless they were changing.

dmesg:
When you typed
dmesg >/tmp/dmesg_output.log

This created a new file in your /tmp directory

After running the above, do
ls -ltr /tmp/dmesg_output.log

You should see the new file.

Gene
2 years 11 months ago #70222

Please Log in or Create an account to join the conversation.

  • Posts: 92
  • Thank you received: 1
Gene: This is what I get by adding the 2nd set in the terminal.

Not much shows up.

 

As for now, I think I may have a logical start up sequence which hopefully doesn't unglue.

I'll be disconnecting in a little and will do another power up with the same start up sequence that was successful earlier.  If this works good I think I likely will be good.  I'll just be sure to follow a specific startup   pattern.
2 years 11 months ago #70226
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 276
  • Thank you received: 52
Following up on the dmesg_output.log

You can open and read the contents with any text editor, vi,,,,
The following user(s) said Thank You: Paul Imm
2 years 11 months ago #70252

Please Log in or Create an account to join the conversation.

Time to create page: 1.098 seconds