Reverse-engieneering the interface to a USB9097 1-wire adapter

[Isamun]

Good evening good folks!

I tried searching around, but have not found anything useful about this topic. Maybe Im just stupid =D

I am a student wrapping up a bachelors degree in communication technology. During our class in "computer aided data acquisition" we were assigned the task of getting some Maxim DS18B20s to work from a cheap, third party usb adapter called USB9097 and writing a LabView user interface. Apperently students have tried this before without luck.

I am in the lucky position of having a MSOX3000 scope with every option in the book at our disposal.

Firstly I tried and succeeded with getting communication going between the DS18B20 and a bus pirate in 1-wire mode. But I have not yet gotten the USB9097 adapter to communicate with my computer. I am suspecting that the adapter might be fried.

This assignment consists of many topics we have never touched upon in class. For instance, I am wondering how the USB port emulates a serial port. I tried scoping the USB lines and decoding them on the scope. But this has gotten me nowhere. Am I correct to assume that the USB protocol has some low-level overhead on the packets meaning that I cant decode them as regular serial communication?

Assuming that I can get the USB9097 to work with its provided software. How can I decode/look at the messages being sent to it? Is this scope work or better suited for some PC based port monitor?

Anything to put me on the right track is warmly welcome.

Regards,

[Rerouter]

all usb commands are packetised, so serial decoding will not work directly,

equally it is differential with 3 symbols, j k and 0,

better to work on attacking the devices functionality than its high level protocol

all that adapter is, is a usb to serial adapter with a DS2480B tacked on after it, so by all rights any usb to ttl adapter will work in the mean time, and you just need to read over the datasheet to model your control script around that chip, http://datasheets.maximintegrated.com/en/ds/DS2480B.pdf

[amyk]

This? http://owfs.org/index.php?page=usb-usb9097 Looks like they found another way to reuse those surplus USB sound card casings...

As for scoping USB signals, an MSOX3000 will work for low and full-speed USB, although you may have to manually decode the two lines.

[apelly]

Some googling will net you free and open usb sniffing software for windows and linux. You can also watch it from the other end with a few lines of code on an mcu.

[avishorp]

I didn't quite understand what you want to do. If your final task is only to read temperature from a DS18S20 sensor, you should choose much easier path, such as connecting it to an Arduino and sending temperature values to the serial port.
If your main goal is to make the dongle work, you're facing a real challenge. Oscilloscope is not the proper tool for decoding USB traffic (unless it has a special mode capable of doing so); a USB sniffer is what you need. But even if you have one, you are not going to see any meaningful data exchange between the dongle and the PC unless there is already a software that communicates with it. The best thing you can do is to crack the dongle open, see which chip is used inside and try to find its datasheet. I bet it is this one.

Avishay

[Isamun]

Thank you for your feedback.

I have made some minor progress.

I popped the hood of the dongle to revile two chips


The larger one is a CH340 USB to serial converter and the small SO8 package is the DS2480 1-Wire chip.

As I suspected the module to be fried I hooked it up to some digital channels and tried to talk to it though Putty.



This has in my mind confirmed that the module is working, but I still cant get it to communicate with the provided software (TEMPer1W, section 22)

I didn't quite understand what you want to do. If your final task is only to read temperature from a DS18S20 sensor, you should choose much easier path, such as connecting it to an Arduino and sending temperature values to the serial port.
If your main goal is to make the dongle work, you're facing a real challenge. Oscilloscope is not the proper tool for decoding USB traffic (unless it has a special mode capable of doing so); a USB sniffer is what you need. But even if you have one, you are not going to see any meaningful data exchange between the dongle and the PC unless there is already a software that communicates with it. The best thing you can do is to crack the dongle open, see which chip is used inside and try to find its datasheet. I bet it is this one.

Avishay

The goal is to create a LabView user interface for the USB9097. I know I dont have to probe the USB directly, but I have zero experience with USB encoding and had to satisfy my curiosity

As I see the road ahead, I have to get the software to work so I can observe its behavior and try to mimic that in my LabView code.

Any suggestions welcome!
I will of course keep you up to date on my progress

[Isamun]

Well what do you know! I was dicking around with the drivers, deleting the entire COM port register and now the software has decided to work!

I think i might be on to something here

[poorchava]

What sort of operating system are you using on the computer which you connect the dongle to? I remember that when I was developing USB stuff for my master's thesis I had shitload of problems with getting USB to work on x86 and x64 systems at the same time. Also Win XP and Win7 were difficult to get working within the same code.

Perhaps there's something up with that?

[Isamun]

What sort of operating system are you using on the computer which you connect the dongle to? I remember that when I was developing USB stuff for my master's thesis I had shitload of problems with getting USB to work on x86 and x64 systems at the same time. Also Win XP and Win7 were difficult to get working within the same code.

Perhaps there's something up with that?

Im sorry if I didnt make myself clear in my last post. Drivers are working fine now.  Issues was related to some 1-wire driver not directly related to the CH340 serial driver. Also the provided software didn't communicate with devices with a COM# higher then 15. I simply deleted the entire COM port register and it started working

Edit: Im using Win7 64-bit, btw.