On Tuesday 05 June 2012 12:34:33 Fred Labrosse wrote:
> On Sunday 03 June 2012 19:33:50 Rich Mattes wrote:
> > On 06/03/2012 12:19 PM, Fred Labrosse wrote:
> > > On Saturday 02 June 2012 20:00:35 Travis Woodbury wrote:
> > >> Fred,
> > >>
> > >> You have a cabling issue of some sort that should be resolved. I've
> > >> not
> > >> looked at the code to see exactly how it works, but the 'EMI?' warning
> > >> has always been spot on in identifying cabling issues, from my
> > >> experience. USB signalling isn't especially robust and is sensitive to
> > >> poorly build/designed cables, RF noise sources near the cables, and
> > >> shortcuts in filtering on the PCB's. Tough to speculate without
> > >> knowing
> > >> more
> > >
> > > Thanks for the input. Yes, I suspect cabling issues, as I have had a
> > > lot
> > > of that sort of issues recently. I have in particular experienced a
> > > drop
> > > in power provided by the USB ports from the computer and have had to
> > > feed
> > > in external power via powering USB hubs... However, this device is
> > > directly connected to a "native" USB port, and I'm wondering if this
> > > could be the problem... More investigation needed.
> > >
> > > Thanks.
> > >
> > > Fred
> > For what it's worth, we've had a lot of problems with the USB ports on
> > Dell laptops deciding to cut out intermittently when under heavy load
> > (we had the two Segway modules in an RMP400 hooked up.) We were able to
> > work around it by making sure all of the USB connections went through a
> > USB hub to a single USB port on the computer, for whatever reason that
> > helped things. Our theory was that the laptop's USB controller couldn't
> > handle multiple connections at full speed.
> I agree, USB is less than good.!
> > If you need to work around it in software though, you can indeed
> > unsubscribe everything from the driver, which will cause the driver to
> > close the file descriptor to the port. Once everything is unsubscribed,
> > if you need to change the port that the laser is connected to, you can
> > the driver's port string as a Driver Property.
> I think the problem is worse than that. I haven't delved in udev rules, but
> my system (gentoo) provides by-id symlinks, which is very handy. However,
> these seem not to be released until player is shutdown, even if the link is
> pointing to the new device... I think the solution there is to come up
> with a udev rule to make sure my devices always appear as the same ttyUSB
> The bigger problem for now is that player does not seem to realise that it
> is not getting data any more. I access the lasers via ranger interfaces
> and use the GetElapsedTime() function to see how old the data is. This
> seems to be updated normally even if I don't get any data... I need to
> explore this a bit more though.
Obviously, elapsed time was the wrong thing to do, as I understand this is the
time between the last 2 data points obtained. So if I don't get any data,
then this is not updated.
Now using the GetDataTime(), then I can detect that I am not getting data any
more (comparing it to the current time).
That said, I wiggled all the USB connectors and that seems to have solved the
issue... I hate USB!