I'm looking for a logic analyzer since I'm looking for saleae clone replacement or an upgrade. (Yes, I'm feeling guilty about it, although I can use sigrok for that matter)
I was searching info and found Open bench Logic Sniffer (OLS) is what I'm looking for but with known RLE bug with sigrok which is kinda a bummer as I'm getting familiar with sigrok. Somehow I stumbled upon an article (I can't put any url link as I'm a new user, you can search with an article from sigrok website with the title "A newer, better Openbench Logic Sniffer") stating that this project is abandoned so new features won't be added. Is it true? It's not like I'm going to buy the pipistrello as unfortunately I don't have that much of a budget. I'm looking for more info before doing a purchase.
Thanks before.[/quote]
I don't know as I'd call it abandoned. Maybe "mature" or "stable" would be a better description. You can still purchase it from Seed Studio. The client software is occasionally updated.
I'm not sure what the "newer better Openbench Logic Sniffer" refers to. There was someone that used the core OBLS and added external dram storage. Even got the client program modified to use some high speed transfer mode. As I recall, it was based on Pipistrello. Bit pricey, but may be worth it if you need the trace length.
The Tx/Rx pins if I remember correctly are only there to provide a USB to serial convertor function. That is, your computer opens the virtual comm port via USB and the PIC dutifully relays all communications to/from the Tx/Rx pair. Also, it only does this, after the mode has been switched appropriately. In no way, shape or form, will it still perform IR functions when in that mode. For all I know, the USB to serial capability isn't even in the current FW anymore.
All that said, considering all of the difficulties that folks have with drivers and what not, having the option to use the Rx/Tx pair as the normal I/O for the IRToy, would be a great feature. If it were my design, I never would've gone with USB to begin with, just stuck with standard old rs232.
[quote author="Synper311"]Thank you for the quick reply Qwlciguk. As I'm sure you can see from the above question, my knowledge doesn't run terribly deep on this unit. I try to follow directions where given to ensure that I don't prevent myself from getting the device working properly. Now that I know it doesn't matter, I'll simply stop passing that argument to the program.
Thanks for saving me a few extra keystrokes :)
Do you have any advice/help for me regarding cross-compiling the Play/Record application for ARM?[/quote]
I don't have any experience compiling stuff for ARM, but I would recommend that you pursue LIRC or something similar for the ARM platform, as the record/play program is not really intended for more than demo purposes. It just isn't robust enough for an "always on" environment. If you just want to do interactive capture/record playback, I would recommend IR Scrutinizer which I'm pretty sure runs JAVA. So in theory, it could run under RPi.
Given that the IRToy is simply emulating a serial port via USB and no communication is happening via RS232, the baud rate is merely a placebo. That is, it has zero effect on operation. As I recall, the CDC driver does not even do anything with the caller's requested baud rate. It is ignored.
Logic Pirate: Low speed (40MHz max?) Low channel count (4 or 8?) Stupid name that prevents corporate purchase by many companies Cheaper 256K deep buffer
Logic Sniffer: Not much buffer, but somewhat mitigated by RLE capture mode So-so name that is corporate purchasable after some begging High speed (200MHz max) High channel count (32) Complex trigger capability
[quote author="webshed"]Many thanks - I've had a look at some of the RLE documentation, I see that I may well be able to capture the whole transaction. I'll have some time to try this weekend.
I'm glad to know the hardware isn't abandoned, I understand that larger capture depth would have made it much more expensive.
David[/quote]
One thing that can be hard to grasp about the OLS RLE implementation, is that there is a very non-obvious tradeoff between channels captured and idle time storage. It goes something like this; if you configure for 1 MHz basic sample rate and 8 channels (8,16,24,32 are the only choices), if there were no transitions on those 8 lines, a sample is taken every 128 us even with no change. This is because there are only 7 bits of timestamp available. That is, whenever the OLS sees a transition on a line, it records the timestamp of when it happened. At a 1 MHz sample rate, the timestamp timer increments every 1 us and there is only 7 bits available for the timer. The 8th bit of sample memory is used as the timestamp timer rollover indication. So, with a total of 24KB of memory available, OLS would use 1 byte per 128 us and memory would be completely used up in just 3 seconds total, even with no changes actually recorded. Of course, if there are transitions that get recorded, all of the sample memory will be used up even faster.
If you move to 16 channel capture, it would seem to follow that you'd get even less total captured time, but it may not be the case for sparse data captures. In 16 channel mode, again 1 channel is used as the rollover bit, but this now leaves 15 bits for the timestamp timer. So, at the same exact 1 MHz sample rate, you only burn 16 bits of sample memory every 32768 us. On the other hand, we now have only 12K of samples that can be captured. Still for a completely idle capture, 12K samples would be consumed after some 393 seconds. Again, if there are actual transitions recorded, the total capture time is less.
Similar for 32 channel mode. Samples captured drops in half, but the timer is now 31 bits and can capture very long periods of idle time at the expense of actual transitions captured.
The tradeoff is between idle time capture and actual transtions captured. You need to experiment a bit to get a feel for it. If you're not getting enough capture time and there are long idle times, then increasing the number of channels in the capture, will help. If you're not getting enough capture time and transitions are fairly dense, decreasing channels captured will help extend the capture time.
[quote author="fisarmio"]Thank you Qwlciguk for your reply.
So, considering that OLS can sample @200 mhz, I should analyze all 32 lines. To obtain the RAW data I need to write a sort of plugin that allow me to reconstruct data from sdram protocol I sniffed? Or is there some software that can handle it compatible with OLS?
I didn't know OLS has a buffer of just 24k . So that means I can sniff just 24K of signals? Can't I just empty the buffer and restart the sniffing? (Maybe not due to high velocity right?)
Regarding professional LA, this one is perfect, but it costs around 100k :) keysight U4154A (replace all capitalized C with / ) it has also a module that handle up to DDR4 sample rate.[/quote]
You can connect all 32 lines and it will use up all the available inputs on the OLS. Then you need to connect either the dram clock or perhaps the DQS strobe line to use as the sample clock for the OLS. Then you will need to figure out what are writes to dram vs reads from dram, but there are no more inputs on the OLS after you use all 32 for data. Trying to use a free-running 200 MHz sample rate, isn't going to work very well. It won't get much data captured, less than 8K 32 bit dwords and it will require a lot of manual analysis. If you use DQS strobe as the OLS clock, it will only capture actual data and not idle time. The OLS client software will display the data nicely for you in that case.
You would need to keep all input wires as short as possible. I'd recommend nothing over 5 cm.
The keysight U4154A commercial logic analyzer would work for what you're trying to do.
From having done this sort of thing before, I can say that it's very difficult using a logic analyzer like OLS.
I was wondering if OLS is able to sniff SDRAM protocol. I have a board with an ARM CPU connected to a 16 mb sdram chip 143 mhz (hynix HY57V283220T). What I just need is to sniff the bus in order to dump what CPU read/ write. In this way I could access directly to code loaded from flash (it's encrypted there).
Someone know if OLS can accomplish these velocities?
If not, what kind of logic analyzer I have to see?
regards[/quote]
It is doubtful that you could do that with OLS.
1. The dram referred to, appears to be a x32 part. So, you'd need all 32 OLS lines just to capture the data alone. There would be none left for RAS/CAS/WE, etc, much less address lines.
2. The 143 MHz is the part spec, but assuming that the application is really using a clock near that speed, let's say 125 MHz for example, luckily this is SDR and not DDR, you would still need a good bit more than the 200 MHz max sample rate of the OLS to capture any semblance of usable data. Perhaps you could use the external clocking option and sample on the opposite edge of the clock? Still, with just 24KB of sample memory, you wouldn't get much data captured before the OLS buffer fills.
As for what sort of logic analyzer can do what you want to do, you need something with upwards of 250 MHz sample rate and as much buffer storage as data you intend to capture. Plenty of professional solutions in the $100K and up range. Even used models command nearly new prices.
I was reading over on the sigrok website that the OLS is effectively an abandoned project. Is this the case? If not, is anyone working on adding additional capture RAM to the board or enabling continuous capture? Is there anything I could help with along these lines?
I'm trying to capture a rather long i2c transaction that will just not fit in the OLS capture buffer.
Regards, David[/quote]
Abandoned probably isn't the right word for it. Perhaps "mature" is more accurate. At this point, the OLS does what the developers set out to make it do. There isn't any current work to change the hardware design, though there was a user that tweaked the core to add simple edge trigger capability, not so long ago. The main client program to configure the OLS and display captured traces, is stable at this point. It does what it does acceptably. There are several alternative client programs around with various capabilities.
As for modifications to add more capture depth, I'm sure that the goal of the original development, was to keep the price in reach of the most people. As such, I don't quibble with the choice to use only the internal ram, as limited as it may be. The core has been modified and put onto a Spartan6 along with 64MB of dram. See:
The price is triple what the OLS goes for and availability can be spotty.
Depending on how dense the i2C traffic you're trying to capture, you may find that the RLE mode of the OLS can actually cover a really long period of time with adequate sample rate.
[quote author="oliver"]A quick question about RLE mode.
I read that RLE mode works more effectivly when enabeling all groups (-1 bit, 31bits total) as that strangly is more effective/efficient, with a note of ensuring unused bits are nicely grounded. While I haven't looked at the FPGA code, this seems strange to me. Why can't the FPGA figure out that when using only 1 group, the rest of the bits should be interpreted as 0. Its the same as grounding the unwanted bits, sure, but technically much less work (with the default stock OLS that can be quite tricky, no headers pins 16-31, odd jumpers required for pins 8-15 etc). Also the user experience would make more sense. Use 1 group, yielding more sample memory, enable RLE, doing things more efficiently. That internally the FPGA uses all 32 bits and forces the upper 24 bit to 0 shouldn't matter to the user.
Does this make sense at all?[/quote]
I agree that it is a bit counter-intuitive. There is a side-effect to selecting 32 or 16 channels vs 8 when using RLE and that is that you get proportionally less "event" storage. An "event" is either a change in the state of one or more of the channels being captured, or a timer rollover. In 8 bit mode, timer rollover happens much more often, since the timer only has 7 bits in that case. You do get the maximum number of events stored, but if the data being traced is sparse, most of the events stored will be timer rollovers.
If you choose 16 channels, you will get half as much event storage, but 256x longer between timer rollover events. So, with sparse data, the fewer timer rollover events, results in more of the available event storage getting used for actual channel transition events and more total time covered in the capture.
In 32 channel mode, the event storage drops in half again, but here we get 65536x more time between timer rollover events. This is great for super-sparse data captures. If you have a serial character being sent once per minute, in 8 or 16 channel mode, 99% or more of the event storage will be used up for timer rollover events. In 32 channel mode, you don't get as much total event storage, but far less is wasted on timer rollover events.
Personally, I find that 16 channel mode works pretty well for what I capture typically, though I do have to think about the tradeoffs.
In my day job, I regularly use a Tektronix TLA7012/7BB4 which has 64M x 135 channels at 800 MHz. I occasionally use what Tek calls "transition" mode which is what we're calling RLE mode. The difference there, is that they have completely separate memory for timestamps and there are no timer rollovers, as the timestamps keep the full calendar time/date. Well, I suppose that it would rollover at some point 1000 years from now or something like that. The point is that given enough money (TLA7012/7BB4 is $180K) you can supply enough memory to make it work without the user needing to understand the dirty details of what is going on behind the scenes. With the OBLS, I don't see how to hide this from the user without causing any issue.
Version 1.1.1 - New export format: IrToy-bin - New importer: IrTrans - Fix bug in Hexcalc when number > 65535. - Splash screen on startup. - Multiple decodes from DecodeIR are no longer "censored" (in all places). - Parametric remote -> Advanced -> "Set misc. parameters" now replaces all old parameters except D, S, F, and T. - Fixed unclear semantic of "count" sends of an IrSignal. - Fixed issue with sending by IrToy.
Version 1.1.0a. - IrToy: fixed several issues. (Only FW version 222 is supported.) - the count for transmit generated is now a saved property. - csv-importer: can now parse hexadecimal numbers starting with 0x.
[quote author="AnalysIR"]Hi I think you need to treat measurement of Modulation frequency separately from demodulated signals with the IR Toy.
Some points of interest: 1. The IRToy returns 2 values for the modulation frequency, which are captured from the first 2 modulation pulses at the start of each signal. For this to be accurate, you need the remote to be up close and personal!. In my experience you are either getting the Modulation frequency or the IR signal, but not both simultaneously. 2. There ia a bug in the current V222 firmware, wherby only the first value returned for modulation frequency is accurate, this is covered elsewhere in this forum, but remains outstanding. 3. If you make a request for modulation frequency after a signal where the remote was not up close, you will get a bad out of range result. 4. There is always a lag with IR Receivers and the resulting timings are always distorted, due to things like AGC within the device. You can get some insight in our blog post "Infrared Receivers – signal lag and distortion": http://http://www.analysir.com/blog/2014/03/27/infrared-receivers-signal-lag/ 5. IR Receivers are not designed for use at ranges of a few cms & from what I have observed the internal circuity can be overloaded when this happens and may (sometimes) operate outside of spec.
IR decoders must make allowances for variations in timings. Some use up to +/- 200 uSecs others use +/- 25% of pulse lengths.
I am not sure this addresses your points, but hopefully is of some interest nonetheless.[/quote]
For capturing precise timing, using just the raw IR sensor seems like the way to go, even if it does require the remote be quite close. I've never seen the raw sensor fail to give correct timing in such case. The demod on the other hand starts out with a handicap and it gets worse from there.
Many people know that the IR Toy can actually operate in IR Widget mode that uses the raw IR sensor exclusively. The demod sensor use was abandoned long ago by the Widget developers, due to the inaccuracies. Sadly, the built-in Widget mode of the IR Toy is badly broken. There is a stand-alone "Widget only" FW for the IR Toy and it works beautifully, though the "Widget only FW" gives up the capability to transmit IR. Ideally, if someone with an understanding of the IR Toy FW, fixes the built-in Widget mode, we could have the best of both worlds; pulse accurate timing on captures and retain the ability to transmit IR.
In native IR Toy sampling mode, I wouldn't go so far as to say that you need 2 captures, one to get the frequency and another to get the timing. I haven't had much trouble finding a happy medium on distance that allows both to work reasonably well.... once you know not to get too close. It hadn't occurred to me that the demod might malfunction in such a peculiar way, if encountering a really strong IR source. I think I rather expected the "on" times to get blown out, rather than shrink.
[quote author="Simpkins"]It would seem at the same time you found this I too was running the same experiments and came up with exactly the same conclusions (almost!). The demod receiver does not like to be saturated and there is a happy medium for both IR chips to receive a nice signal to. However there was a slight difference in that in my tests I found the distance for my NEC IR remote to be more in the range of 6-9cm not inches. This distance probably changes a lot depending on the power of the IR LED. This is something that people can experiment with now that they know.
Nice work with all the images and details. Where's the forums thumbs-up thingy?[/quote]
I think it absolutely depends on the transmitting power of the remote being recorded. I tried 5 different remotes and only the one I tend use all the time, has so much power that it overwhelms the demod at close range. Most remotes, I could put directly against the demod without any issue, but this OneForAll URC-8910 apparently puts out a lot more power than the others.
Given any random remote, it's hard to tell if there is a problem or not (without a scope or logic analyzer), unless you playback the captured IR record and it doesn't operate the device. In such case, adjusting the distance is in order.
