3
1
As a fan of gadgets sometimes I get carried away and this time I bought a Neato XV-11 vacuum bot (which by the way works pretty good).
Now there seems to be a firmware upgrade for the device that I have to do under Windows. However I have a 2008 Macbook Pro, so I decided to use BootCamp.
To do the upgrade you need a mini usb cable and plug it into your robot. The update application will setup a serial connection to the robot, which is emulated under COM3 in my case.
This doesn't work because under Windows any serial connection with the device stalls after the first character that is send. I've tried it myself with Putty and Hyperterminal to setup a test serial connection (115200 baud). I want to type "help" which would list the robots commands, but only the "h" is echo-ed back to me.
If tried the same under OSX (with terminal and the screen command, /dev/ttsy.usbmodem662, same settings as in Windows) and everything works fine (I get the list of supported robot commands)!
After debugging with a serial communication monitor under Windows I saw that the connection is still open after the "h", but the device isn't sending anything after that. When I then disconnect the session, unplug the USB and plug it back in, I notice that the device suddenly reacts to all my previous commands. A bit as if it was buffered (I can only see this because of the serial logger).
I've tried XP SP3(x86) and Windows 7 (x64) with Bootcamp, Parallels and VMware Fusion. I've contacted their customer support, but I'm still waiting for a technical response.
Update - FrankenSerial workaround attempt:
In my desperate attempts to fix this I've tried to connect the device from within OSX via a pipe to VMWare. You can do this with a unix program called socat. It basically opens a read/write stream from /dev/ttsy.usbmodem662 to the VMWare's COM1 port. I managed to communicate with the device on COM1 through this solution. Unfortunately the firmware update tool first looks for a USB device called Neato XV-11 that is simulated under COM3. Switching Windows from COM1 to COM3 doesn't work neither (they probably enumerate the usb devices, so that they don't have to scan all COM ports).
Any clues what's going on?
Is this a known Windows problem (on Apple hw)?
Somehow the USB -> Serial emulation under Windows seems broken with my hardware?
Zyphrax
Posted 2011-12-18T14:54:36.717
Reputation: 81
The robot has a mini-usb port, I'm not using a serial adapter. And it works under OSX Lion so I assume the hardware is all fine. Windows is somehow causing this. The driver is directly based on Windows's usbser.sys. – Zyphrax – 2011-12-18T15:21:39.187
Sorry, apparently too early in the morning for me. – Chris S – 2011-12-18T16:10:09.290
when emulating this com port, can you adjust any flow control items? so far (as you probably know) your getting what sounds like one way communications with no acknowlegement of reciept. (not to be confused with me even knowing what that is) When doing serial stuff there was always an array of adjustements a person could make to flow, speed, handshake, and I/o stream, like 7-1 and ??? simple serial was never so simple, and they let us mess up all kinds of parameters that could cause a problem like that. – Psycogeek – 2011-12-18T19:51:50.323
I've tried changing some of the serial settings (flow control, bit setting, parity), it doesn't matter. I've updated my post with some additional information. – Zyphrax – 2011-12-18T23:56:35.317
Well you got somewhere :-) , your well beyond my skills, with this virtualising stuff. Firmware updates,, makes me think that you have to have a pretty solid, real actual connection to the device, because Safely speaking (bricking) the updates should always fully ID the device the Size etc before guessing that the firmware would fit and work. I have never (ever:-) been able to perform a firmware update without the Rawest and Only connection method they recommend and test. – Psycogeek – 2011-12-20T00:14:49.983