IRScope v2.01a available!

[mathdon]

IRScope v2.01a is now available. This update to version 2.01 is needed to provide full support for the latest IR Widget available from Tommy Tyler. It also includes version 2.44 of DecodeIR.dll.

[Update: Widgets are no longer available from Tommy Tyler's store, but are now available instead through the Market Place store TxSat Electronics, see also the direct link http://www.txsat.net/]

Although the new Widget design will work with IRScope v2.01, the AutoLocate Widget feature will not work as the new design uses an FTDI X-Series chip, the FT230X, that it does not recognise. AutoLocate works with the new Widgets and IRScope v2.01a but you may notice a few seconds delay after IRScope opens before the Port window changes to the correct port and turns gray. This is not a software issue, it is a result of a slower response of the X-Series chips to certain dll calls.

The X-Series chips are a new range by FTDI and are also not recognised by earlier versions of the FTDI drivers. The current FTDI driver version for Windows, version 2.08.24 issued April 25, 2012, is the first version to support these new chips. If you use IRScope v2.01a with an FT230X-based Widget and an earlier version of the FTDI driver, you will get a message saying that you need to update the driver to this version or a later one.

In testing, there have been occasions when this message has appeared even after the driver has been updated. However, this only seems to occur once and on the first use of the new software. If you get such a message when using the updated driver, please report it in this thread with as much detail as possible of the circumstances in which it occurred. If possible, please also note and report the first sentence of the message as there are two versions of it. One begins "You have a device with an FTDI chip of unknown type which may be a Widget" and the other begins "You have a device with an FTDI X-Series chip which may be a Widget". It will help to diagnose the cause of these spurious messages to know which one is appearing. It is also possible that these spurious messages may be a result of an issue with the FT230X chips used in Tommy's prototypes, as the first release of these chips by FTDI was subject to a product recall. It is this recall that has caused Tommy's latest production delay (see his Market Place posting) as he has received only a few of the corrected chips, with a long delay before his next batch arrives.

There is only one new feature in version 2.01a, intended primarily for diagnostic purposes. If you start it with

Code: Select all

IRScope -test

then you get a series of information and progress messages as AutoLocate seeks the Widget. If you want to open this test mode from a shortcut and the filename in the shortcut is in quotes, then the -test goes after the closing quote.

The source code of IRScope v2.01a is available here.

Link to the announcement of version 2.01.

[vickyg2003]

This seems to be a good place to post my IRScope wish list.


1) I'd like the ability to open exportuei or exportpronto directly from within IRScope, so I don't have to figure out where it is and navigate to it.
Usually when I export signals I want to cut and paste them somewhere else, and this would speed things up and minimize the train of thought issues..


2) I'd like to see IRP rendering come up to the levels that are in IR. Quite often signals in IRScope show undetermined, but they render in IR.
On the simple signals, wher I don't need someone to decode for me, I find the IRP very useful in figuring out OBCs.


3) I'd like the Summary report to break out the IRP the way it does in IR. This would allow me to determine simple patterns at a glance. The way it is now, its tedious because you don't see them all lined up.
I'd like to see the note and the IRP on one line so that everything is all lined up. As it is now, it is tediuos and time consuming to actually use the IRP. I've tried dropping it into a spreadsheet and sorting it, but the notes get lost so I can't find the OBCs for the functions on a custom protocol. When its mixed in with the timing data, nothing lines up, and again I lose my train of thought.

4) I'd like the opening of an ICT to force a break if there is a NOTE, so that the ICT's don't colapse and lose a signal when someone posts one for me to look at.

5) I'd like the ability to round the timings and all the other cool stuff that IR can do with a signal.

6) Is there a way to adjust the intial timeout to be a little longer. Or is that a hardware issue? It often times out between the time I click on the mouse, pickup the remote, find the button and start the capture. As it is now, I am able to make the window 9 out of 10 times.

There was something else, but I forgot what it was.....

[cauer29]

This seems to be a good place to post my IRScope wish list.
6) Is there a way to adjust it to be a little longer. Or is that a hardware issue? It often times out between the time I click on the mouse, pickup the remote, find the button and start the capture. As it is now, I am able to make the window 9 out of 10 times.

The "capture duration" on the left side right under PORT controls that. You can set it up to 15 seconds which should be enough time for even the most fumble-fingered of users to get it together and press the button on the remote. The downside of setting a longer time than the default 1 or 2 seconds, is that if you ARE fast occasionally, you have to wait until the full time selected passes before it finishes the capture.

I think ideally it should have an infinite wait for the first button press with a possibility to cancel the capture altogether if you need to. Then once the first IR comes across, the timeout should apply, but I'd rather see the timeout be applied as x seconds from receipt of the last IR and not the first IR or as it is now, pressing the capture button.

A.A.

[vickyg2003]

This seems to be a good place to post my IRScope wish list.
6) Is there a way to adjust it to be a little longer. Or is that a hardware issue? It often times out between the time I click on the mouse, pickup the remote, find the button and start the capture. As it is now, I am able to make the window 9 out of 10 times.

The "capture duration" on the left side right under PORT controls that. You can set it up to 15 seconds which should be enough time for even the most fumble-fingered of users to get it together and press the button on the remote. The downside of setting a longer time than the default 1 or 2 seconds, is that if you ARE fast occasionally, you have to wait until the full time selected passes before it finishes the capture.

I work with the capture duration all the time. Depending on if I'm going to capture 1, or 10 signals. However this doesn't change the timeout problem. If the first key isn't received in the 5 second time frame, it timesout. The duration changes the amount of time from the first signal to the capturing is terminated (up 15 seconds). Its that 5 second thingy where you let go of the mouse, pick up the remote and locate the key to press thats the killer. It takes my eyes almost the whole 5 seconds to refocus on the remote control after looking away at the screen.

Of course this was even more of a problem with head to head learning. There I was able to get in the window about 20% of the time. This got better when I found out that you could chain learning together and didn't have to start over with the 975 command all the time. The Widget is cool for learning, and makes it so I don't dread the process, but I always feel pressured to make it into that first 5 seconds.

[cauer29]

This seems to be a good place to post my IRScope wish list.
6) Is there a way to adjust it to be a little longer. Or is that a hardware issue? It often times out between the time I click on the mouse, pickup the remote, find the button and start the capture. As it is now, I am able to make the window 9 out of 10 times.

The "capture duration" on the left side right under PORT controls that. You can set it up to 15 seconds which should be enough time for even the most fumble-fingered of users to get it together and press the button on the remote. The downside of setting a longer time than the default 1 or 2 seconds, is that if you ARE fast occasionally, you have to wait until the full time selected passes before it finishes the capture.

I work with the capture duration all the time. Depending on if I'm going to capture 1, or 10 signals. However this doesn't change the timeout problem. If the first key isn't received in the 5 second time frame, it timesout. The duration changes the amount of time from the first signal to the capturing is terminated (up 15 seconds). Its that 5 second thingy where you let go of the mouse, pick up the remote and locate the key to press thats the killer. It takes my eyes almost the whole 5 seconds to refocus on the remote control after looking away at the screen.

Of course this was even more of a problem with head to head learning. There I was able to get in the window about 20% of the time. This got better when I found out that you could chain learning together and didn't have to start over with the 975 command all the time. The Widget is cool for learning, and makes it so I don't dread the process, but I always feel pressured to make it into that first 5 seconds.

My mistake, I was sure that the duration was it. Now that I think about it, it is the way you describe. Nonetheless, it would be great if it worked as I outlined. That is, infinite timeout on waiting for the first IR and duration starts from the last IR received. If you just send one, then you would not notice the difference. If you want to capture a really long macro for posterity or whatever and it lasts longer than 15 seconds, currently you're out of luck. I have had that problem. In any case, infinite timeout on receiving the first IR would require a cancel function to be available.

Personally, I haven't had all that much problem with the current 5 second timeout, but I do sometimes have to plan everything in advance. That is, place the remote pointing at the widget with a finger over the button to be captured and then with the other hand click the capture button in IRScope. Still, it would be better that we can wait infinitely without danger of timeout.

A.A.

[The Robman]

I would like the ability to configure the UEI export mode so that it creates an actual IR file, then I would could skip straight to step 5:
http://www.hifi-remote.com/forums/viewtopic.php?t=14280

[vickyg2003]

My mistake, I was sure that the duration was it. Now that I think about it, it is the way you describe. Nonetheless, it would be great if it worked as I outlined. That is, infinite timeout on waiting for the first IR and duration starts from the last IR received. If you just send one, then you would not notice the difference. If you want to capture a really long macro for posterity or whatever and it lasts longer than 15 seconds, currently you're out of luck. I have had that problem. In any case, infinite timeout on receiving the first IR would require a cancel function to be available.

Really a 15 second macro? Does anyone ever point the remote at their unit that long? I do like the 15 second limit though. That is enough for me to easily capture 10 numbers without feeling rushed. Since I got a harmony, I've created a template for RM and then capture the signals in a specific order. I have an RM template with many groupings of keys in the order I will push them, so it makes it easy for me to get the keys. I still like a shorter session, 5 button session at a time.

Personally, I haven't had all that much problem with the current 5 second timeout, but I do sometimes have to plan everything in advance. That is, place the remote pointing at the widget with a finger over the button to be captured and then with the other hand click the capture button in IRScope. Still, it would be better that we can wait infinitely without danger of timeout.

A.A.

Because I mostly use my widget for tweaking a protocol, I get in a rut use mouse to assemble, switch tabs, copy, swtich to IR, edit,, right click, paste,save, upload, switch to IRScope, Capture, release mouse, grab remote, look for target key, press button, compare pictures. Lots of times I miss the window, or get a bad learn because I rushed. I still test in etch-a-sketch mode so, I need to get the first key right so that the pictures line up correctly. Otherwise I'd just press any key to get me that whole 15 seconds, but it needs to be the first key I press for side by side picture comparrison. Since I'm still an apprentice, it takes me a LOT of repetitions of that sequence to get it right so it does get tiresome when I miss my window.

[vickyg2003]

I would like the ability to configure the UEI export mode so that it creates an actual IR file, then I would could skip straight to step 5:
http://www.hifi-remote.com/forums/viewtopic.php?t=14280

Ditto.

[cauer29]

Really a 15 second macro? Does anyone ever point the remote at their unit that long? I do like the 15 second limit though. That is enough for me to easily capture 10 numbers without feeling rushed. Since I got a harmony, I've created a template for RM and then capture the signals in a specific order. I have an RM template with many groupings of keys in the order I will push them, so it makes it easy for me to get the keys. I still like a shorter session, 5 button session at a time.

Well, not really a macro in the conventional sense, but a precisely timed IR sequence output by a home automation controller. Some sequences last as long as 25 seconds depending on the whether the TV is on at the beginning or not. In such cases, I do 2 or more overlapping captures with the first one starting before the first IR cmd and the 2nd starting 10 seconds or so after the first IR cmd. It takes 2 separate captures to get all of it.

A single IR cmd from a simple IR remote is received and translated to X10 power line and then received by the home automation controller, which then sends RS232 cmds to a slave controller that electronically presses buttons on a 15-100 JP1 remote. Button press duration can be precisely controlled. The master home automation controller also communicates directly via RS232 with the AV receiver, skipping the whole IR link there.

In order to debug all of this takes a lot more than a simple widget since there are 3 different domains to deal with, all running at the same time. X10 pwrline, IR (raw and demod'd) and RS232. So, I've created a custom logic analyzer interface that feeds all 3 domains into a low cost (<$50) logic analyzer for capture. That is the only way to see the timing of all 3 domains simultaneously. Ideally, the logic analyzer software would interface with DecodeIR dll and annotate the trace with the protocol info. Same for X10. It does already decode RS232, but I'm not really a software guy, so I'm not able to extend the software's functionality to do this. If I can't tell what IR protocol/OBC is being sent, then I have to resort to the widget and IRScope.

If all you're dealing with is IR, then the widget is almost perfect, falling short only for carrier-less protocols and maybe a few other obscure cases.

A.A.

[vickyg2003]

Really a 15 second macro? Does anyone ever point the remote at their unit that long?

Well, not really a macro in the conventional sense, but a precisely timed IR sequence output by a home automation controller.

Ahh, so this isn't a human holding and pointing a remote, but some controller running through a set of instructions. I can see that working. Machines are trainable, my humans are not! I can't train my family to point the remote at the TV long enough to let a long macro finish, even if there are clear indications on the screen and the remote LED is still flashing. That's why I fell in love with extenders with the fast macros. The macro failure rate dropped dramatically as the speed of the macro increased. Back in the Yahoo days, John Fine was always talking about macro speed when he was excitedly writing about his extender development, and yet it took me 6 years to actually try an extender. The concept of the fast macro was too foreign for me to understand what all the excitement was about. (Any wonder it took me so long to understand IRP, haha.) Of course once I used an extender I immediately fell in love. Back then we had a 13 step macro that would switch from DirectTV to Antenna. The unextended remote stepped through that slower than it would take me to do it by hand. The first time my extender ran that same macro, I couldn't believe how fast it ran! I was even more amazed that my impatient jump-happy sports fans could now switch from Fox (antenna) to ESPN (Directv) without getting into trouble. I no longer was having to "fix" the TV several times during each game, when the menu was stuck on the screen. You would think that using that macro probably 50 times on a typical Saturday afternoon, they would shortly figure out that they needed to wait until the macro finished. But after 5 years, they were still having trouble and couldn't leave me in peace. After the extender came into play, they could actually watch tv un-aided unless there was too much beer involved. That's why I was so surprised that you would need more than 15 seconds for a macro to run! Now I understand.

[cauer29]

Really a 15 second macro? Does anyone ever point the remote at their unit that long?

Well, not really a macro in the conventional sense, but a precisely timed IR sequence output by a home automation controller.

Ahh, so this isn't a human holding and pointing a remote, but some controller running through a set of instructions. I can see that working. Machines are trainable, my humans are not! I can't train my family to point the remote at the TV long enough to let a long macro finish, even if there are clear indications on the screen and the remote LED is still flashing. That's why I fell in love with extenders with the fast macros. The macro failure rate dropped dramatically as the speed of the macro increased. Back in the Yahoo days, John Fine was always talking about macro speed when he was excitedly writing about his extender development, and yet it took me 6 years to actually try an extender. The concept of the fast macro was too foreign for me to understand what all the excitement was about. (Any wonder it took me so long to understand IRP, haha.) Of course once I used an extender I immediately fell in love. Back then we had a 13 step macro that would switch from DirectTV to Antenna. The unextended remote stepped through that slower than it would take me to do it by hand. The first time my extender ran that same macro, I couldn't believe how fast it ran! I was even more amazed that my impatient jump-happy sports fans could now switch from Fox (antenna) to ESPN (Directv) without getting into trouble. I no longer was having to "fix" the TV several times during each game, when the menu was stuck on the screen. You would think that using that macro probably 50 times on a typical Saturday afternoon, they would shortly figure out that they needed to wait until the macro finished. But after 5 years, they were still having trouble and couldn't leave me in peace. After the extender came into play, they could actually watch tv un-aided unless there was too much beer involved. That's why I was so surprised that you would need more than 15 seconds for a macro to run! Now I understand.

The macros need more than 15 seconds to run, not because of any limitations on the controller sending cmds, but due to various equipment receiving the IR cmds needing delays. The TV doesn't listen for IR cmds during the 5 seconds immediately following power on. So, if the controller senses that the TV is off at the start, it inserts a delay. It's not a simple wait though, during the delay, other tasks are done, such as turning on the AV receiver and getting it switched to the proper input configuration. Other equipment may also need to be powered on.

The TV requires a lengthy procedure that involves up to 6 cmds stepping through input selections to arrive at the desired input source. When stepping through the internal HDTV tuner selection, there has to be a 1.5 second pause as the TV will not respond to cmds during the 1.5 seconds immediately following landing on that input. Some devices using RC5 or RC6 (your fav) require special treatment to get around the toggle bit problem.

Implementing a one button power off is almost as challenging. Naturally, the controller has to be smart enough to sense the power state of equipment so that it doesn't send a power toggle cmd to a device that is already off. Other devices have discrete pwr cmds but with RC5 or RC6. The toughest nut to crack is the kid's PS3 since there is no discrete pwr cmd and there is not even a power toggle at all. It requires on the order of 10 blind IR cmds to have anything approaching a guarantee that pwr will actually go off. Even then certain apps like Netflix prevent any blind sequence from being 100% successful. It does have a touch sensitive button that if held for 2 or 3 seconds, is a force pwr off, but I haven't gotten around to rigging something up to simulate a user holding their finger on the touch sensitive button yet.

Before I came up with all of this I had a large card with step by step procedures of how to do various things for family members. This worked ok, but it ended up with the kids simply doing it all intuitively and not being able to explain to my wife how to get from A to B. So, she would just not use it unless it happened to be left in the state she needed. Next I graduated to JP1 macros with an unextended 8910 which seemed to have pretty fast macro execution compared to other JP1 remotes, but requiring the user to hold the remote pointing at the equipment for 15+ seconds, was not popular at all and without any state sensing, there was always the "harmony" problem where the power state would get out of sync and I'd already solved that problem for the upstairs TV with power state sensing. So, I took on the task of moving the macros to the home automation controller. It took a really long time to do that and without any widget or other way of recording what exactly was happening, it was very challenging. Along the way, widget and logic analyzer capabilities were acquired, but by that time most everything was working. It was a real eye opener to see the exact interplay between all of the pieces, once I got the logic analyzer.

At this point, the only remaining issue is the upstairs TV setup once a month or so, fails to pwr off the AV receiver via the home automation controller macro. Since there is power state sensing for the receiver, I may end up implementing a feedback system where it sends the discrete power off cmd and if it doesn't receive confirmation via state sensing, it sends it again. Still, that is a band-aid and doesn't actually fix the root cause of the issue, whatever it is.

The really cool thing about this whole system is that it is self-healing. That is, anytime things get out of whack due to some glitch (happens rarely) and what the user wanted to do didn't happen, simply pressing the button again corrects it with no idiotic Harmony questions about what is on and what is off. Currently the downstairs system hiccups maybe once or twice a year and the upstairs system once a month. Once a month is annoying enough to me and irritates my wife sufficiently that I need to fix it.

A.A.

[vickyg2003]

Some devices using RC5 or RC6 (your fav) require special treatment to get around the toggle bit problem.

Yeah I only have one left!! I hate that RC5 protocol!! I had 4 of them when I started, but now most of them are at the Goodwill. Still nice units because they all had stereo av in, real useful.

The really cool thing about this whole system is that it is self-healing. That is, anytime things get out of whack due to some glitch (happens rarely) and what the user wanted to do didn't happen, simply pressing the button again corrects it with no idiotic Harmony questions about what is on and what is off.

I am slowly getting there. Surprising how easy that can be when there are discretes. I've been very careful about my selection of equipment since I became IR aware. I've replaced a lot of equipment since the digital conversion, and each replacement I checked for discretes and toggling protocols prior to purchase.

Currently the downstairs system hiccups maybe once or twice a year and the upstairs system once a month. Once a month is annoying enough to me and irritates my wife sufficiently that I need to fix it.

A.A.

Yes, the only time mine gets out of synch now is during a power outage. The input on my RC5 TV gets out of whack, and since I have hidden the ability to change it, to keep the DH from switching to channel mode it is a challenge getting it back in synch. In fact I use the documentation that I prepared from Phil's template, to figure out how to do it myself.

[jward]

I have an additional use case/wish list for IRScope, capturing a long session and I'm talking 30 minutes here. I guess it would be most convenient if it could record indefinitely until a stop button is pressed. It would also be good to collapse or ignore any nothing space between actual signal bursts.

The case is IR signals sent to a group of toys that blink lights based on the codes sent for a long light show. It is desirable to record the signals for the whole show to process through them later.

[Barf]

For the use case you have in mind, I am not sure if blowing up Irscope is a good solution. Rather, you would like a portable "IR recorder", and a possibility to offline analyze the "recording". In this use case, it may be assumed that the carrier is of known and constant, "normal" frequency. So, such an "IR recoder" can in principle be as simple as,say, a TSOP4838 or similar connected to the microphone input of a mobile device, using a standard audio recording software.

I am not aware of a suitable available decoder for this use case; "we" can probably cook up something if the need arises.

[mathdon]

After becoming impossible to get when Tommy Tyler's store closed, IR Widgets are now once again available, through the Market Place store TxSat Electronics. See the update to the first post in this thread for links.