Ethernet to USB Connectivity
Posted 06 February 2011 - 03:42 PM
Figured I'd share my trial and tribulations encountered this weekend related to Ethernet to USB connectivity.
A few weeks ago a member posted a request for info related to extending communications capability to a mount where the computer controlling it was remotely located. Specifically, he was looking for Ethernet to serial communications capability. The thread weaved a bit due to different forms of advice, but kept going back to Ethernet to USB as a more robust solution (being that a USB to serial converter could be used to address direct serial requirements, while providing additional USB capability with the remaining open ports on the Ethernet-USB adapter).
Based on the recommendations (and direct help in defining the configuration of the unit) from another poster obtained via PM, I purchased the adapter displayed as a USB 2.0 over IP. For under $100.00, it provides 4 USB 2.0 port accessibility over an Ethernet connection. After spending Friday evening and most of Saturday playing with the adapter under different configurations, I have to report that this truly works as advertised.
My current configuration (sans observatory) is a permanently mounted pier, with my equipment mounted and covered responsibly. Problem is it gets a bit cold here in the winter, and standing outside with a laptop shooting pictures get a bit "old in the cold" if you all know what I mean. I tried remote desktop with laptop co-located with the pier but the lagging rendered that solution unusable. Nevertheless this solution worked perfectly. No lagging, with the exception of the Meade DSI cameras, all peripherals were connected, tested and supported. If you are considering long distance remote access of your equipment (serial or USB 2.0), you should consider this solution. Here's the link that Paul provided me: http://www.cooldrive...b20ovipne4.html
The only "cons" I experienced was with determining how to deploy the adapter (by including it within my current home network or by running a separate Ethernet cable specifically for this). Flipping back and forth from the network to a dedicated connection from my laptop caused me some confusion in determining a correct configuration, but this was wholly driver error and I eventually figured it out. Although it will function as part of an existing network (as I tested), I felt it would degrade the existing network and be influenced by traffic as well so I installed a second network interface card in my computer and ran a dedicated Ethernet line to the outside connection box. So from that interface box I can connect to the Pier or to the CGEM just about anywhere in my yard. This provides lots a flexibility as well as warm nights! The other "con" was that for a home based PC with no wireless capability, you may want to consider installing an additional NIC card, so that you can still have internet access. Kudos to Paul for pointing that out to me.
This is a solid remote connectivity solution and for those using remote desktop it also frees up a device!
Posted 06 February 2011 - 04:16 PM
Posted 06 February 2011 - 11:28 PM
Thanks for the report. I ordered the same "box" and should get it this week. I plan to connect directly from laptop's ethernet port to the "box" and use USB connections to SXVR-M25C camera, Lodestar autoguider, MicroTouch autofocuser and CPC0800 via USB to serial adapter. Any tips you can provide or is it very straight forward?
Posted 06 February 2011 - 11:58 PM
If using direct connection without an Ethernet switch in between, an Ethernet cross-over cable is required.
Also note that many astroCCD imagers require High-speed USB 2.0 isochronous mode for data streaming. This is the same constraint as in Meade DSI.
The best way to describe the situation is USB2 high speed is 480Mbps (and DSI needs it) while fast-Ethernet is just 100Mbps. The network will choke the data movement and that's why things won't work.
P.S. don't know if there is a USB hub inside that device. Assuming it's using the USB hub design, if any one device connects to the 4 USB ports is USB1.1, all ports will be downgraded to USB1.1. Meade DSI (and many astroCCDs) will not work under USB1.1.
P.P.S. I learned in the USB world, there is nothing called "all works".
Posted 07 February 2011 - 01:11 AM
Did you use cross-over cable for direct connection from NIC card to the "box"?
Posted 07 February 2011 - 07:05 AM
Direct connect. I tried cross over initially on my first attempts to get it to work. I'll follow up later today with detail for some tips. Great info from CSS_Hello, that could be the problem I'm encountering with my DSI's.
Posted 07 February 2011 - 12:03 PM
I've always used plain old Cat5e - not crossover. I think most of these units have auto cross-over.
Sorry that I didn't check before, but cooldrives apparently has a USB2 to gigabit ethernet unit also available ($99) which would obviate the USB2 to ethernet bottleneck. Since my setup works, I never bothered to search for anything better. I have no idea if the unit would revert to USB1.1 if that kind of device were attached, though. Probably would, but you could get around that with multiple units and a gigabit switch I would think.
I've used my DSI1Pro successfully as a guider with the ST402 as my imager. Haven't had it out since I got my ST2000XM though. My DSI1Pro, though, always 'worked' with USB1.1 - at least for short (< 5 sec.) exposures on a very bright star. The background noise would fluctuate but not enough to throw off the guiding. The DSI issues seem to be related both to transfer speed and power delivery. The units seem to deliver plenty of power but obviously don't meet the transfer speed requirement. Meade claims the DSIs are USB1.1 backward compatible with the caveat that it depends on the overall system it's hooked to. Guess I got lucky. The later DSIs with bigger chips, etc. would probably have more problems.
To answer the wireless question - I would think that 802.11a/g/ or n (not would work for USB1.1 devices hooked to the unit if you have a clear signal with no interference from household stuff or neighbors. At least in my neighborhood, though, wireless stuff seems to be everywhere and is easy for me to pick up. Luckily for me, they all seem to use channels 1, 10, or 11 for some reason, so I have channel 5 all to myself but I can't expect that to last. Lots of devices default to 3 or 6 so it's probably just a matter of time. Even though the transfer specs would seem to be there for wireless, I'm not sure I'd trust it much for transferring image data. At least with my ST2000XM, it just takes one 'glitch' to basically spoil a whole subexposure. The glitches I've had to this point have all been related to trying to run memory intensive apps on my admittedly dated laptop while a subexposure is downloading. For example, running CCDStack while a download is in progress. It might not happen on a multi-core machine with more memory or have anything to do with wireless but it has made me a little gun-shy, so to speak. I do access the internet via wireless while I'm imaging without apparent problems. I've had no problems with the USB2 to IP device given my application which uses just 3 ports - USB-to-serial adapter, JMI PCFocus, and ST2000XM.
Posted 07 February 2011 - 01:28 PM
Following up on tips and tricks when deploying this unit, I would stress not to complicate the environment as primary. Paul had sent me directions via a PM that were very clear and direct. Although I followed them, I did so under varying conditions such as directly connecting the unit and connecting downstream from a router and a switch. Due to the environment changes, my expectations as to how the unit was identified and configured were not as expected. Here's the differences I found:
1. If direct connect, then you should use the default IP as programmed in the unit. You'll need to configure your NIC card to that IP schema (including gateway, etc.). Additionally if you have multiple NIC cards (wireless, ethernet) there could be contention as to assignment to the proper card of calling resources (i.e. internet vs. the USBIP assignment). Paul's advice addressing this problem was spot on, that being to assign an Interface Metric via the NIC properties that sequences the assisgnment. you can also just enable-disable one card vs. the other, but that can get old quick. Nevertheless, that was the main issue I sa with direct connect.
2. Over network: I do not know what the "influencing contention" of running this over a network would be (I'm not a network guy, I'm an applications guy), but I do know my three boys are all college students and fling a lot of stuff across that router. I also know that the ST-4000XCM is also sending a lot of data back to CCDSoft, so between the boys and the camera, there's bound to be some contention somewhere. I figured if I was going to go through all of this work, I might as well just run it direct from another NIC card. But everyone's environment is different. That being the case, my test of the unit over the home network still required that I identify the unit as Paul defined, but after that was done I selected DCHP instead of static IP and saved that setting to the unit. It worked OK with DCHP selected. So I guess it will work over a home network (sans contention). My understanding from the guys I work with is that these ethernet to USB devices are used with home theater and office audio-video type setups.
Between the two settings, I'm more comfortable with static IP. My problem was that I was jumping back and forth between my PC, a laptop, direct connect and home network, static and DCHP. My test environment was not secure, so I ended up wasting about a day (but I sure learned a lot!).
I'm still struggling with css_hello's observations specific to the DSI's. I agree with the fact that USB 1.1 usage will drop all other ports to that level. I'm thinkg he's right that even though the ST-4000XCM supports 4kps USB throughput, it may be USB 1.x and hence it functions.
I'd like to figure this out 'cause I want to use the DSI's with the CGEM.
Hoe that helps a bit.
Posted 07 February 2011 - 05:27 PM
Posted 15 February 2011 - 01:36 AM
My other computer is a laptop which has wired LAN and WiFi. I connected the "box" directly to the laptop wired LAN connector (bypassing the home network) and I have been unsuccessful. I set the wired IP address to 192.168.3.22 in laptop which is the default IP address of the "box". I also set the gateway address to 192.168.3.1 in laptop. After setting the default IP address, I keep getting conflict IP address saying another computer has the same IP address which I can't find. I tried with regular and cross-over ethernet cables.
I also disabled laptop's WiFi thinking it might be conflicting but that was not the case.
Any ideas on how to connect the "box" directly to the laptop and not connect to the home network?
Posted 15 February 2011 - 05:00 AM
If I'm reading what you did right.
Posted 15 February 2011 - 10:07 AM
Posted 15 February 2011 - 11:50 AM
The laptop is the gateway for the USBoverIP and has to have that address. If you are also going to use the wireless, you'll have to set the interface metric of the wired NIC to a higher number than the wireless NIC or your computer will probably try to use the wired NIC to find the internet. Windows usually defaults to using the wired card unless the metric tells it not to.
Posted 15 February 2011 - 11:59 AM
Posted 15 February 2011 - 12:20 PM
Posted 15 February 2011 - 12:37 PM
Posted 15 February 2011 - 12:52 PM
Sorry for the late join, but everything Paul instructed is spot on. Especially with setting the interface metric for multi NIC card devices. USB over IP does not like to share NIC's, expecially when the first card it finds does not have the correct IP (192.168.3.1).
Following up on your previous cross-over vs. direct connect, it has to be an auto cross-over detection as you stated, because it works with straight thru T568-B connnect. I proved this this weekend as I ran a dedicated line from my PC to the external port on the back of my house, and configured the connectors to straight thru.
Posted 15 February 2011 - 03:19 PM
It recognizes my Startech USB-to-Serial adapter but it won't connect to Celestron NexRemote for telescope control. Device Manager showed COM17 but NexRemote won't find or let me connect to COM17. If the USB-to-Serial adapter is connected directly to USB port of laptop, it works fine with NexRemote.
Also, I was not able to connect to my SXVR-M25C camera and Lodestar autoguider. Nothing happened after connecting them.
Any suggestions and tips?
Now I am back to work. Will play with the "box" some more tonight.
Tonight, I will check to see if connecting to home network works better than direct connection.
Posted 15 February 2011 - 07:43 PM
I'm not familair with the SXVR camera or Lodestar. I presume you've used them with the laptop before so the drivers, etc. are available. If the drivers won't install PnP when the cameras are plugged into the USBoverIP, I suggest you try manually installing the cameras with the CDROM or whatever they come with while they are hooked up to the USBoverIP. Keep in mind that the USB-to-serial may default the USBoverIP to USB1.1 and cause some difficulties with the USB2 devices.
Posted 15 February 2011 - 10:45 PM
Posted 15 February 2011 - 11:44 PM
Posted 16 February 2011 - 11:00 AM
As you may have already guessed there are likely a bunch of applications on your PC that are "holding" a Comm port address. Since it's unlikely that you need 17 different comm port addresses today I would go through your app list and delete any you no longer need or want ... and maybe even de install and reinstall some of the ones you do use regularly to release and re order your comm port assignments.
There is still a lot of code around that "holds" comm ports and that doesn't understand virtual comm ports and high comm port numbers. For a while it was normal to only see comm 1-4, then it became 1-8 or 10, now it's often up to 15 (think hex addressing). Many applications that used serial ports simply never envisioned PCs with large numbers of comm port addresses.
Posted 16 February 2011 - 11:33 AM
It works great if plugged in the adapter directly to USB port of laptop and COM16 is assigned. NexRemote kindly brought up COM16 and I selected it and I am able to control my CPC0800.
Posted 16 February 2011 - 05:00 PM
Posted 16 February 2011 - 05:23 PM