Author Topic: Which logic analyzer?  (Read 12965 times)

0 Members and 1 Guest are viewing this topic.

Offline Housedad

  • Frequent Contributor
  • **
  • Posts: 514
  • Country: us
Re: Which logic analyzer?
« Reply #25 on: November 13, 2018, 09:53:39 am »
To be totally fair and honest, I should add in the Saleae 16 analog specs too.  (Saleae says to divide by 10)

up to 5 channels  50ms/s  max 5 mhz

over 5 to 16 channels  12.5 ms/s  max  1.25 mhz

12 bits resolution ADC

(The Analog discovery 2 is two oscilloscope channels at 14 bits ADC, and 30mhz)
« Last Edit: November 13, 2018, 10:05:30 am by Housedad »
At least I'm still older than my test equipment
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6662
  • Country: hr
Re: Which logic analyzer?
« Reply #26 on: November 13, 2018, 10:42:49 am »
One thing DD has is quite sophisticated triggering.
Saleae has only edge and pulse width trigger. DD can trigger on protocols among other things.

Also, I used pattern generator many times for testing devices. Very useful.
 

Offline malagas_on_fire

  • Frequent Contributor
  • **
  • Posts: 591
  • Country: pt
  • Kernel Panic
    • Malagas Lair
Re: Which logic analyzer?
« Reply #27 on: November 13, 2018, 12:05:44 pm »
Well this is more of a question than providing a solution.

Does anyone knows about perytech products?
What about this logic analyzer :

https://ebay.us/vulmL2

The listening has a lot of description , FCC and CE compliancy and a compreensive software but i don't see any included acessories, such as probes.

[Edit ]
I was talking rubbish on acessories, sorry:


"Accessories: External box, Logic-Analyzer, LA-Clips, Clip Line, disc, USB 2.0 cable."
« Last Edit: November 13, 2018, 12:07:58 pm by malagas_on_fire »
If one can make knowledge flow than it will go from negative to positve , for real
 

Online ajb

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: us
Re: Which logic analyzer?
« Reply #28 on: November 15, 2018, 07:48:18 pm »
I am told the Rigol will only decode what is on the screen. I suspect that makes it of little use with long data comms and/or for triggering on a specific message.

That is true!  The thing is, I just want to see a single frame.  I am interested in the state of the clock with CS* goes low, the subsequent data transitions relative to the clock and the fact that all the data has shifted before CS* goes high.  I don't need to decode "War and Peace", just a single short frame to verify timing.  Everything else can be done with printf().
Yeah, but the Rigol decoding is so fucking bad that it's hard to use even on a single frame, especially if that frame is 16+ bits. 

If you're doing only 8-bit CS-framed SPI transactions, it's okay, but anything more than that is just awful.  What makes it even worse is that if a frame is partially offscreen, it doesn't just fail to decode that section, it decodes it incorrectly.  And if that wasn't bad enough, it can fuck up the entire rest of the frame!  It will even fuck up multi-byte UART messages if the first start bit is off screen.  If you aren't zoomed in enough, some of the bit decoding becomes marginal and it will just sit there and flip bits randomly on repeated captures.  It's so bad that it's borderline harmful, because there are so many conditions that can cause it to display misleading or outright wrong decoding.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf