USB Logic-Analyzer (sorry, long) - Page 1
Forum section: electronics / testgear

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 25, 2011, 05:48:47 pm
content: While this has been discussed several times before I guess, I'd really appreciate some input on my thoughts regarding selecting an USB logic analyzer. E.g. if my assumptions are valid or if I overlooked something.For the start, let's say I narrowed down the selection to the following two devicesZeroplus LAP-C16128 (249€) + Trigger Module (~50€) (including VAT, but not shipping)Intronix LogicScope (about 370€ including VAT and shipping)I looked at at least a dozen of other USB LAs, but they all had severe limitations, crappy software or both. E.g. as far as I can tell the above two LAs are the only ones below 500€ that are able to trigger on pulse width. This excludes e.g. the devices from Saleae, USBee, Deditec, Hantek, RockyLogic and the Open Logic Sniffer. Well, I'm not so sure about the Logic Sniffer, but it appears to be a bit unstable and more like a thing to play around with than to work with. Please correct me if I'm wrong.LogicScopeThe trigger possibilities are pretty good: two levels and the possibility to trigger on the width of a level or pattern.The memory per channel is very limited (2k Points), but the well designed compression (only changes are stored) still gives good memory depths (the better the less edges).The most important protocols (like SPI, UART and CAN) are built in, but there is no way of adding additional protocols.ZeroplusTrigger possibilities are very simple. One level (channel edge, pattern) only. Triggering on width is only possible for one channel and only with the external Trigger Module which essentially creates an edge at another channel if the width/range condition for the connected channel is met. It's not clear to me if this makes it possible to combine the output of the trigger module with another channel as a pattern trigger. But it doesn't look like it.There is an option for a protocol based trigger, but I assume this is not possible in real time (and costs another 46€).The memory depth is ok (128k points per channel), unfortunately the compression algorithm is pretty basic, so even if the signal doesn't change at all, one sample is needed after 256 sample points.The big advantage compared to all other USB LAs is the number of protocols. Apart from the fact that it already comes with all the most popular protocols, there's currently a special offer so you can select 30 additional protocols for free. As a result, the Zeroplus has nearly all the protocols I'll probably ever need. Which makes me a little enthusiastic to say the least.While the LogicScope is the clear winner regarding trigger possibilities and the Zeroplus is the clear winner regarding the protocol analyzers, I'm a bit unsure who's the winner regarding the memory depth. It's clear that the LogicScope will always win for cases where there is very little activity and the ZeroPlus might take the lead if there is a lot of activity.So I picked two use cases which I'm familiar with:1) SENT (Single Edge Nibble Transmission)A typical SENT message consists of a calibrations pulse and 8 nibble pulses (-> 18 edges) and lasts for 1ms.While the SENT clock is usually 3µs, the SENT specification defines a time resolution of 100ns, so let's assume 10MSamples/s.The Zeroplus has 128k Samplepoints: 131072/10000000 -> 13.1072msAssuming a 200:1 compression -> 2.62144s-> 2.62144s/1ms -> 2621 messagesIntronix LogicScope can store 2k samples. I understand it only stores a sample if an edge occurs:-> 2048/18 = 113.78 messages2) SPIA typical SPI communication with an output driver uses 1MBaud in our projects (due to EMC). A typical communication lasts about 60µs and needs about 128 CLK edges. Also the communication is usually started only every 10ms.Let's assume a sampling rates of 10MSamples/s, which means an accuracy of 100ns to e.g. judge the timings between CS and CLK etc.For the Zeroplus, we end up again with 13.1072ms (uncompressed) or 2.62144s (compressed)-> 2.62144s/10ms -> 262 MessagesThe LogicScope is limited again by the number of edges-> 2048/128 = 16 MessagesThis comparison is not completely fair, as obviously, the values for the LogicScope won't change for higher sampling speeds, resulting in better time resolution. Then again, even at 100MHz the ZeroPlus would win both comparisons. Even worse, if there are multiple devices on the SPI bus, the LogicScope would run out of memory much earlier as it had to sample the edges of the other devices as well.This leaves me with the impression that in my typical use case scenarios, the Zeroplus provides better memory depth even at 100MHz, plus it clearly wins as protocol analyzer.On the other hand the LogicScope has by far the better trigger options and will be superior for very short signals over a longer time, but this is simply not my typical use case.Currently I tend to think that the Zeroplus would fit my needs better and essentially there is no other USB LA that offers so many protocols and allows to do a pulse width trigger at the same time.So: any comments and are there other devices <500€ with width triggering that I overlooked?I overlooked the DigiView DV3100 which seems to combine the best of the two worlds (512K samples per channel with clever compression, 8 complex trigger levels with e.g. period triggers):http://www.tech-tools.com/dv_dv3100.htmAs fas as I can tell, it would cost me around 455€ including shipping at VAT, which is a little more than I wanted to spend, but yeah well. Also there are not too many protocols implemented currently, but obviously the upcoming version of the SW will have the possibility to create own plugins via an API.

author: Unknown
author_rank: Unknown
timestamp: September 25, 2011, 06:51:50 pm
content: I believe the Open Logic Sniffer supports most of the triggering capability of a professional HP 16550A logic analyzer, so I would be surprised if it would be unable to trigger on pulse width. See the Dangerous Prototypes forum for more info.'Dumb' USB bulk transfer based logic analyzers like the Saleae do all their triggering in software, so in theory there's no reason why the couldn't support pulse-width triggering, it's just a matter of implementing it in software. I'm not aware of any of them having released the software to do it, bugging them might help.My impressions of the Zeroplus software were that it was horrible in the usability department, lots of tiny icons with no logical organization. Maybe they've improved their software since. They used to charge an arm and a leg for additional protocols (something like $80 for two). Do they allow you to build custom protocol analyzers?The Intronix LogicPort (LogicScope?) is by far the closest to a professional tool, in my opinion. Most users don't have any issues with the memory limitations. Advanced triggers can make up for lack of memory to some degree.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 25, 2011, 07:22:37 pm
content: Quote from: alm on September 25, 2011, 06:51:50 pmMy impression was that the Sniffer is very promising in theory, but in reality it's not really reliable at this point. Also the SW seems to be very weak to say the least.QuoteHm, that's a point. Then again, all triggering done in SW doesn't sound very reliable. And at least for now, none of the simple LAs supports advanced triggers. And hoping that this will change soon is as hoping that Intronix will provide more protocols or that the Open Sniffer will get a great GUI in the next weeks.QuoteWell, neither the Intronix nor the Zeroplus SW is perfect, but I don't see such an advantage for the Intronix SW honestly. Both don't seem to support cutom plugins, but as pointed out before: with >30 (currently) free analyzers, the Zeroplus has more or less everything you'll ever need.QuoteWell, not always. Take the SENT example. There is really nothing you can trigger on in a SENT message apart from message length. Indeed what would be needed to trigger on a special message would be several sequential length triggers (e.g. 6 or 7). No USB LA (apart from maybe the DigiView) can do this. Futhermore, if an advanced serial message is embedded into SENT messages, it needs 18 messages to decode this serial message. This makes 324 edges for one serial message. It's quite obvious that the 2k buffer are quite limiting then.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 25, 2011, 07:35:05 pm
content: Quote from: BoredAtWork on September 25, 2011, 07:21:38 pmI totally agree. That's e.g. why I ordered an Agilent arbitrary waveform generator in my company instead of an USB Lecroy Waveform generator. Even if the Agilent Windows SW id not usable in ten years, it will be still possible to upload waveforms from the USB stick.QuoteI'm fully aware of this. Then again, regarding logic analyzers, there is not much of an alternative. The usual desktop LA is terribly loud and costs around 10k€ while the typical things you need to do can be done with a silent few hundred bucks USB LA. Anyway, also Intronix seems to be a very small company and regarding the state and last update of their website, I wouldn't be surprised if they wouldn't exist any more in two years or so. This is probably also true for any other of the <500€ LA companies. With this in mind, I'd had to get a LeCroy in the >1k€ range, but this is for my private stuff and I don't want to invest so much money right now.

author: seattle
author_rank: Contributor
timestamp: September 25, 2011, 08:03:40 pm
content: I have a logicport. The software is very good and rock solid. Rock solid as in, I leave it connected always, weeks on end, through hibernate and running, and at any time I can switch to that window and the logic analyzer is there waiting to do what I need.The software copes readily with large data sets (meaning the compression works), and the protocol decoding works fine too.However, as you note, if you are looking at something alongside a fast signal (like a clock), you will very quickly run up against the small memory. The 500 Msps speed is awesome too.PS. I agreed with BoredAtWork about USB a decade ago, but frankly for the last 5 years I've found USB on Windows to be (finally) plug and play and very reliable. Especially on Vista and later with silent driver installs. If a vendor does their job, it just works and continues to work. And I'm of the opposite opinion on desktop versus USB scopes. Desktop scopes feel like you are looking at the world through a pin hole. I'd rather spend an hour updating drivers every 4 years than have to stare at a scope screen with less pixels than my cellphone.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 25, 2011, 08:59:34 pm
content: Hm, I played around with the DigiView DV3100 Software a little and it seems that the complex trigger system is a little more limited than it seemed. While you can define a minimum duration for patterns and "stable" conditions, you can't seem to define a maximum period. Therefore you can't define ranges as well.Then again, also the LogicScope is more limited that the stone age HP logic analyzer I had in the company 12 years ago (and even then it was old). E.g. you can't define something simple as two falling edges within a certain time range, but only on a certain pattern that is stable for a given time range. So e.g. you can't trigger on a pulse that has only a defined falling edge, but heavy jitter on the rising edge. Not to speak of stuff like trigger on edge B only if it happens within a certain time range after edge A.You would think that with afforable FPGA being available for several years now it should be possible to implement at least a two level trigger system with the most common trigger conditions.So maybe I should bury the idea of getting an USB LA with a usable trigger system and focus on the protocol analyzer.Ok, looked at the Open Logic Sniffer again. Looks as if the newest FPGA code would indeed support interesting trigger features which try to imitate the trigger system of the good old HP16500/HP16550 LAs. Unfortunately, the GUI/client obviously wasn't updated for several months and so this advanced trigger system is not yet available. And yeah, the GUI is somewhat crappy.Anyway, I kinda like the approach and the HW costs only 45€, so I think I try this first before spending hundreds of € for a commercial LA that doesn't make me happy either.

author: Neganur
author_rank: Unknown
timestamp: September 26, 2011, 03:05:06 pm
content: Regarding the logic snifferQuote from: 0xdeadbeef on September 25, 2011, 08:59:34 pmAre you sure you're using the most recent software version? (0.9.4 from 8. June 2011)from the changelog:Code:Trigger Terms:10 more 32-bit masked value comparisons.2 range checks.2 edge checks (rising, falling, both, neither).2 36-bit timers (10ns to 600sec range).States:16 state FSMEach state can use any combination (AND/NAND/OR/NOR/XOR/NXOR) of thetrigger terms for detecting a "hit" condition, and "else" condition, or"capture" condition.Each state also has a 20-bit hit count that must be reached before a full "hit"occurs. Hit actions include setting trigger(run), starting/stopping timers,and advancing to the next state.The "else" condition lets you punt to another state. If neither hit or elseconditions match, then the state spins.The "capture" condition lets you control what gets sampled into RAM,until you flip the trigger.Grab the 16550a user's guide (Google for "HP 16550a" - it's the first hit).I think you'll be surprised how much got squeezed in.The advanced trigger & basic trigger can be used in parallel, though youlose the advanced trigger conditional "capture". Arming basic triggersimmediately starts filling the RAM.Also, I don't understand what you mean by "the software seems to be very weak to say the least" and "but it appears to be a bit unstable". Can you be more specific?

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 26, 2011, 06:23:31 pm
content: Quote from: Neganur on September 26, 2011, 03:05:06 pmYep. It's nearly 4 months old though.The thing is that I stumbled over this site here which seems to show the trigger conditions I know (and love) from our old school HP LAs in the company.http://www.mygizmos.org/ols/fpga.htmlI somewhat expected that the GUI would be changed to reflect this trigger possibilities directly.Yet I could also live with another presentation as long as the possibilities are there:http://gadgetfactory.net/logicsniffer/uploads/Playground/OLS%20Advanced%20Trigger.pdfThen again, when I look at the current "complex" trigger system, I can see only 4 levels with 32bit mask/value bitfields and a delay time. For me the current system looks as if you can select a pattern that's present for a certain period and then either connect this serially or in parallel (OR) to another pattern present for a certain period. Which is better than the trigger system of most of the lowcost USB LAs, but still not nearly as good as that of an 20 years old HP LA.Maybe I don't get it, but I don't figure how this should be the same as the advanced trigger system depicted above. As far as I can tell, there are no (selectable) logical operators, no way to invert a condition, no ranges etc. To me this looks like a way simplified trigger model while the new advanced system exists as prototype, but is not really available yet in the official release. Also, this complex trigger menu was obviously introduced in March 2007, while the advanced trigger was first implemented as prototype in January 2011. So quite obviously, they are not the same.Anyway, in the mean time I ordered an OLS just because I couldn't resist a 45€ toy to play around with. Even with the current trigger system it would be a bargain if it worked reliably.QuoteWell, I couldn't really test the software due to the lack of a demo mode, but what I saw didn't overwhelm me.About the stability: I quickly browsed through dozens of sites yesterday and I can't really recall where I read it, but in some semi-official OLS site I read a comment about it freezing and the need to replug it. I also read several comments about the RLE not working and being removed and then later re-enabled in later releases. So my impression wasn't really that the base functionality is working reliably since several months.

author: Unknown
author_rank: Unknown
timestamp: September 26, 2011, 06:32:26 pm
content: I believe RLE was fixed around the time the advanced triggering stuff came along. My impression isn't that it's perfect rock-solid production software, but neither is all of the software for commercial logic analyzers.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 27, 2011, 12:44:27 am
content: It's a bit disappointing that the "Demon Core" 3.07 with the advanced trigger is available since begin of March and still doesn't seem to be a client that actually makes use of the advanced trigger possibilities.

author: vk6zgo
author_rank: Super Contributor
timestamp: September 27, 2011, 02:29:41 pm
content: Quote from: seattle on September 25, 2011, 08:03:40 pmUSB scopes may offer nice big displays,but their specifications are usually poorer than a desktop unit.Of course,if a lower spec instrument does the job OK,the big display is a plus.VK6ZGO

author: seattle
author_rank: Contributor
timestamp: September 27, 2011, 03:52:52 pm
content: Quote from: vk6zgo on September 27, 2011, 02:29:41 pmI offer 3 observations:1) 95% of the scope shots posted on this website could have been made on a USB scope2) My desktop monitor has 21 times more pixels than my Rigol DS1102E3) After countless hours spent, I still cannot get screen caps from my Rigol to my PC.Now, on #3 maybe I'm just thick. I'll grant that. I have both USB and desktop scopes. They serve different purposes. The Rigol gets fired up only to look at fast clocks (SDRAM and Xilinx)

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 27, 2011, 07:31:28 pm
content: To get back on the topic: I got the OLS today and died a thousands deaths before I was able to finally reprogram the newest PIC and FPGA Software. For some reason the scripts are fixed to (virtual) COM6, while my OLS installed a virtual COM driver at COM9, but even when patching the scripts to COM9, they just didn't work. I tricked the COM to 6, replugged the OLS a dozen times and finally I was able to upgrade the firmware(s). On the way I tried three different ways of upgrading and two always failed completely, only the "first install" script worked now and then. Well, apart from some error messages because it tried to call (Unix) shell commands which simply don't exist in Windows.Anyway, finally I could test the client and it's more or less as buggy and simple as I imagined. Zooming out to max level doesn't really work and often leaves garbage on the screen, you can't define buses and generally everything is very, very basic.Apart from that, capturing at 200MHz doesn't seem to work correctly and the RLE only works as expected if you enable 16 channels. E.g. at 10MHz you can sample 16 channels (no edges at all) for about 20s but only for about 156ms with 8 channels. Although you have twice the buffer size with 8 channels. As a side note, the RLE seems to be more efficient than that of ZeroPlus, but not nearly as efficient as that of LogicScope. For 8 channels the compression factor for completely empty channels is only around 64:1 (much worse than ZeroPlus), but for 16 channels it's around 16384:1. Well, I hope the behavior for 16 channels is the "normal" one and that for 8 channels is erratic. I's have to check with real signals.Well, I was not in the mood to set up a real test, but despite of all the limitations, I think I can live with this. At least it works and while neither the RLE nor the buffer size is really great, it seems to be a very good compromise between the ZeroPlus (lousy compression, but larger buffer) and the LogicScope (much better RLE, but very small buffer). And of course you can't beat the price. Hell, if they finally implement a GUI for the advanced triggers and fix a few issues here and there the OLS could be really great I guess.In the meantime, I found several other issues. If you play around with the trigger settings either the OLS or the client or maybe also the virtual COM port driver hangs up and you get connection errors. Also the client crashed and I needed to kill several dead JAVAW processes. Only by replugging the OLS several times and performing magical dances, I could get it to capture again. Well, well, lots of room for improvement.As a side note: the inputs are floating (no weak pulldown whatsoever) and quite sensible to picking up noise. When I connected some simple probe cables, I got all kind of phantom signals on these channels.

author: FreeThinker
author_rank: Frequent Contributor
timestamp: September 27, 2011, 08:01:21 pm
content: After a bit of research I found a comment one one forum that the Saleae LA started life as open source and was later commercialised, Can any one confirm this? I find it to be a bit rich that Saleae's website should condemn the cloners if this is true! Can't find any other reference to this on Saleaes or any other site but it rang a bell with me for some reason, anyone know any more?

author: seattle
author_rank: Contributor
timestamp: September 28, 2011, 12:10:24 am
content: Quote from: BoredAtWork on September 27, 2011, 06:16:29 pmMost don't drive around town in a Ferrari, either. That doesn't mean the Ferrari is a crappy car...It has nothing to do with technical limitations...Like I said, I have both. I need to see lots of digital and analog at the same time. A standalone scope is pretty horrid for that....

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 28, 2011, 05:36:56 pm
content: Ok, I played around with my OLS to watch SPI communications. It actually worked pretty well.Sampled at 10MHzSPI analysis:There really is an issue with the RLE compression for 8ch setups. I tried the above capture for different sampling and channel settings which shows that the higher the frequency, the worse the RLE compression for 8ch gets. E.g. at 100MHz the 16ch setup is able to capture nearly three times the 8ch buffer though only half of the memory is available:10MHz: 8ch: 59ms, 16ch: 40.634ms50MHz: 8ch: 26.085ms, 16ch: 34.524ms100MHz: 8ch: 13.367ms, 16ch: 36.506msCaptured data for you to play around with:http://home.arcor.de/0xdeadbeef/SPI.ols

author: Hypernova
author_rank: Unknown
timestamp: September 29, 2011, 03:26:48 pm
content: I got both the OLS and a Saleae clone and I use both a lot, OLS with the buffer add-on get's you 31ch (I also use RLE) at an unbeatable price, while Saleae excels at long records. Hence I use the OLS for timing analysis with lots of signals and Saleae for bus analysis. IMO it's a good idea to get both for waaay less the price of a single full featured LA.But yeah the noise issue on the OLS input can be annoying, I keep a bread board with headers on the GND rail and plug any unused channels into that to tie it down.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: September 30, 2011, 12:57:07 am
content: Honestly it looks like the OLS should suffice for my private tinkering and could even help me in the job in certain scenarios.If the 8ch RLE problem was resolved, the stability was increased a bit and the GUI was improved a little (mainly implementing the advanced trigger setup, a possibility to define buses and a better zoom handling), I'd be very satisfied from a functional point of view. There were very few cases in the past where I wanted to watch signals over a very long period and then honestly I wouldn't trust an LA based only on USB transfers.Then again, the lack of a proper case, the very cheap probe cables, the floating inputs and the low voltage tolerance (-0.5 to +5V) reduce the usability in an industrial environment quite a bit. Of course you could build/buy a case, buy better probes and either buy or built a more robust input stage, but this would increase the price dramatically or cost a lot of time. Also the number of available protocol decoders is underwhelming. The most common serial protocols are there, but for the job, it would be nice to have e.g. CAN and LIN and I don't feel the urge to implement my own plugin.So I'm still toying with the idea of buying a cheaper ZeroPlus (e.g. the one with 64k for around 170€) just as a protocol decoder. It comes with nearly 40 protocol decoders, somewhat solid case and probes and can survive up to +/- 30V on the inputs. Besides I figure that the 32k, 64k and 128k version are still the same HW and the memory limitation is only done in the client SW. So by patching the USB DLL (or the EEPROM) you can use the 64k as 128k version. The bad thing is that you use the 30 free protocol plugins, but then again the 128k version has the most needed decoders and you can still use the unpatched SW to use the other protocols. At least that's how it worked until recently.

author: JuKu
author_rank: Frequent Contributor
timestamp: October 01, 2011, 07:32:23 am
content: Zeroplus on order, Review coming later. :-)

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 01, 2011, 02:46:46 pm
content: Did you order the C16032? If so, could you check how much RAM it really has? At least until recently, the 32, 64 and 128 had all the same hardware (including the CY7C1347G-250AXC 4.5MBit RAM), so you could "upgrade" the C16032 to a C16128. In the 1st HW sample you could even update to the 32ch devices by populating the missing parts but this doesn't work any more.For details, look here:http://hackaday.com/2010/03/30/zeroplus-logic-cube-modification/http://lostscrews.com/viewtopic.php?f=16&t=84Anyway, if this is still possible to upgrade to the 128k unit, it would be really interesting to know if it's possible to register the 30 free protocols for the "upgraded" device. I understand that the registration key is based on the serial number of the device and the ID of the device. So if you register the protocols for the C16032 you bought, they won't work if you use it as C16128. The questions is though if it's possible to register them for the C16128 or if this doesn't work because the serial number is bound to the device type (via encoding or database).Regarding the Open Logic Sniffer I learned yesterday that the PIC firmware was never updated. The reason was that the hardware revision v1.04 I got, has a new Winbond flash polulated that the default upgrade tools don't support. I was able to set the PIC to boot mode manually and thus upgraded to the newest PIC firmware.This kinda explains my problems upgrading as most of the tools tried to update the PIC first and only then the FPGA. Only the one script that didn't care about the failed PIC reprogramming continued to the FPGA reprogramming.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 06, 2011, 06:55:24 pm
content: For the fun of it, I also ordered a Zeroplus C16032. The good news is that there's the 4.5MBit CY7C1347G in it, so from the HW point of view, this is a C16128. Also patching the EEPPROM still works, so you can use 128K samples.The even better news is that cross-registering plugins seems to work perfectly. I was so bold to register my C16032 as C32128 and activated one of my 30 free plugins (FlexRay) with the generated serial in fake C32128 mode. And it workedHonestly I wanted to register it as C16128, but somehow selected the C32128 instead. I hope this is not an issue regarding the RAM as long as I don't have the additional 32channel selected.Anyway, this currently looks as I got a full featured C16128 with all 30 free protocols (+ the one which are already free for the C16128) for 90€. Have to do some testing with real signals though.

author: duke3k
author_rank: Newbie
timestamp: October 07, 2011, 07:50:51 pm
content: Shahriar @http://thesignalpath.comdid a really good video product review & teardown of the Salea, Salea 16 and the USBee SX.Review:http://thesignalpath.com/blogs/2011/05/31/saleae-logic-and-logic16-product-review/TearDown:http://thesignalpath.com/blogs/2011/05/31/saleae-logic-and-logic16-product-teardown/The software on the Salea is excellent - I've got the Salea 16 and have been happy with it so far for ....although to be fair have not used it much. The build quality on it is outstanding.DukeEDIT: PS- the software platforms that the Salea supports may be a plus for some people - it is cross platform running on: all windows 32bit & 64bit platforms, Mac OS X, Ubuntu 32 & 64 bit versions. The team is very active on their Software platform- here is the change logs for the Saleae Software from the last several revs:Version 1.1.13* Fixed an issue where new Logics and Logic16s were not getting assigned ids properly -- which caused a number of issues and crashes for users using more than one device. This would happen if you purchased and used 2 or more new devices in the last few months on the same machine. If you're having an issue and think this this might be it, deleting your setting file could fix it. Here are the locations of the settings file:o On Vista/7: C:/Users/YoutUserName/AppData/Roaming/Saleae LLC/Logic/settings.xml (The AppData folder is a hidden folder)o On XP: C:/Documents and Settings/YourUserName/Application Data/Saleae LLC/Logic/settings.xml (The Application Data folder is a hidden folder)o On OSX: /Users/YourUserName/Library/Preferences/Saleaeo On Linux: Inside the folder with the Logic executable, in the Settings folder.* Fixed issue with channel reordering on Logic16. It should never do it now.* Some exciting stuff is in the works, but it's a few months out. We're shooting for a release around the end of the year.Version 1.1.12* Obtained new code signing certificate after the old one expired, and unexpectedly caused older installers to fail. This normally shouldn't happen, but it turns out we forgot to 'timestamp' the driver package which keeps the signature valid even after the associated certificate expires.* Fixed issue with channel reordering on Logic16 on Linux and Mac. It still appears to occasionally happen, but much more rarely now -- we'll get that fixed shortly.* Changed the way analyzers export their data to use far less memory -- this was causing an issue when exporting very large amounts of analyzer results.Version 1.1.11 beta* Adding ability to re-run an analyzer starting at the T1 timing marker. This has been a long requested capability.Version 1.1.10 beta* Added Simple Parallel decoder! We have much more ambitious plans than this, but it may hold you over until then.* Fix for ppc version (i.e. non-Intel) on Mac -- who knew, it's been broken since 1.1.5. I guess not many of us are using ppc Macs.Version 1.1.9* Increased Logic16 USB bandwidth performance by 50%! Old limits were 2 ch @ 100MHz, 4 ch @ 50MHz, 8 ch at 25MHz, and 16 ch at 12.5Mhz. New limits are 3 ch @ 100MHz, 6 ch @ 50MHz, 9 ch @ 32MHz, and 16 ch @ 16MHz.* Added support for CAN remote frames* Organized the Preferences dialog into multiple tabs* Added ability (in Preferences) to edit Logic16 LED behavior* Added option (in Preferences) to collect up to 1 T samples* Finally *really* solved the issue where Linux 64-bit would not accept saved data from other platforms* Fixed issue where software would hang if analyzers were used and the device couldn't keep up* Fixed issue where double-clicking the Options menu would add extraneous items to it* Fixed issue with binary export -- previously had wrong endiness when using data larger than 8-bit* Fixed issue with Logic16 Device SDK memory leak* Fixed issue where Device SDK would not build on OSX* Fixed marque zoom operation -- shift-click-and-drag* Fixed bugs related to hiding channel 0* Fixed bugs related to reordering channels* Fixed bug with analyzers which caused the minimum sample rate to remain after an analyzer was removed* Fixed crash bug caused by exporting analyzers which didn't decode any data* Fixed bug where the pin tab button was visible when it shouldn't be* Fixed crash bug caused by analyzer processing progress displayVersion 1.1.8* Manchester decoding! Standard, differential, bi-phase mark code (FM1), bi-phase space code (FM0). It's pretty flexible and we have high hopes for it.* 9-bit Serial decoding! Also called MP Mode or Multiprocessor mode. Basically a 9th bit specifies if the byte is an address, or data.* Demo mode works with Logic16* Big updates to the User's Guide for Logic16* Fixes for a number of crashes and other issuesVersion 1.1.7 Beta (On the Community Site)* Fixed remaining corruption/crash bug related to long data collections using a trigger (when the trigger did not occur for a long period)* Updated Linux version to reflect window and text system preferences* Added keyboard shortcuts for timing markers (the 1 and 2 keys)* Internal overhaul of how sessions work* Added tabs* Added proper file name display in Window title* Greatly increased performance of loading and saving session files* Session files are now fully cross platform (before we had a pesky issue with Linux 64-bit)* New channel options menu for hiding channels, reordering channels, and resetting settings quickly, etc.* Fixed some minor issues with screenshots* Fixed issues with 1-Wire analyzer* Fixed issue where analyzers would block if they were backlogged and you tried to start a new capture* Fixed issue where I2C would still not decode the very last event recorded (added some capability to the SDK for this)* Full support for Logic16

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 07, 2011, 09:20:02 pm
content: Apart from the fact that we already discussed the Saleae and the other USB bulk data loggers (which I wouldn't call logic analyzers) I don't really see the point in spamming this thread with more than 80 lines of a version history that is of no real interest and could have been linked to anyway.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 27, 2011, 10:22:31 pm
content: hey deadbeef. can you update your experience with the OLS? where did you get it from, any usefull steps to make it work? isnt there any OLS that pre-programmed that i dont have to mess with programming FPGA thing? hope to hear from you.i found this link but i need more detailshttp://www.seeedstudio.com/depot/open-workbench-logic-sniffer-p-612.htmlhttp://www.sump.org/projects/analyzer/if i cant make it, maybe i just buy the saleae logic16 rather than risking not having the ols work correctly.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 28, 2011, 06:44:41 pm
content: Quote from: Mechatrommer on November 27, 2011, 10:22:31 pmI got mine from a German shop, but I guess they just sell them as delivered from seeedstudio.com. Which means that there is a software on it, but not necessarily the newest one. In my case, there was a 2.x software, not the "Demon Core" with advanced trigger possibilities. Then again, there is still no GUI for them, so it doesn't really matter so much.In theory, updating the software should be easy (e.g. starting a batch file). My bad luck was that I got a (not really so) new hardware revision with a different EEPROM which was not supported by the tools. Should e fixed y now though.And yes, 24kByte is really not so much. You probably don't want to use it without compression. Unfortunately the compression is pretty basic. In either 32, 16 or 8bit mode, one channel is lost since this bit is used as RLE token marker. Then a 2nd dword, word or byte is stored with the number of identical patterns. So in 8bit mode, the algorithm needs to store two bytes after 256 identical patterns, in 16bit mode it has to store two words after 65636 identical patterns and in 32bit mode two dwords after 4294967296 identical patterns.So on the one hand, a change onanychannel forces the algorithm to start a new RLE token and on the other hand, the most efficient mode for sporadic signals is the 32bit mode, but it also needs the most space per token.All in all, you end up with using the 16bit mode most of the time, even if you just use 4 channels.There are other drawbacks: the input protection is weak, the inputs are floating and prone to noise and the input threshold is fixed. Also it would be very convenient to have some kind of case (custom case is a lot of work as there are no sensible screw holes).But hey, it's just 50 bucks and in theory, it has the best trigger possibilities of all affordable LAs. And you might actually be able to use them some day in the futureAnyway: all in all, IMHO the ZeroPlus 16032 is better value for the money if you patch it to a 16128 and get the >30 protocols for free. It also has a configurable threshold and a better input protection (not floating either). Last but not least, it has a case.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 28, 2011, 07:30:10 pm
content: Well, there are things like CAN, LIN, FlexRay that I can really use at the job. Also stuff like JTAG and USB that might come handy. Compared to that, the range of protocols available for the OLS is pretty basic.

author: longpole001
author_rank: Contributor
timestamp: April 26, 2012, 10:58:01 am
content: hows is the zeroplus EEprom patched , using windows 7 , i done the USBport.dll patch on a c16032 to make it a c16128 and it works ok , which is fine till the next update and ill have to do it againAlso is these away to add the other 16ch as i believe the internal chip gnds these inputs now ( manufactire date was oct 2011 and adding the extra 16 channel hardware would not be able to be usedCheers

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: April 26, 2012, 04:31:54 pm
content: Patching the EEPROM is no problem under Win7. I can provide you with the tools if you wish.Yet AFAIK updating to 32ch was only possible with an early HW revision.

author: longpole001
author_rank: Contributor
timestamp: April 28, 2012, 01:14:00 pm
content: Hi , yes love to get the tool to update eeprom using win7,as far as the extra 16 channels for the zeroplus , further entries on hackaday site indicate that the current versions are up gradable ( assuming you add the parts) , but the hard bit seems to be that 2 pins referring to the post on hackaday have been cut off at the asic , checking my unit i found 4pins missing , they are not impossible to resolder on but you better be very good and have a very steady hand and not over heat the asic while tring .again from the post it indicated 2 pins cut off access the memory above 32k , which sort of makes me think that although the patch in the software says it can use 128k , it cant really if those pins are not in placesomething that anyone who is doing the "upgrade" would need to confirm

author: free_electron
author_rank: Super Contributor
timestamp: April 28, 2012, 01:23:46 pm
content: Take a look at chronovu. They approach this different from the 'streamers'. They have the acquisition memory on board.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: April 28, 2012, 03:26:00 pm
content: Quote from: longpole001 on April 28, 2012, 01:14:00 pmI uploaded the full package here:http://www.sendspace.com/file/e1zxu0Quote from: longpole001 on April 28, 2012, 01:14:00 pmHonestly, I haven't looked deeper into this. 16ch are good enough for me - usually I use less than 8.Quote from: longpole001 on April 28, 2012, 01:14:00 pmWell, I sure can access the whole RAM without any HW change. It is clearly visible that the measured buffer increases when increasing the "RAM size" parameter from 32k to 128k that it's filled with valid values.Quote from: free_electron on April 28, 2012, 01:23:46 pmNeither the OLS nor the Zeroplus are Streamers. E.g. the Zeroplus has a 4.5MBit Highspeed SRAM.The ChronoVu seems to have cheap DRAM on board (and also a CPLD instad of an FPGA), so I guess that there's catch. On the one hand, obviously they save bandwidth by only supporting 8 channels, but probably there's more to it. Probably there's a small highspeed cache on the CPLD and they rely on the fact that not too many edges occur in a given time, so they have time to transfer the data to the DRAM.Anyway, the HW looks pretty lowend and the GUI is _very_ basic. No comparison to the ZeroPlus GUI.

author: longpole001
author_rank: Contributor
timestamp: April 29, 2012, 05:07:16 am
content: thanks for the file , i have ordered the bits to upgrade the 16 to 32 , note to others the TI 7416ABT245b GGP package in the upgrade is avail from rs componentsbe interesting to see if it works more so with all the protocolscheerssheldon

author: KedasProbe
author_rank: Frequent Contributor
timestamp: July 16, 2012, 07:29:10 pm
content: @longpole001Did you do the update, and does it work as expected?Which serial number did you use to register? (I assume they know which serial number belongs to 32 or 128)

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: July 16, 2012, 09:20:00 pm
content: I even registered my 16032 as 32128 by mistake. I can't use the missing 16ch of course, but registering worked without problems - despite the serial number containing the string "032".

author: mrflibble
author_rank: Super Contributor
timestamp: July 21, 2012, 11:36:58 am
content: Quote from: 0xdeadbeef on November 28, 2011, 06:44:41 pmAs it's been a while since this post, do you still use the 2.x firmware? Or the demon core? Any chance of the newer trigger options being supported in software by now?The reason I ask is currently I use the older firmware version, or rather a slighty hacked version of it. I run it on a nexys2 board, so I took a version where someone already did all the hard work for me.Then mainly did a few quick fixes to get a different pinout, added some pullup constraints on the pins, add some differential inputs, add sychronizer to uart to fix some non-valid assumptions in the original, and added some more BRAM for sampling. Then I used the leftover 2 brams for a small chipscope ILA instance to get me some more triggering options. So basically chain the ILA trigger out with the SUMP original, or run in parallel for debugging. That way I can check if the SUMP trigger thing is doing what it should be doing. So far so good.Now while that's all nice and useful for me, it's not very useful for anyone else. So I thought I'd see if I could do some improvements on the 2.x version triggering. Lucky for my laziness someone else (dogsbody) already did the work in the form of that demon core. And even more luck ... it's in verilog (my vhdl really sucks).So right now I'm looking at changing the demon core so that it'll work on OLS hardware and nexys2 hardware, selectable by synthesis parameter. Whoever thought to put partial opcode decoding right in the uart/spi? O_o Anyways... it would be interesting to know if you and others use the 2.x version or the demon core?QuoteYeah, the RLE in the original SUMP is ... curious. That's another reason I'd like to use that demon core, since it looks better in that regard. Or maybe I'm just biased because I'm more familiar with verilog, dunno.QuoteIndeed. So since it's 2012 by now I was wondering if you or anyone else was using said triggering?

author: amyk
author_rank: Super Contributor
timestamp: July 21, 2012, 12:28:29 pm
content: On a related topic, Cypress has a USB 3.0 equivalent to the old FX2LP in the Saleae and related clones:http://www.cypress.com/?id=3526It would be interesting to see when/if someone makes a logic analyser using it, although it is currently still a bit expensive.

author: mrflibble
author_rank: Super Contributor
timestamp: July 21, 2012, 01:16:32 pm
content: I assume you mean the FX3 for fast usb transfers? At ~ 32 euro at mouser/digikey it's doable, but the bga-121 package might thin the herd of potential "someones" to DIY a prototype. Besides, you'd need a good reason to justify the price increase. More bandwidth is always better and all that, but does the current OLS version even use something approaching usb2 bandwidth?Or maybe you mean it more general. In which case I look forward to trying one of those Kintex-7 + FX3 based analyzers.Well okay, maybe just spartan-6 then.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: July 21, 2012, 02:51:17 pm
content: Quote from: mrflibble on July 21, 2012, 11:36:58 amI updated to Demon Core directly when I got it, What I described was the issue of the update process failing on my HW revision of the OLS and me having to do some trickery to get it done.Quote from: mrflibble on July 21, 2012, 11:36:58 amSo my OLS has the Demon Core on it since several months but the last time I had a look, the OLS GUI still didn't allow to use any of the advanced triggering features and continued to have some annoying bugs and missing features. A least it's still under development, so there's probably a chance that the trigger dialog is reworked some day.Quote from: mrflibble on July 21, 2012, 11:36:58 amFrom what I can tell from a user's perspective, the RLE encoding of the Demon Core is exactly the same as it always was.

author: mrflibble
author_rank: Super Contributor
timestamp: July 21, 2012, 03:07:46 pm
content: Quote from: 0xdeadbeef on July 21, 2012, 02:51:17 pmBummer, I was kind of hoping that I was just blind and missing the magic buttons...

author: Rasz
author_rank: Super Contributor
timestamp: October 15, 2012, 06:02:16 am
content: Quote from: mrflibble on July 21, 2012, 01:16:32 pmI think he meant expanding on USBee/Saleae idea. Using FX3s GPIF II to pump raw 32 bits at 100MHz and let sigrok.org take care of the rest (triggering).We could end up with ~$50 (CYUSB3012-BZXC $28 + pcb and 245 buffers) data logger comparable to >$100 commercial ones.