It's awkward to describe, because I don't use the regular client, but in the Trigger Setup dialog there's a choice between Serial and Parallel triggering. Parallel triggering checks for a simultaneous match across all the input channels. Serial triggering checks for a match on one channel over samples on successive time slots. That's how you detect a pulse. For a high-going pulse you would -- actually I should refine the description from before -- you would set the first time-slot to check for Low, and enable that slot. Set the next for High, and enable that slot. Disable the next few slots since you don't care just which slot the pulse falls back down in, but enable the slot that occurs right after the longest pulse you're testing for. That slot should check for a Low. You can see a way that this test can fail -- if a short high-pulse is followed right away by a high level you can miss the fact that the channel went low during your "don't care" slots.
I hope you can use what I've told you. I can't guide you through the dialog, because I never see that dialog. Good Hunting.
I would try serial triggering at 200MHz. Check for a sample High (or Low), skip one sample, and check for the opposite. Of course, really quick glitches could get lost between sampling periods. You might need to jury-rig hardware with a delay and an XOR to get at those.
[quote author="bigmessowires"] 7. How's the quality of the mini-grabbers that Seeed recommends for the OLS? Can the grabbers "unplug", so you can put the shaft of the wire directly onto a header pin, like some others I've seen? Any good alternative mini-grabbers from other vendors that will fit the OLS? [/quote]
The miracle of electronics is that it's become so cheap compared to other physical goods. My experience with the recommended grabbers is that they've been cost-reduced right to the limit; in the ones I got, the retractor springs overpowered the finger springs, to the point where after about 5 seconds the probe would jump off the contact. Probably other sets work better. I got some good looking clips from http://http://www.e-z-hook.com. Because electronics are so cheap compared to physical goods, a set of 16 hooks cost about as much as the OLS, and I still have to connect wire and pin headers. Sadly, the courier messed up the shipment so that I got the hooks a month late and 50km away. They missed the presentation I was going to use them in, and they're waiting till I get back into hardware and need a good set of test clips.
I would try using twisted pair or co-ax to carry the clock signal, but only ground the shield at the clock source. Then a separate ground connection from the clock generator to the OBLS might be enough.
I wonder if this isn't a more pervasive problem. I have similar issues trying to run the `screen` program to communicate with the Bus Pirate under Ubuntu 10.04. It seems as though comm. software wants to create pseudo-TTYs in a directory called /dev/pts , and permissions there are set to rwxr-xr-x i.e. writable only by root. It sometimes seems as though setting group permissions to rwx, and putting my user in the appropriate group, makes things go smoothly.
If that truly is the case then it's not Jawi's problem at all, but I haven't been able to chase down the software that sets the default permissions on /dev/pts .
A common way to remove bias is to read successive pairs of output bits until they differ, then take one -- either always the first or always the second. It has the sad effect of cutting the data rate to slightly under one-quarter (depending on the degree of bias), but it provably removes the bias.
Don't know if this is practical -- could the Bus Pirate people come up with a mode that generates an external trigger for the OBLS after some pattern is recognized?
Sorry about that. Python has gone through some changes in the Unicode area. You might get trouble just from using a different Python version from me. I was trying to be cute and put a real mu in there. You can sub that out with
The project is still alive in my mind, but it's been stuck behind other projects for quite a while. I hope to get in a new wave of upgrades; I can't tell anybody when.
Re versions, I've been running Python 2.6.5 and wx 2.8.10.1.
Good to see the mention of PyLogicSniffer. I'm glad it was there to settle your mind that your OBLS hardware was working.
This is the first feedback I've got. I'd better not be demanding feedback, though; my problem now is a pileup of work. If I get a firmware project out of the woods, then I can unpack my OBLS to test it. Then I'll have some impetus to catch up on features. RLE support if nothing else.
STK500 for AVR programming Multimeters from Canadian Tire and Velleman Logic probes -- an antique from Arkon Electronics, and a recent kit by Elenco OBLS DSO-2250 digital storage scope. Very nice. Starting to look pricey compared to new things on the market. Forces me to keep a Windows laptop. Bus Pirate to be pressed into service as a PIC programmer. I tried an Inchworm2+ from BlueroomElectronics, but either I got a dud unit, or the homebrew programming socket I cooked up is causing trouble. If I meet Mr. Blueroom at the hacklab someday, maybe we can figure it out. Sparkfun USB/Serial boards wired with test clips so I can clip serial I/O onto any random microcontroller project. Homebrew Macgraigor Wiggler clone for JTAG Olimex mini USB for same Various 78xx-based power supplies in little aluminum boxes. Wall-wart in, mini-phone jack out, external cables to match individual projects.
[quote author="BrentBXR"]I also tend to make one shot debuggers/analyses by programming an AVR real fast. [/quote] et tu BrentBXR Weller WES51 soldering station, because they go on sale periodically Actual Dremel. I was unlucky with the cheap ones I had before. Canadian Tire's first didn't accept standard collets. Their second welded the collet into the sleeve. Have my fingers crossed for this one. One of the nice Pololu ratchet-crimp tools. [/list]
Postscript works too. I made a 2-piece cardboard wrapper for my OBLS -- I guess it was lost in this month's hard-drive failure. I could re-create it I suppose.
OK. Here's something kind of like what I had before. Haven't actually glued it up, but the OBLS board seems to fit the printed copy. For what it's worth.
%!PS-Adobe-1.0 %%Creator: Mel Wilson %%Title: Open-Bench Logic Sniffer Wrapper %%CreationDate: Sun Nov 27 15:01:12 EST 2011 %%Pages: 1 %%EndComments /inch { 72 mul } def /mm { inch 25.4 div } def
% approximate dimensions of the OBLS board .. /Width 49 mm def /Length 94 mm def /Height 6 mm def /USBWidth 13 mm def% gap to cut for a USB connector /Tab 5 mm def% width of glue tab
/CutGray { 0 setgray } def% gray tone for cut lines /FoldGray { .7 setgray } def% gray tone for fold lines
%%EndProlog %%Page: 0 1 1 inch 1 inch translate .1 setlinewidth
4 inch 0 translate% over to one side to make the inner carrier /Width1 Width 2 sub def% 2/72 inches narrower for inner carrier CutGray% Draw the cut outline for the inner carrier .. 0 0 moveto Width1 0 rlineto 0 Length Height add 1 inch add rlineto Width1 neg 0 rlineto 0 0 lineto stroke FoldGray% Draw the fold lines for the inner carrier .. 0 Length translate 0 0 moveto Width1 0 rlineto 0 Height moveto Width1 0 rlineto stroke CutGray% Draw the ends of the USB socket cutout .. Width1 USBWidth sub 2 div 0 moveto 0 Height rlineto Width1 USBWidth add 2 div 0 moveto 0 Height rlineto stroke
When I say about ""glitches"" I refer to short peaks that happens between the rising and falling edges of clock of FPGA acquisition and then it´s missed by the Logic Analyzer. This glitches affect our circuit but we don´t see it if I select a slow acquisition rate. If OLS implement a glitch capture mode we can decode a I2C of 100Kbit at 200 Ksamples (with memory optimization) but see glitches that has 10 nS for example.
Would a serial trigger work? If a high capture rate gave you, say, at least two clocks within a glitch pulse, then you might catch a positive-going glitch with a value+mask combination like "01xx0" (meaning transition to high followed by two don't-cares followed by a sampled low level.
I got used to really good ratchet tools in a client's workshop, but they cost something like $300. I found the $20 pliers can be made to work, but it takes great care, and even then not every crimp will hold.
Now I'm using a pretty good low-cost ratchet tool from Pololu <http://www.pololu.com/search?query=crimp+tool&x=0&y=0>. Once in a while the crimp over the insulation will come out a tad too "fat" to fit in some plastic connector housing, and I have to compress it a bit with pliers. That's the only drawback I've found, and the price is right. I think I'm using the smaller model 1929.
"Possibly the fpga thinks it's in the middle of a long command."
It's got to be something like that. Probably I'm leaving serial data unread. I do a five-0x00 reset before I issue the 0x04, command, but as of today I see four 0x17s coming in before the first metadata token. These have to have come from somewhere else. Pretty clear that any time they were 0x00 instead, I would be taking that to mean end-of-metadata. Heigh-ho. Time to debug.
