On 11/30/10, michael getachew <michaelhoustong@yahoo.com> wrote:

...

...

that has a serial connector on its cable. This thing comes with a CD for Windows. Does anyone know if this is something I can use on a Linux machine? What would I need to have to use it?

These connectors are as common as dirt. I have used one to connect to a modem for years. I got it from Radio Shack for ~$40, but you can buy one from CompUSA, BestBuy or anywhere else for $10 and up.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-- I have seen the future and I'm not in it! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thu, 2010-12-02 at 13:57 -0500, Adam Tauno Williams wrote:

On Thu, 2010-12-02 at 11:15 -0500, Richard Creighton wrote:

...

On 2010-11-30 Stan offered the following:

...

I am looking on ebay at a serial-to-usb adapter to use with a trackball that has a serial connector on its cable. This thing comes with a CD for Windows. Does anyone know if this is something I can use on a Linux machine? What would I need to have to use it? I bought an el-cheapo "gender-mender" type converter from Radio Shack and plugged it in .... no software required, from 'Doze or anyone else and it just works.....threw the 'coaster' that "Doze machines must apparently need for some reason away before it contaminated anything :) I think in the case of a mouse, the rs-232 is close enough to USB that the little converter (plus it's internal resistors/diodes/whatever) need no software, just the pin diddling.

This isn't true; it does require software, but the drivers are built-in and are loaded automatically. There are only a handful of USB/RS-232 chips, the majority of which are supported out-of-the-box. For instance

And the support is uneven. While all the drivers support the basic functionality, only some support all the status/control lines or take action on them. I checked this when were were investigating if we could use such a device with very high end GPS units. These provide a pulse-per-second signal on one of the control lines. This PPS lets you know when something in the receiver was calculated, so you can time tag it more accurately than when it eventually arrives on the serial port. We have decided that the good old RS-232 is still best for this type of thing. Too bad real ports are going away. I guess we will soon be adding RS-232 interface cards to systems. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 2010-12-03 at 09:09 +0100, Per Jessen wrote:

Roger Oberholtzer wrote:

...

port. We have decided that the good old RS-232 is still best for this type of thing. Too bad real ports are going away. I guess we will soon be adding RS-232 interface cards to systems.

Moxa has some really neat serial-to-ethernet boxes.

I have seen such devices. The problem is the non-deterministic nature of packets on the ethernet, versus the hardware interrupt caused by the serial port line toggle done by the GPS. The issue is that we are striving for centimeter accuracy with these receivers (they are GPS with integrated inertial navigation systems that solve locations using Kalman filtering). As a minimum, we need to know the time we were at some location when the GPS/INS did some calculation. The time when things happen is the core data used here. At 90 km/h, a vehicle is moving 25 meters per second. So to even begin to entertain thoughts of achieving this accuracy, the accuracy of the time tag for the event should be better than 1/2500 of a second. Obtaining the PPS over the serial port with this or better accuracy is no problem. Obtaining the same over USB or ethernet is less provable. But we are always looking. Serial ports are going the way of the dodo. Even if there are some real world needs for them. Just not enough of them to keep them standard on consumer grade computers. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 2010-12-03 at 09:20 +0100, Roger Oberholtzer wrote:

...

Roger Oberholtzer wrote:

...

port. We have decided that the good old RS-232 is still best for this type of thing. Too bad real ports are going away. I guess we will soon be adding RS-232 interface cards to systems. Moxa has some really neat serial-to-ethernet boxes. I have seen such devices. The problem is the non-deterministic nature of

On Fri, 2010-12-03 at 09:09 +0100, Per Jessen wrote: packets on the ethernet, versus the hardware interrupt caused by the serial port line toggle done by the GPS.

+1 These devices are epic-fail for a wide variety of use-cases. They work very well if you are just streaming data back or forth and don't require flow-control.

But we are always looking. Serial ports are going the way of the dodo. Even if there are some real world needs for them. Just not enough of them to keep them standard on consumer grade computers.

It would seem you need to build a native-USB interface. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 2010-12-03 at 09:01 -0500, Brian K. White wrote:

Interesting problem. I love how it exemplifies how "progress often isn't".

Maybe get a head start by licensing a reduced version of this that only has to keep two nodes in sync, the pc and the gps.

Only keep two things in sync... That's no fun. We are also syncing images from firewire/Gig<E>Vision/JPEG2000/v4l2 cameras, vehicle movement from linear pulse transducers, an assortment of lasers, accelerometers, inclinometers, gyroscopes, and other devices I am surely forgetting. Oh, and of course operator input in all this. That one is the nastiest one to deal with in X11 systems (who's concept of time is relative to when the X server started - not the systems' clock).

http://www.chronologic.com.au/oemsolutions.html

This sounds interesting. But I wonder how this really works when USB is a packet-based system on which all devices must share access. I suspect this is a sort of fast hub that accepts packets from each connected device immediately and then time tags each packet from the devices as they pass through, allowing you to check this encapsulated info on the host via a driver that can peel off the time wrapper. As long as you can assume there is no delay getting it in to this hub, I guess this could improve time tagging. I will bookmark this one.

It's the only thing I find at all when I google for variations of synchronous, deterministic, high precision, timing, and usb.

I would have thought every dinky usb sound card would need good timing, and usb modems that expect to fax reliably. But then again, my incredulity doesn't matter because current bluetooth A2DP audio devices continue to have have wow (speed skew, as in "wow & flutter" like records and tapes had, but no flutter) no matter how incredulous I am about it. I mean, CD's had no wow since 1982, laserdiscs had no wow since 1978. Why in 2010 do several different smart phones (different OS's different manufacturers, used with different receivers both in car and in home) have wow when playing audio over bluetooth?

Progress often isn't.

Still, USB has generally made connecting many types of peripherals much easier. I have no trouble with it for many uses. My new laptop has USB3, but I have no devices to test with. I wonder what a 10x speed improvement will really mean. Probably that all devices will get more verbose, and just fill the capacity with, effectively, the same content. I'm showing the telltale sings of age here... -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 03 Dec 2010 09:20:58 +0100, Roger Oberholtzer <roger@opq.se> wrote:

Obtaining the PPS over the serial port with this or better accuracy is no problem. Obtaining the same over USB or ethernet is less provable.

No way, at least not for GPS/Time signals! The reason is that serial ports can react to interrupts but USB is polling by the host.

But we are always looking. Serial ports are going the way of the dodo.

Yeah, and sadly so! There is currently no connection for peripheral devices that want to trigger an interrupt. I still wonder why Intel thought no one would need something like this ... Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 03 Dec 2010 15:56:32 -0800, John Andersen <jsamyth@gmail.com> wrote:

USB can use interrupts, as a gander at the Hardware information thingie in Yast will show you. Each of your controllers has an interrupt assigned.

USB knows interrupt transfers but it doesn't know interrupts in the way we are used to. See http://www.embeddedsys.com/subpages/resources/images/documents/InterruptsAnd... for a good description. USB devices *must* be polled by the host controller, the rate of which is established at enumeration time with limits as described in the document. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Philipp Thomas wrote:

I still wonder why Intel thought no one would need something like this ...

Roger Oberholtzer wrote:

Interesting read. This is why we have made our own little dongles to which we attach various devices. These time stamp (or the equivalent) things and then pass them on the ethernet to the collection systems. This way we have everything synchronized to within 1 wheel pulse (< 0.9mm) of vehicle movement.

I think this answers Philipp's puzzlement. Intel expects that measurement devices will contain enough intelligence to enable measurement collection to be asynchronous. Or at least they will be interfaced via such devices. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 06 Dec 2010 11:37:21 +0000, Dave Howorth <dhoworth@mrc-lmb.cam.ac.uk> wrote:

I think this answers Philipp's puzzlement.

In Part yes :)

Intel expects that measurement devices will contain enough intelligence to enable measurement collection to be asynchronous. Or at least they will be interfaced via such devices.

I think they didn't really think about these cases, but you could also be right in that the USB creators (Intel, Microsoft and others) really did assume that the timing critical part would be implemented in the device. And using the serial port for Time signal receivers wasn't in the spec of the serial interface either, at least for those devices that just strobed DTS to deliver a timing interrupt. It just happened to work :) Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org