Trouble Triggering/Decoding Data on DS1054Z - Page 1
Forum section: electronics / beginners

author: metrologist
author_rank: Super Contributor
timestamp: June 10, 2016, 06:34:20 am
content: I have a continuous, 8-bit data stream of four characters "ABCD" running at 4Mbps. The pattern repeats and I want to verify that it repeats properly every time, so I would like to get a stable waveform on the scope when in normal trigger mode or use the decoder.I've tried decoding this with SPI and setting the timeout to around each 8-bit segment (2 µs) and I cannot get it to decode. I have decoded a regular SPI stream that has some amount of delay between each 8-bit character, so I think missing this delay is confusing the scope.I also tried decoding RS232 setting up the data rate, but I think needing a stop bit is throwing off the decoder.I then tried triggering on one of the characters using both SPI trigger and RS232, and the scope will not see a character or pattern (i.e. LHLLLLLH for the letter A (65)).I tried a couple other triggering schemes such as twiddling around a 4 µs holdoff; or setting up nth trigger on the clock, 127th edge after ~400+ idle time to get a trigger and it was not happening. I'm confused about nth trigger because I could not get it to run on the clock no matter how I set it up, I could just get one off trigger events when I twiddled the idle time or edge number.I also tried recording 8 µs segments and scrolling through them in playback. I thought the scope might start a new recording every 8 µs, but it seems to use the displayed time scale for each segment (or frame).I can of course single shot and zoom and scroll through the pattern, but keeping track of bits is hard, and the real test pattern is going to get more complex, so getting some sort of reliable trigger or decoding would help.Here's some photos with the A character cued up to the start of the sweep. Each character takes two divisions.

author: Electro Fan
author_rank: Super Contributor
timestamp: June 10, 2016, 07:01:13 am
content: Seems like you might have some grounding and ringing issues - but those might or might not be preventing accurate decoding. As a start you might consider a simpler baseline - maybe focus on RS232 at a slower speed - maybe 1200 or 9600. Then you could see what happens as you crank up the speed or try SPI.

author: tautech
author_rank: Super Contributor
timestamp: June 10, 2016, 07:20:57 am
content: Datastream idle time High or Low can have a dramatic affect on successful decoding, have you set this correctly?

author: metrologist
author_rank: Super Contributor
timestamp: June 10, 2016, 04:11:15 pm
content: I was able to decode a regular 4Mbps SPI signal, but this is a straight byte stream without any idle time between bytes as illustrated in "Figure 8:SPI Byte Timing –tdis the setup time between SPI bytes and tbis the total byte-to-byte time." fromhttp://www.totalphase.com/support/articles/200468316-Aardvark-I2C-SPI-Host-Adapter-User-Manual(about 1/4 the way down the page) - so I have configuredtdto zero, where a minimum of 7 µs is specified. I think this is why using SPI protocol decoding fails. I'll look for the idle time H/L setting, but would this be for SPI or RS232 decoding?Otherwise, the pattern should be repetitive so I would expect to be able to trigger on some event (like nth edge or a bin data character) and I have not figured it out yet. Or, my pattern is actually NOT consistent like I expect (that is what I am trying to verify)... With single shot, it looks consistent when scrolling through a number of bits, but there could be a bit or two delay that happens in long intervals that I have not scrolled to yet (needle in haystack)...

author: rstofer
author_rank: Super Contributor
timestamp: June 10, 2016, 05:03:42 pm
content: For SPI, have you tried syncing on CS'. I would think the decoder needs to know where things start. There's a similar problem finding the START bit on RS232. How to tell it's really a START and not just a wide spot in the bit stream. When I played with this a couple of weeks ago, I added a little delay between chars to get it to sync. I haven't run into it but I would think that hardware RS232 decoders would have a similar problem with a continuous stream.I'm not working on an SPI based project at the moment but, still, I'm beginning to think that decoding just isn't all that important. I need to know that CS' frames the packet properly and I need to now the relationship between clock idle and clock active edge but in terms of the payload, well, I just sent it! I should already know what it is. If there's any doubt, I drag out something like printf().I have a project that uses SPI to send packets from an FPGA to an mbed (LPC1768) at around 6.25 MHz and, somehow, I got it working without a DSO and decoding. I used a non-DSO scope to verify CPOL and CPHA as well as checking that CS' stayed low throughout the packet but, beyond that, it just plain worked.

author: metrologist
author_rank: Super Contributor
timestamp: June 10, 2016, 06:04:11 pm
content: The project is not necessarily SPI or data based. It is supposed to be an arbitrary pulse pattern generator. I was hoping to leverage a binary character data stream for this using SPI out of normal operation. So, I do not have a CS line, just clock and data.

author: metrologist
author_rank: Super Contributor
timestamp: June 10, 2016, 08:56:03 pm
content: I'm a little rusty, but thinking about this today, I may be making a rookie triggering mistake. That is I was setting holdoff to 8 µs, less than my sweep 12 µs sweep time when triggering on the clock. Still not sure why nth edge did not get it... more play time tonight...

author: metrologist
author_rank: Super Contributor
timestamp: June 11, 2016, 12:55:40 am
content: All right, never mind. I don't know what I was doing yesterday, but plain old edge trigger and trigger holdoff of just under 8 µs works fine. I might have had some setting toogled that I'd forgotten about - has happened before.