EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: RBBVNL9 on August 08, 2021, 09:43:27 am
-
Dear all, I’m sure there are quite some PicoScope experts on this board…
I’m not managing to accomplish a seemingly simple task and could use some help.
I want to decode USB (1.0/1.1) data between two devices, and neither is a PC, so Wireshark is not an option. Of the oscilloscopes I have at my disposal, only the PicoScope 3405D supports USB Serial Decode. So that is what I am trying to use.
To prepare for that task, I started by practising signals from a simple USB keyboard. It uses the USB low-speed protocol (1.5 Mbps), and, as expected, we see on the data+ line some activity every 1.0 ms (I believe a Start of Frame Packet). Every 8th activity (so every 8.0 ms), the keyboard is polled and (unless a key is pressed) it responds with a NAK handshake, indicating it sees the poll but has no data to send. So far, so good. I can see these signals on the Picoscope, and when the USB Serial Decode is properly configured, I can see the protocol being decoded and these NAK messages passing by.
But I am, of course, only interested in seeing the messages when a key is pressed, and the messages have some data payload. In the PicoScope USB Serial Decode I occasionally can see such messages with payload. But my problem is that I cannot detect them in a reliable way, it seems. I need a good way to trigger at such messages or filter them out afterwards.
So, I tried two routes:
- Try to set the trigger to fire on messages with a payload (only). Unlike most oscilloscopes with serial decode options, the PicoScope is not able to trigger on events from the serial decode. So, one needs to resort to the ‘regular’ trigger options. Sporting a digital trigger, the PicoScope seems to have quite advanced trigger options (simple edge, advanced edge, window, pulse width, interval, runt, window pulse width, level dropout, window dropout). PROBLEM: But no matter what I try, I do not manage to set up a trigger that only fires on long messages (with a payload) and ignores short messages (with just a NAK).
- Trigger on all USB messages (which is easy) and subsequently filter for viewing only those messages that have data payload. This can be done by setting the filter on the ‘package type’ field for values “DATA0”, “DATA1” or just “DATA”. PROBLEM: While I sometimes do see messages with a payload, this method seems to miss most instances where I press a key on the keyboard.
So, does anyone have some advice how to reliably decode USB messages with payload using a PicoScope? Thanks!
PS. I am using the latest stable build of PicoScope for Windows (6.14). The sampling rate is set to 60kS, which is sufficient to properly observe this (slow) USB signal and.
-
For starters , the sampling rate set to 60kS is not enough to sample properly signal that has signaling rate in 1.5 Mbps. Try sampling with at least 5MS/sec, to get at least 4 samples per symbol for reliable edge detection.
As for triggering, AFAIK, there is no sort of burst length trigger.
What would be needed is putting a retriggerable monostable with monostable pulse longer than signaling rate period on the signal.
Or some other way to demodulate envelope of burst.
That would create pulse for the duration of burst. And then trigger from that envelope with pulse width type of trigger...
-
Triggering on patterns in USB sounds like a good feature, maybe submit to Picoscope?
-
Dear 2N3055, thanks!
For starters, the sampling rate set to 60kS is not enough to properly sample a signal that has a signaling rate on 1.5 Mbps. Try sampling with at least 5MS/sec, to get at least 4 samples per symbol for reliable edge detection.
Good point. I selected the 60kS sample rate just by looking at the waveform, not asking myself what rate would be necessary for properly capturing a 1.5 Mbps signal. In the back of my head, I wanted a low sample rate so I could perhaps store a long time range in memory and analyze afterward.
Having that said, the USB signal is still decoded properly when sampled at 60kS (see attached screenshot). Higher sample rates are probably more appropriate but do not solve my problem as such.
[attach=1]
As for triggering, AFAIK, there is no sort of burst length trigger. What would be needed is putting a retriggerable monostable with monostable pulse longer than signaling rate period on the signal. Or some other way to demodulate envelope of burst. That would create pulse for the duration of burst. And then trigger from that envelope with pulse width type of trigger.
Makes sense, with additional hardware I could make a simple block wave that is a long as the USB message, and then the Picoscope would be able to distinguish a long block wave from a short one for triggering purposes. I was hoping to solve the problem without additional hardware (I am travelling and the PicoScope is one of the few things I have here ;-) but if I find no other way, I will follow your suggestion!
Thanks again, Rudi
-
Triggering on patterns in USB sounds like a good feature, maybe submit to Picoscope?
SilverSolder, yes, that would be a greatly valued feature indeed, not only be me but by many, I suppose. [Like everyone doing any kind of serial decoding work on a Picoscope...]
But it is soo obvious (and present in every other scope I used that has serial decode) that I get the feeling there must be some kind of design restraint why Picotech did not add this in the first place. Then again, perhaps I should not speculate...
-
Triggering on patterns in USB sounds like a good feature, maybe submit to Picoscope?
SilverSolder, yes, that would be a greatly valued feature indeed, not only be me but by many, I suppose. [Like everyone doing any kind of serial decoding work on a Picoscope...]
But it is soo obvious (and present in every other scope I used that has serial decode) that I get the feeling there must be some kind of design restraint why Picotech did not add this in the first place. Then again, perhaps I should not speculate...
Rudi,
I took a look at few other scopes and if you don't use protocol triggers, their analog triggers also don't support "burst length" trigger (let's call it that for now). But on scopes that support Zone triggering, I do that with zones: You setup basic trigger and by using zones define burst length..
If you happen to go forward with the trigger gizmo I might help a bit, time permits..
Regards,
Sinisa
-
Sinisa, thanks for the information and the offer. I now decoded a few other 'simple' devices on both USB Low Speed (1.5 Mbps) and Full Speed (12 Mbps) and I am getting a better grip on its decoding, even though the base problem I posted originally is not solved yet.
More relevant, I also did some USB protocol testing on a measurement instrument with USB control (in this case an ElektroAutomatik EA-PS 2042-20B power supply my son happened to have here). Interestingly, here I never get to see any USB packets with a data payload, even when I know that factual communication is occurring. Now I noted that this device actually emulates UART serial protocol ("COM") over USB, and I suspect that the serial bytes to be exchanged are simply transmitted in short USB 'signalling' messages and not via a USB message of the "DATA0" / "DATA1" / "DATA2" packet type and associated data payload.
The reason I am writing is this is because I will have to wait to see how the device I eventually want to decode (and which I do not have here right now) actually exchanges data via USB. If it indeed uses data payload, I might indeed be happy to have your further help/suggestions for an additional circuit that facilitates triggering. But if the ultimate device is actually emulating UART over USB, then there is no need to go into that route...