4. Maybe the irscope software can do that. Im not familiar with it. Jtr made a firmware to make the irtoy compatible with it. It is floating around but rather outdated.[/quote]
Yes indeed, IRScope can capture and auto-analyze IR cmds, decode them into OBC, protocol, etc. IRScope was originally designed to work with a device known as "widget", but that is just some FW running on a PIC connected to a USB to Serial adapter. The widget sells for something like $30, while the IRToy is a bit cheaper and if it can run FW that emulates the widget, then all the better.
All that said, IRScope will be quite disappointing to anyone looking for record/play functionality of IR cmds. Capture/analyze is what it does and it is up to the user to find a way to use the analysis results. The original intended path was to use the results to create an "upgrade" file for a JP1 type remote. IRScope can export to pronto hex format and a few others, but not LIRC.
[quote author="RichF"][quote author="ian"]I think the problem is that you cannot send actual byte values from hyperterminal, only text - there is a huge difference. In that example I used Hercules which supports HEX input. [/quote] According to the manual:
Another useful HyperTerminal feature is the ability to send out any of the 256 possible RS-232 (ASCII) characters by using the numeric keypad. Make sure the "Num Lock" key is pressed. To do this, hold down the ALT key and enter the desired numbers. For instance, hold down the ALT key and enter the 1, 2, or 3 numbers needed (i.e.: 0 to 255), and then release the ALT key to send the single ASCII character.
Note: When dealing with Hex code the procedure varies. For example Hex 80 can't be sent by simply entering 80 on the numeric keyboard. If you enter 80 (with ALT) on the keypad, you'll send a "P" (which is Hex 50). Hex 80 is actually Decimal 128, and 128 should have been entered.
Numerical characters generated with the ALT key need to be specified in decimal values 0 through 255. For these complex strings, it would be a good idea to generate your keyboard actions on paper before typing them. Also keep in mind many devices will timeout and throw away part of your command string if you take too long to enter a command.[/quote]
Interesting idea. I had never thought of that, though I was aware of the alt-xyz keyboard functionality for some 30 years now. It does work, but I wasn't able to get alt-000 to send anything. Any other alt-xyz combo seems to work. Well I didn't try every possible xyz value. I stopped once I had marched into the standard printable ascii chars (>0x20).
[quote author="ian"]I think the problem is that you cannot send actual byte values from hyperterminal, only text - there is a huge difference. In that example I used Hercules which supports HEX input.[/quote]
Actually, you can send arbitrary byte values from hyperterminal. You have to arrange for them to be on the clipboard and then you can simply press ctrl-v and it does a "paste to host" sending precisely the bytes contained on the clipboard. To get the bytes on the clipboard in the first place may be tricky, depending on the exact bytes needed. Anything can be created in a hex editor and then opened in notepad, then highlight the desired bytes (displayed as ascii) and press ctrl-c to copy to clipboard. You may need some knowledge of ascii control characters since chars like 0x13 will force notepad to display a carriage return. So in that case, you have to extend the highlighted area to include up to the first char of the next line.
Actually, plasma displays are well known as major IR polluters. Something to do with the intensity control PWM ing in the 30-40 KHz range. Narrow band IR receivers can help, but it's not always enough.
There's no need to mess with the VDD on the receiver. To effectively probe high speed signals at a distant of more than a couple of cm, you need to use an isolation resistor at the signal end of the wire and this should be balance with a load resistor at the OLS end. Coming up with the right ratio of isolation resistor vs load resistor involves matching the load capacitance with a capacitor in parallel with the isolation resistor.
I just used an existing pod probe containing 16 shielded from a commercially available HP Agilent 16550 Logic Analyzer. The isolation resistor at the tip of each probe, is ~90K ohms and this is in parallel with an 8.2pf capacitor. The 90K works against a load resistance of ~49.9K at the OLS end. That forms a voltage divider of sorts and we can move the voltage swing up and down by tying the load resistor to a voltage other than ground. A picture explains it all better:
The jumper reconfigures the term voltage for 1.8V, 2.5V, 3.3V or 5V operation depending on position/presence.
I don't have any comment about the port issues that you're encountering, but edge triggering is already possible via trigger sequence. Just define the first state as low and the second as high and you'll have a positive edge trigger. It's a bit of a pain by comparison to commercial logic analyzers that offer a direct edge trigger selection, but it's better than nothing. I suppose the client could offer an automatic sequence selection for edge trigger mode. No change to the hardware is needed.
Here is another screenshot, where I don't understand what I did wrong, or why the system did trigger. I mean, 0ms starts at the very left edge of the screen in the middle of a burst of data on channel 1. So how does this happen?
Sometimes it even happens that channel 0 is high all the time, while there is a signal on channel 1. Now, as I understand this shouldn't have trigger, should it?[/quote]
Admittedly, the trigger mask and value scheme is a bit obtuse. Basically, each bit in the "mask" that is set, means that channel participates in the trigger. In your case, you have none of the bits in the mask set, so it should never trigger. Each bit in the trigger value that is set, specifies the required state of that channel to meet the trigger condition.
Example; suppose you wanted to trigger when ch 0 and ch 1 are both high but ch 2 is low. Set bits 0, 1, 2 in the trigger mask. Now ONLY those 3 channels participate in generating a trigger. Next, set bits 0 and 1 in the trigger value and make sure that ch 2 is clear. So, trigger mask would be a 7 and trigger value would be a 3. You can either check/clear the bits directly in the trigger mask and value checkboxes or you can enter the value directly in the trigger mask and value entry fields.
What you're trying to do by triggering on a specific serial character, turns out to be difficult at best given the state of the OLS hardware/client software. You have to define a complex trigger sequence of seeing first a long stop duration, followed by a start bit of the requisite duration at the given baud rate, followed by the lsb of character to be recognized present for one baud time, followed by the next bit in the proper state for one baud time, etc etc. Seems like more trouble than it is worth. Given the current 4 deep complex trigger, it may not even be possible. Technically, you'd need 10 states with time qualifications to be able to recognize a specific character.
[quote author="ian"]Could it be the frequency? Maybe the transmit frequency should be 56 or 58khz? IR Toy v2 has the hardware and firmware to measure frequency, but there is no software to decode it that I know of. I'm not sure if IR REC&PLAY transmits at other than default frequency, but WinLIRC certainly does. Maybe that is a better route to go, but you would need to manually set the frequency in the file. If you get it captured with WinLIRC I can help with some test frequency mods to the profile.[/quote]
FWIW, generally Mitsubishi protocol is 32.6 KHz, but there is a Kaseikyo variant that is 37 KHz. It is fairly unusual for a receiver to be using a super narrow band filter. So, anything in the neighborhood will usually work. I've even seen 38 KHz work on a 56 KHz receiver. Here's a graph showing the response of a typical IR receiver:
As you can see, you will get the maximum sensitivity of the receiver at the center frequency, but the response doesn't fall off very quickly as you move away from the center frequency. There is still 20% response at 30% off frequency. Certainly the transmission range would be reduced, but it would still be usable in many circumstances.
[quote author="jawi"][quote author="Qwlciguk"]There seems to be a bug in the time scale when setup for 200 MHz sample rate. It's there in 0.9.4 and 0.9.5b2. All times are 1/2 of what they should be. Easy to see with a 1 MHz signal captured at 100 MHz and 200 MHz. The 100 MHz capture shows 1 us period, but the 200 MHz capture shows 0.5 us period and the measure tool claims a frequency of 2 MHz.
The issue seems to be limited to RLE mode.[/quote]
Are you able to provide me with a project file of this? I remember there was a discussion with David Francis some time ago about this which I couldn't reproduce locally. If you can provide me with a valid capture file, I can build a test on this...[/quote]
Ok, find 2 files attached. Both are 1 MHz signal with one capture at 200 MHz sample rate and the other at 100 MHz sample rate. The 100 MHz sample rate capture shows the correct 1 MHz frequency for the signal, while the 200 MHz sample rate capture shows the signal as 2 MHz.
These were captured with 0.9.4 since I can't download 0.9.5b2 from your site here at work due to it being flagged as malicious content! In any case, it behaves the same between 0.9.4 and 0.9.5b2.
[quote author="Tarloth"]I´m using the 16XXX probe too but in 5 volt, I have an old one and now buy a new one because they are great for the cost, but it´s true that is not cheap, but isn´t so expensive if you need a good probe.
How bad it´s in the real life use a resistance of 100K instead of 49.9K? With that someone not need to make a wing, only change the buffer and the things can work (replacing the buffer off course).[/quote]
If you only work with 5 volt logic, then using 100K termination resistors will work with no need to change the buffer itself. Even with the 2:1 attenuation and baseline shift, it will probably work OK. If you work with lower voltages (3.3, 2.5, 1.8), then you may run into trouble due to the attenuation and baseline shift. You may get lucky and have the baseline shift move the voltage swing upward enough that the smaller signal swing still crosses the 1.5V threshold of the input buffer.
Here's a picture of the termination mod for the 16550 probes:
The hot melt glue is not actually holding down the single row header (that's soldered to the gnd plane). It's just there to protect the resistors and wiring on the header from getting damaged when handling.
For example, using the 74AVC16T245 yo can obtain the threshold for 1.8 volt if VCC it´s 0.8 volt and other input threshold varying the VCC, they work to me better that other solutions and it´s cost effective (propagation time in next paragraphs), but I follow you with this and never tray SSTL2 logic to do this. I love to test everything that seems good or interesting and you take this seriously. Do you have in mind any part to put in replace or companion of current buffer?
Quote
If you drop the voltage enough to make that work, the propagation delay becomes very large.
YES! That its VERY true, but I assume that only a small fraction of users use OLS at really high speed. For example, the part that I random select (maybe with carefully search this would be improved) at lowest VCC (0.8) has a propagation delay of 15ns that limits OLS to 60 Mhz and it´s ugly, but at 1.1 volt (2.5 volt at inputs) has 7nS of delay. I not read about buffers of Texas in last years, but someone in laboratory uses their low voltage series up to 300Mhz, I dont know which is the High input threshold. The advantage of using this translators it´s that we can direct replace the buffer in the current board with very low changes.
Thanks for the schematic[/quote]
If not using the 16550 input probes, then a dual voltage translating buffer replacing the one on the OLS is a reasonable thing to do. That will allow operation with 1.8V logic input signals, where the existing LCX16245 is a little marginal. 2.5V and 3.3V logic should be no issue with the current LCX16245
For my application using the 16550 probe set, the AVC16T245 will not work due to the excessive propagation delay at the very low voltage that I'd have to use for the input supply voltage. With 1.8V logic levels, the signal gets attenuated down to only 600 mv or so at the termination resistor. The minimum VDD for the AVCT16245 is 1.2V and prop delay at that voltage is quite large, but more importantly, I'd expect that the variation from buffer to buffer in the same package, to get larger too. I'd still have to bias the termination resistor to get the input voltage swing centered around the input threshold. So, for the 16550 probe application, replacing the existing AVC16245 with a dual supply tranlator, doesn't do anything but add more prop delay/variation.
I believe that TI has other dual voltage translators that work down to 0.65 volt supply. Still, the ideal design for the OLS application is SSTL. With that, we get a 0.9V or 1.25V threshold with only a very tiny (+/-100mv) input voltage swing required. Those threshold voltages are are designed for 1.8 and 2.5 volt logic levels respectively. If you re-compile the OLS specifying SSTL inputs for the unbuffered "wing" inputs and then provide the 1.8 or 2.5V I/O supply for those pins and supply an appropriate Vref (0.9V or 1.25V), you would have low voltage compatibility without any added propagation delay/variation. You'd need a few jumpers on the board to select the supply and Vref, but all in all, it would be just a small change to the existing OLS design.
I have used dual voltage translating buffers for other applications, but I don't see how to apply them here, since with a 1.8V logic input swing, after the unavoidable voltage divider formed by the 90.9k series resistor and the 49.9k termination resistor, we only have ~600mv of voltage swing at the buffer input and that's not going to work well with dual supply translating buffers. If you drop the voltage enough to make that work, the propagation delay becomes very large.
Given free reign to design something to do this ideally, I'd use an SSTL type buffer which are specifically designed for precise threshold detection. Still have to use the variable termination voltage to deal with different logic voltage levels (ie 5V, 3.3V, 2.5V, 1.8V). FWIW, I noticed that the "wing" inputs can be configured at design time for SSTL input characteristic.
The signal being measured is ~30 MHz 1.8V logic level square wave.
Here's what the signal looks like at the source with the low capacitance probe:
And at the input to the LCX16245 buffer on the OLS with the same low capacitance probe:
A couple of things to note here. The low capacitance probe is significantly altering the circuit due to the 100k ohm input impedance. Remember, there is a 90k ohm series resistor in the 16550 probe tip. So, that forms a voltage divider that attenuates the signal ~2:1. Also, there is significant baseline shift seen as the signal does not get anywhere near ground. This is due to a mis-match between the 8.2pf capacitor paralleling the 90k resistor in the 16550 probe tip and the load capacitance after the probe tip and all the way back to the OLS input. The original 16550 design has a very large load capacitance on the order of 75pf, while our OLS + 16550 cable is much less, on the order of 15pf. The ratio of the probe capacitor to the load capacitance should match the ratio of the series resistance to the termination resistance. If it doesn't, you'll see the baseline shift that we have here.
The obvious thing to do here, is to decrease the termination resistance. The 16550 design is using a 10k ohm termination resistance, yielding a 10:1 attenuation. That's not going to work for the OLS since we don't have inputs that can deal signals that have been attenuated to that extent. Fortunately, we can come up with a termination resistance that matches the 8.2pf : 15pf ratio. 15/8.2 = 1.8 and 90k / 1.8 = 49.2k. If we want to look at the signal with the low capacitance probe, we've already got 100k termination resistance. So, we can simply add another 100k in parallel and see what it looks like.
See the picture below with 50k effective termination resistance:
Here now we can see the baseline shift has gone away almost entirely and the signal comes close to ground on the low side. That is confirmation that we've got the proper matching term resistance compared to the ratio of series capcitance to load capacitance. Unfortunately, we've also got almost a 3:1 attenuation of the input amplitude. In fact, the signal does not even go high enough to be seen as a logic '1' by the OLS. All is not lost though. We can connect the term resistor to a voltage above gnd, biasing it near the 1.5V threshold such that the signal swings symmetrically above and below the 1.5V threshold of the LCX16245. Oddly enough, tying the term resistor to a 1.833V low impedance source, will accomplish that. We'll get about +/- 300mv swing above and below the threshold. I can't measure the final result directly since the low capacitance probe is single-ended and one leg has to be tied to gnd and not the term voltage, but I did verify with static DC voltages of +1.8 and 0V input that we get 1.8V and 1.2V at the OLS input. Just what we want.
Of course, the 1.8V termination voltage is only correct for a 1.8V logic level input. For 5.0V, 3.3V or 2.5V, we'll need different terminating voltages. For 5.0V, 0.944V term voltage centers the swing nicely on the 1.5V LCX16245 threshold. Similarly, for 3.3V, 1.42V works nicely and for 2.5V logic input levels, 1.64V is perfect.
I have done these mods to my OLS. I added sixteen 49.9k resistors to the 16 inputs at the connector with the other end of the 16 resistors all bussed together and bypassed to gnd with four 0.01uf X7R caps evenly spaced over the length of the connector. I added a jumperable low impedance voltage divider for a selectable logic threshold, (ie 5V, 3.3V, 2.5V, 1.8V) and this connects to the common end of the 16 term resistors.
It's all working quite well and it gives me some ideas for doing an add-on wing. I'd want to use something better than the LCX16245 for sure. Probably something with SSTL inputs. Also need something other than a 16550 pod, since these aren't going to be available to the masses at a reasonable price. Simple wires, shielded or not, are not going to cut it. We absolutely need an input isolating network like the 90k/8.2pf in the 16550 probes.
If I get a chance, I'll do a picture of my modded OLS and post it here.
There seems to be a bug in the time scale when setup for 200 MHz sample rate. It's there in 0.9.4 and 0.9.5b2. All times are 1/2 of what they should be. Easy to see with a 1 MHz signal captured at 100 MHz and 200 MHz. The 100 MHz capture shows 1 us period, but the 200 MHz capture shows 0.5 us period and the measure tool claims a frequency of 2 MHz.
