Products > Test Equipment

DIY Logic Analyzer Probe and Pods for Siglent (and LeCroy) scopes

<< < (30/51) > >>

mawyatt:

--- Quote from: Slartibartfast on July 14, 2021, 09:43:37 am ---
--- Quote from: mawyatt on July 13, 2021, 11:43:04 pm ---I use the single 8 bit input mostly, in fact have yet to find a need for the full 16 bits use, and could even use the single bit lines now since I'm sensing SPI lines.

--- End quote ---

That is exactly what I anticipate for my usage scenarios too, hence my preference for detachable pods and wiring.

So I'll do my own design then. Should not be much work given all the information on the circuitry you have provided in this thread.

You have correctly pointed out that oz2cpu's in line resistors at the base do not terminate, but it seems in your design you also only use in-line resistors, instead of parallel-connected terminators. Is that work left for the future, or is there some background to it that you did not explain in the thread?

--- End quote ---

I did some simulations of what I thought the scope input looked like, and was able to get a close pulse response to what Rob at tautech had shown (measured, see earlier in this thread). First off the twisted pair is not terminated with the characteristic impedance (100~130 ohms depending on the cable) on either end, this would load the input probe too much and attenuate the signal too much at the scope end. The cable is AC terminated with an RC network on each end that allows a reasonable input impedance as "seen" for the device being probed and doesn't attenuate the signal too much for the scope to sense. The network I did allows this with select Rs and Cs. However, I have not had time to create the optimum network RC values just yet, will do so later when time allows, so for the beginning just included the series resistors and series capacitor.

Here's what the schematic and PCBs look like. I got 2 types of twisted cable off eBay for ~$25 each, the one I've used is like the 3M type mentioned in the thread, the other is a larger cable but should also work. Also have a few PCBs somewhere, but really don't have the time now to pull all this together (in middle of a major project which is benefiting from this LA), later in a couple months. PM if you want more details or files if I can get them easily.

Best,

mawyatt:
Few more.

Best,

Slartibartfast:

--- Quote from: oz2cpu on March 06, 2021, 02:03:47 pm ---here you go, i think TK was the one to first provide the pinouts, he shared this file attached,

--- End quote ---

There is something wrong here. TK seems to have messed up the side designations.

PCIexpress standard documents state the "lower side" of the board (i.e. "solder side") is "Side A", while the  "upper side" ("components side") is "Side B". This coincides with the orientations of the PCBA sides when looking down the PCIe card onto the PCIe socket, and placing it such that the 11-pin section is at the left, with pin counting from left to right (in a PC, this amounts to placing the I/O shields to the left). (edit: used to be with PCI but incorrect for PCIe)

TK has called the lower side "Side B" and the upper side "Side A", in contradiction to the standard. Depending on whether the table was meant to give the layout looking into the socket, or onto the edge connector, either could be right. So, in the two header lines in the pin table posted by TK, which is the correct line? The one denoting A vs. B, or the one lower vs. upper?

Since we're dealing with a scope that clearly defines directions up and down I suspect I can trust the "Upper" vs. "Lower" designation, and "Side A" vs. "Side B" are chosen arbitrarily (opposite to standard). Can somebody confirm, or state what is correct?

Edit: Just realised the fact that in a typical tower case PC the PCBA is mounted upside down (component side pointing down) may be the source of the confusion. If that is true then indeed TK assigned A and B correctly, and with "upper" and "lower" he just referred to the sides as referring to the scope's "up" and "down", different from the PCIe standard which has the component (upper) side down, and vice versa.

https://web.archive.org/web/20111102042843/http://www.adexelec.com/faq.htm#pcikeys

oz2cpu:
if you look at the pictures of the pcb layouts in post 1
you will see what is what,
also the pcb is impossible to flip in the 3D printed case, and the edge connector and case is impossible to stick into the scope wrong.
you are welcome to reinvent it all, once again,
but you can also just download the free available ordering zip, send it to JLC or similar place
3D print the shells, and be done in a week,
it is a well tested design, we are many users now on this design.
here is a picture from last week, when i designed a PID system for a robot motor controller

AlexDavidson:
Thanks to the great work by oz2cpu and the boards he sent me, I’m now able to use the digital channels on my SDS2000X+. I had no problems printing the cases and assembling everything, and it all seems to work as intended. A note to others using this solution: the wires used for cabling shouldn’t be more than 0.75mm diameter otherwise you will have trouble soldering to the boards and fitting into the cases. I used twisted pairs removed from HDMI cable as suggested earlier in this thread.

The main reason I wanted to enable the digital channels was to assist in debugging communication problems in a project with 6 daisy-chained SPI devices (AS5048A encoders). Using the LA probe I was able to connect 4 digital channels to the master SPI, freeing up the analog channels to look for noise etc along the chain & power supply rails. I used both pods so I could set 2 different thresholds, because some of the signals were 5v & others 3v3. At one point I also connected digital channels to the MISO/MOSI interconnections along the daisy chain to check that data was being shifted along correctly, but this is not shown in the capture below.

For those interested, the trigger for the capture below was MISO bit 14 set, which happens to be the AS5048A error flag bit. Decoding was set to use clock timeout because CS only changes every 6 packets. S1 & S2 are both decoding the same data - one is set to hex display, the other to binary to make it easy to spot bit patterns. The analog channels were connected to CS & CLK as a cross-check for glitches, and C3 was connected to an MCU output pin used for debugging.

Following the trigger, which in this case came from the 4th encoder in the chain, code in the project sends a UDP packet to a host PC, which is why SPI data stream pauses for about 200 us before transmitting the 5th and 6th packets. Next the code sends 0x4001 six times to clear the error registers in the AS5048As, before resuming sending 0xFFFF, which is the read angle command.

It took a while, but I’m happy to report that I did eventually sort out the comms problems with all those extra channels to play with. (Those AS5048A encoders seem very fussy when it comes to output loading, and very susceptible to noise on the clock, which is a bit annoying since they are likely to be used in a noisy environment, e.g. with stepper motors as in my case.)

I did however notice a few issues with the Siglent along the way, mainly to do with SPI triggering and decoding, which didn’t always seem consistent. After changing something, say the SPI trigger conditions or channel mapping, I would sometimes have to play around with thresholds or cycle the SPI settings to get it working correctly. Sometimes the decoding was clearly incorrect (not just the last bit issue mentioned in the bug thread), and sometimes it would trigger on the incorrectly decoded data; other times not. Part of this might have been due to the rats nest of connections to the project or me, however I didn’t have the same issues on my Keysight MSOX3000 series scope when I tried connecting it in parallel with the Siglent (making an even bigger rat’s nest).

Yes it would be nice if the digital channels didn’t have these issues, but we can’t ignore that the Siglent is excellent value for money, even more so with the DIY LA probe.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod