EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: Howardlong on September 12, 2015, 04:28:37 pm
-
Folks
The SPI decode on my MSO 7104B seems not to work reliably above 35MHz clock rate. I've tried it on both analogue and digital channels, but no luck. I tried adjusting the digital threshold and analogue trigger levels on the appropriate channels, but still no luck. In contrast, the decoding the same on the Agilent 54831D and even Rigol MSO1074Z does decode perfectly well on both analogue and digital channels.
Can anyone either confirm my findings one way or another please, or suggest a course of corrective action for this operative?
-
Howardlong,
I recommend you send an email to scopes_support@keysight.com detailing your problem. They are more than happy to assist you.
Regards
Alex Klimaj
Product Marketing Engineer
Keysight Technologies
-
I second that. I needed some help to set the decoding thresholds for analog channels and after a few e-mails between me and tech support I got the answer (select channel and use the trigger level knob to set the threshold).
-
I second that. I needed some help to set the decoding thresholds for analog channels and after a few e-mails between me and tech support I got the answer (select channel and use the trigger level knob to set the threshold).
FWIW, I did have to RTFM the trigger level thing myself on the analogue channels for trigger and decode. It wasn't that I wasn't expecting to have to do it, it was that I didn't know how to. The LA channels are more obvious in that respect.
-
Sure you don't have bandwidth limiting, trigger HF reject and that sort of things enabled? I'm just guessing here.
-
Analogue ch bandwidth off on all channels, the same applies to digital channels too.
All the following traces are at 40MHz clock. If I reduce the clock to 35MHz it works 100%. At 50MHz, all hell breaks loose, as it misses clocks (the number of clocks in each frame is displayed when you zoom out).
The test is 16 consecutive bytes, 0x81 is the first byte, followed by 0x01, 0x02, 0x03 ... 0x0F. Sample on falling edge, CS is active low.
You will see that the first byte in the lister is sometimes decoded correctly as 0x81, but at other times it's 0x01.
Analogue first.
Analogue setup:
(http://i34.photobucket.com/albums/d123/photobucket391/scope_1_zpsgcrjleei.png) (http://s34.photobucket.com/user/photobucket391/media/scope_1_zpsgcrjleei.png.html)
Lister:
(http://i34.photobucket.com/albums/d123/photobucket391/scope_0_zpscio2aul4.png) (http://s34.photobucket.com/user/photobucket391/media/scope_0_zpscio2aul4.png.html)
Correct decode, zoomed in:
(http://i34.photobucket.com/albums/d123/photobucket391/scope_2_zpswlcyfrlj.png) (http://s34.photobucket.com/user/photobucket391/media/scope_2_zpswlcyfrlj.png.html)
Incorrect decode, zoomed in:
(http://i34.photobucket.com/albums/d123/photobucket391/scope_3_zpskfhw8lqb.png) (http://s34.photobucket.com/user/photobucket391/media/scope_3_zpskfhw8lqb.png.html)
Now the LA version.
Lister, showing incorrectly decoded first byte sometimes:
(http://i34.photobucket.com/albums/d123/photobucket391/scope_5_zps3g8hszk5.png) (http://s34.photobucket.com/user/photobucket391/media/scope_5_zps3g8hszk5.png.html)
Correct decode, zoomed in:
(http://i34.photobucket.com/albums/d123/photobucket391/scope_6_zpsbavqtcsg.png) (http://s34.photobucket.com/user/photobucket391/media/scope_6_zpsbavqtcsg.png.html)
Incorrect decode, zoomed in:
(http://i34.photobucket.com/albums/d123/photobucket391/scope_7_zpsozfwrhdh.png) (http://s34.photobucket.com/user/photobucket391/media/scope_7_zpsozfwrhdh.png.html)
-
Very weird! I'd definitely contact support.
-
@ Howardlong:
Is solved? And if so, what was the problem?
Cheers.
-
@ Howardlong:
Is solved? And if so, what was the problem?
Cheers.
Nope, not yet, I used a Rigol MSO1074Z to do what I needed to do in the end (!)
I don't know if it's just my unit, a firmware feature (I am on 6.17 which appears to be 0.01 more recent than what's on the Keysight website), or a more general limitation of the 5000/6000/7000, so I guess if someone could try it that would confirm one way or the other.
-
I don't know if it's just my unit, a firmware feature (I am on 6.17 which appears to be 0.01 more recent than what's on the Keysight website), or a more general limitation of the 5000/6000/7000, so I guess if someone could try it that would confirm one way or the other.
No idea, and for now I can't test it with my oscilloscope, sorry.
Currently the latest version is 6.20 for 6000 sries, but minor enhancements.
The last known issue related to the SPI was corrected with version 2.19 of gsp6000.jzp.
The current version for 7000 series (system) is: 06.20.0000 (2015-06-27). Maybe worth trying.
Cheers.
-
Version 6.17 is right around the time they fixed the issue with the SPI decoding so it might be a matter of simply doing a firmware update.
-
Thanks for the heads up: the last time I checked the firmware was 31 July this year, the website was still showing 6.16... from May 2011!
I've just updated to 6.20 but still no joy, the same symptoms remain.
One thing I should note is that although decode doesn't work beyond about 35MHz, the SPI trigger does work perfectly.
Irrespective of the outcome, thanks again for the heads up: on the basis that the last publicly available firmware was previously from 2011 (6.16) and that mine (shipped from Keysight a couple of months ago with 6.17, dated Dec 2011) I'd assumed incorrectly that this was essentially a dormant product from an update perspective.
-
I'll have to bring up a board which has SPI later this week. I'll try and see if I can reproduce your findings.
-
That would certainly be appreciated, if you get the opportunity.
In the meantime, is there a way to increase the amount that the lister can either display or export? I did a rough calculation on the LA alone with three digital channels operating, with 1ms/div (so 10ms span) it samples at 200MSa/s, giving 2Mpts. The lister only displays a very small proportion of what's been captured, 100us worth, or 1% of the total capture.
I realise I can use segmented memory, however this would incur missing data in longer traces between segments, something I'm trying to avoid.
-
I just did some tests. Unfortunately the (lower end) microcontroller I'm using can't go faster than 24MHz. I was hoping it could do 48MHz somehow. I tried how far I could push the time/div down and at a 24MHz SPI clock I could still get a good decode at 2ms/div (acquisition set to sample). When scrolling through the list I could not spot any missing frames over the 20ms capture (50Ms/s according to the scope). The signal looks crap though and not all clock pulses where recognizable with the eye so it seems it does some adaptive level guessing when decoding signals. I'm actually surprised how the scope manages to make something from such a crappy (almost undersampled) signal! :wtf:
(https://www.eevblog.com/forum/testgear/spi-speed-limit-on-agilentkeysight-dsomso-500060007000/?action=dlattach;attach=173588;image)
-
I can't promise anything but I'll check tomorrow if at my workplace there's still a MSO6k/7k left (haven't seen one for quite some time so I guess they're gone but who knows), and if so I can check.
If not then I can at least ask some of my colleagues who worked with these scopes if they know anything about your problem. I know some worked on a project that involved SPI, so they might know.
-
I just did some tests. Unfortunately the (lower end) microcontroller I'm using can't go faster than 24MHz. I was hoping it could do 48MHz somehow. I tried how far I could push the time/div down and at a 24MHz SPI clock I could still get a good decode at 2ms/div (acquisition set to sample). When scrolling through the list I could not spot any missing frames over the 20ms capture (50Ms/s according to the scope). The signal looks crap though and not all clock pulses where recognizable with the eye so it seems it does some adaptive level guessing when decoding signals. I'm actually surprised how the scope manages to make something from such a crappy (almost undersampled) signal!
Now I am scratching my head! Firstly, I am assuming that you weren't using segmented memory, just a single long continuous acquisition. About how many lines of decode are there in that lister? The reason I ask is that as mentioned earlier mine seems to give up quite early on in a single long run. Also from your picture, it's somewhat impressive it decodes at all! You're very close to nyquist and on an analogue channel.
I am hoping this inability to decode single long acquistions is operator error at my end!
-
I can't promise anything but I'll check tomorrow if at my workplace there's still a MSO6k/7k left (haven't seen one for quite some time so I guess they're gone but who knows), and if so I can check.
If not then I can at least ask some of my colleagues who worked with these scopes if they know anything about your problem. I know some worked on a project that involved SPI, so they might know.
I think they're probably close to being phased out, in some ways a shame because the VxWorks based scopes from Agilent/Keysight have the fastest responding UI I've ever seen on a DSO. I have yet to try their Windows CE (or whatever it's called these days) scopes with any gusto to see how they compare.
-
Keysight says that 25 Mbps is the maximum decodable SPI clock rate:
http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293 (http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293)
Regards,
Janne
-
Keysight says that 25 Mbps is the maximum decodable SPI clock rate:
http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293 (http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293)
Regards,
Janne
Thank you, I guess that answers the question then! I hadn't realised there was a separate datasheet for this option.
-
Keysight says that 25 Mbps is the maximum decodable SPI clock rate:
http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293 (http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293)
Hmmm. I guess the hardware decoding isn't so great after all. Given the limits it seems like it is implemented as some kind of programmable statemachine in an ASIC.
-
I think they're probably close to being phased out, in some ways a shame because the VxWorks based scopes from Agilent/Keysight have the fastest responding UI I've ever seen on a DSO. I have yet to try their Windows CE (or whatever it's called these days) scopes with any gusto to see how they compare.
Yes, the old DSO6k/7k Series were pretty swift, good standard scopes with a decent UI. The DSOX Series is pretty reponsive as well.
Keysight says that 25 Mbps is the maximum decodable SPI clock rate:
http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293 (http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293)
Well, I guess that settles then.
Hmmm. I guess the hardware decoding isn't so great after all. Given the limits it seems like it is implemented as some kind of programmable statemachine in an ASIC.
Probably. Agilent/Keysight scopes have been and still are pretty ASIC heavy (almost everything is done in an ASIC). I'm not much of fan of such ASIC heavy scope designs. ASICs may (or may not) be faster initially until standard processors catch up, but they're also expensive and a lot less flexible than COTS processors, and can quickly become a bottleneck (like the Megazoom with its small sample memory in the DSOX Series).
-
Keysight says that 25 Mbps is the maximum decodable SPI clock rate:
http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293 (http://literature.cdn.keysight.com/litweb/pdf/5989-5126EN.pdf?id=811293)
Hmmm. I guess the hardware decoding isn't so great after all. Given the limits it seems like it is implemented as some kind of programmable statemachine in an ASIC.
Which is interesting, because the SPI trigger appears rock solid, it's just the decode.
Surprisingly, the same 25Mb/s limitation also seems to apply to the current 2000, 3000, 4000 and 6000 X-series SPI decoders. These days I'd say that is quite a restriction. http://literature.cdn.keysight.com/litweb/pdf/5990-6677EN.pdf (http://literature.cdn.keysight.com/litweb/pdf/5990-6677EN.pdf)
-
On my Hameg it's even max. 12.5 Mbit/s (up to 200MHz BW model), Max 25 Mbit/s on the higher bandwidth models.
(5Mbit/s for I²C and 31Mbit/s for UART)
-
I just did some tests. Unfortunately the (lower end) microcontroller I'm using can't go faster than 24MHz. I was hoping it could do 48MHz somehow. I tried how far I could push the time/div down and at a 24MHz SPI clock I could still get a good decode at 2ms/div (acquisition set to sample). When scrolling through the list I could not spot any missing frames over the 20ms capture (50Ms/s according to the scope). The signal looks crap though and not all clock pulses where recognizable with the eye so it seems it does some adaptive level guessing when decoding signals. I'm actually surprised how the scope manages to make something from such a crappy (almost undersampled) signal!
Now I am scratching my head! Firstly, I am assuming that you weren't using segmented memory, just a single long continuous acquisition. About how many lines of decode are there in that lister? The reason I ask is that as mentioned earlier mine seems to give up quite early on in a single long run. Also from your picture, it's somewhat impressive it decodes at all! You're very close to nyquist and on an analogue channel.
I am hoping this inability to decode single long acquistions is operator error at my end!
I figured this out: in order to get the lister to completely decode all memory, you need to use single shot. it doesn't seem to work if you simply stop a running trace, only a fraction of the waveform memory is decoded. I did one with 22,500 frames of 16 bytes earlier today this way, I did receive a warning at the extreme to say the lister had given up decoding at this point, but it was a deliberately extreme test: that is a 2.88Mbit decode with 8Mpts. The decode does take a few seconds to happen in this case, probably the only time you'll ever be hanging around for these scopes: it doesn't hang, it just takes a short amount of time during which time the UI remains otherwise completely responsive.
-
That is odd. My DS7104 decodes everything when I press stop. It does take a while to process though.