Simulating serial bus for ‘scope reading

[Al (astral highway)]

Hi folks,

I want to read a pulse train on my’scope. It originates in some bespoke software which is normally configured to detect and pair with a device. The software has a user interface running on Windows , and I can control the duration of some waveforms on it .

The signal ( as against the display) is either a fairly low frequency train of pulses of the frequency displayed , or possibly has been output as something more complex and much higher speed.

If hook up ‘data +’ and ‘data -‘ (green / white leads respectively, removed from a five-pin mini USB jack, USB 2.0 cable) to the scope, I can’t detect anything.

I know buses have their own ways and I’m not hugely au fait with what they regard as polite , impolite , or tantrum-inducing!

In this case, it’s possible that the developer has locked things down so nothing can be read except by a paired device....but your comments and insights welcome -

Thank you

[qazxsw123]

5v rs232 or I2c

[Al (astral highway)]

It’s the standard USB cable we plug into a laptop! I don’t know enough about serial buses to know what that is...

USB requires pullups/pulldowns on the data leads to tell the other end what it is, they don't do much until they are there. It's how it knows something is plugged in.

[GMB]

Just to clarify, USB is a very complex digital protocol. The description "Universal Serial Bus" may have given the impression that it is a bit like RS232. It isn't, not even remotely.

So unless your device knows how to operate the USB protocol, do not try connecting directly to it.

Instead you should look for a USB device that provides an interface that you can use.

[Al (astral highway)]

Thank you Hugo and GMB,

I’ll start reading up on the protocol! My ‘scope definitely doesnt havea compatible interface.

[GMB]

I wouldn't waste your time on that.

I have designed USB devices so I can tell you that the only way you can operate USB is by using processors with a USB interface mechanism that handles the fast parts of the protocol.

If you want to play about with the actual signals on USB you need a USB protocol analyser - which is not entirely cheap. The problem is that if anything goes ever so slightly wrong it all just stops or loops.

You can buy USB modules that conveniently do serial protocols over USB, these are cheap and easy to use.

[MrBungle]

You can analyse the USB protocol in software at a higher level of abstraction.

I use Wireshark for this with USPpcap. Have a google around for tutorials. It will take longer amount of time for me to explain how to glue the relevant bits together.

I have used it to reverse engineer and port a HID driver to Linux.

[Al (astral highway)]

Originally Posted by GMB

You can buy USB modules that conveniently do serial protocols over USB, these are cheap and easy to use.

That sounds like a good plan, thank you.

[Al (astral highway)]

Thank you Mr Bungle. That sounds very interesting and helpful.

GMB, will this do the trick? Photo attached

There seem to be some very cheap Chinese alternatives but I know this supplier.

[GMB]

The FTDI FT232R chip normally does RS232, so I am not sure what that board is doing. But that is the kind of thing to use if you want to interface to something that doesn't do USB protocol. I admit I am slightly hazy on what you exactly wanted to do.

It is a shame that the modern interfaces are so complex. In the old days you could re-purpose a parallel printer port to do almost anything you wanted as there was a simple way to directly use the data signals. Sadly not any more. All a USB link will do is USB because the low level signalling needs dedicated hardware support so is usually impossible to re-purpose.

What Mr Bungle was describing is just a way to examine the USB packets where you have a working USB connection.
By the way, the easiest way to do DIY USB is using Linux which makes it almost trivial to drive a USB port at the packet level, unlike Windows. But you can't get below the packet level as a rule.

[Al (astral highway)]

Originally Posted by GMB

I admit I am slightly hazy on what you exactly wanted to do.

I've got a now oldish interface designed on windows, probably dating from 2005; it allows the frequency and duty cycle of pulses to be altered, with several channels. I'm simply curious about the way this was done, by 'lifting up the lid' off the software. I've examined the circuit that was driven by the pulses and it has some ingenious features.

So I thought it would be a simple matter and a logical first step (excuse the pun) for me to look at data outputs that correspond with what's on the screen in front of me.

Originally Posted by GMB

...it is a shame that the modern interfaces are so complex. In the old days you could re-purpose a parallel printer port to do almost anything you wanted as there was a simple way to directly use the data signals.

Ahah, yes, it is a shame those days are gone. It would have been so much easier.

Originally Posted by GMB

What Mr Bungle was describing is just a way to examine the USB packets where you have a working USB connection.
By the way, the easiest way to do DIY USB is using Linux which makes it almost trivial to drive a USB port at the packet level, unlike Windows. But you can't get below the packet level as a rule.

Thanks, that's a great clarification. Curiosity drives me to interesting places; looks like there's some learning on the way!

I'll buy a breakout board for the RS232 conversion.

[cmjones01]

Originally Posted by astral highway

I'll buy a breakout board for the RS232 conversion.

Do bear in mind that if you're using an existing piece of software to control the USB device you've got, it is very unlikely (unless if has an explicit COM port setting) to recognise your USB-RS232 breakout board.

These FT232-type boards are great if you're developing a new device and software to go with it, or you just want a generic serial port connected via USB, but they are not a general-purpose solution for adapting arbitrary proprietary USB devices to RS232. USB doesn't work that way - it's a much more complex set of protocols.

Chris