Getting back to this just now, it seems that the idea of making a launcher that switches the IRToy into widget mode and then launches IRScope will not work. That is because the launcher, while it can open the comm port to which the IRToy is attached and send the 'p' to make the switch, closing the comm port seems to make the IRToy revert to power up default IRMAN mode. If I don't close the port, then IRScope can't open it.
While I could pursue modifying the IRToy FW to switch to widget mode automatically on recognizing DTR and RTS assertion by IRScope software, I'd still rather modify IRScope to send the "p" switch character automatically. There is precedent in the IRScope software for supporting different hardware via a dropdown selection. Currently IRScope supports 3 different types of hardware; genuine widget, mini-pov3 and discrete logic. The latter is only supported in pulse count mode, while the first two support both pulse count and time mode. Time mode is pretty much deprecated due to the inaccuracies in demod timings. In any case, I propose to add the IRToy as a 4th hardware type selection in "Hardware and Mode" dropdown selection in the IRScope software. I have identified where to make the change to the routine that opens the comm port and now I just have to sort out how to xmit the switch char and where to add the IRToy to the dropdown selection.
I don't think that the JP1 guys should complain that I'm adding support for more hardware types since I understand the original widget may no longer be available. You'd think that they'd welcome support for an alternative hardware platform in that case.
[quote author="StephenR0"][quote author="Qwlciguk"] As for making a special version of IRScope, understand that it isn't software that is continually undergoing significant development on an ongoing basis. It's pretty stable for long periods of time. Besides, not being able to get it to compile a useful executable is pissing me off. Also, if I get it to work, new enhancements can be added that extend the capabilities and if enough people like it, it would become the new standard.[/quote]
I think I discovered how to fix the problem that you were having with building IRScope. I suspect that you built it without problems. If you take the statically linked IRScope.exe and put it in with the other files in the IRScope release, the full user interface is available. It seems to need the other dlls to function. Does that do you any good?[/quote]
Thanks, it seems to work after I did that. I see the full interface now. I'll have to run some tests to see if it all the functions work.
It appears that it is the decodeir.dll that is required to be in the same folder as the exe, or perhaps somewhere on the path, in order for the full IRScope interface to be visible. That kind of makes sense, because the missing part of the interface is all concerned with protocol info etc.
[quote author="KamalS"][quote author="Qwlciguk"] I still don't like the DTR/RTS method, since it relies on behavior of all software that would ever comm with the IRToy, to never raise DTR and RTS together. Seems risky. [/quote]
I don't follow - a serial port can rarely be a shared resource - so when the IRT is communicating with its serial port, no other user application can access it.
Also, no other part of the firmware uses these control signals - they don't need to and that's why these signals are largely unimplemented - which is exactly what I have been saying from the beginning that someone needs to put in the bits to turn these on/off from the firmware handler.
Changing the IRScope software does not seem like a useful idea - unless the maintainer is open. I have no idea who he is and what reasons he has to not cooperate, but if he has been maintaining the software all these years, I am pretty sure there is no one else who is as motivated as him. If you make customization to the software, in a few months, your version is going to be obsolete and all your effort a waste (it's going to be useful to no one but you for your specific use case as the original maintianer would have gone forward with his own updates)[/quote]
You guys are not following my issue with DTR/RTS. It isn't that the IRToy FW is using them. It's obviously not. It's that OTHER SOFTWARE that uses the IRTOY for non-IRScope functions, may raise DTR/RTS and if that switches into widget mode on the IRToy, the user will be disappointed to say the least. It is very common for software to raise DTR/RTS when opening a comm port, even if it's not done explicitly (ie; calling a library funtion to open comm port).
As for making a special version of IRScope, understand that it isn't software that is continually undergoing significant development on an ongoing basis. It's pretty stable for long periods of time. Besides, not being able to get it to compile a useful executable is pissing me off. Also, if I get it to work, new enhancements can be added that extend the capabilities and if enough people like it, it would become the new standard.
[quote author="KamalS"][quote author="Qwlciguk"] Emulating the widget is not the issue here. The IRScope software when talking to a widget simply raises DTR and RTS. Nothing sophisticated. There are other modes that are for other implementations, but they're not interesting here. The IRToy with widget FW can safely ignore DTR and RTS and just assume that we want pulse count mode.
The actual issue here, is that we want the widget FW integrated with the standard IRToy FW. To make that work, we wanted to modify the IRScope software to send a cmd to switch the IRToy into widget mode at the start and switch it back to normal IRToy mode after capture is done. I don't think that using DTR/RTS as a way to detect IRScope client is the way to go, since that would get fooled by other non-IRScope client software that may be raising DTR and RTS. All in all, I think a software cmd is the way to go, but the sticking point there, is that I can't seem to compile the IRScope software and have it fully work. It works partially, but the user interface is largely missing.
I don't know of a list of requested IRScope mods anywhere, but as a long time users of IRScope with my own hardware based widget, I have one and others on the JP1 forum have some too. I know exactly where and how to make the mods, but it's all for naught, since it doesn't compile to a usable program for me.[/quote]
[quote author="StephenR0"] Do we know if any software tries to raise DTR and RTS to the IR Toy at the same time? If there were no conflict, we could just use IRScope as is. This discussion is becoming more immediate with recent developments on the JP1 forums. Apparently, Tommy Tyler felt strongly enough about the election that he left the forum over it. Since there is currently no hardware for sale that IRScope supports, this is an opportunity for the IR Toy.[/quote]
Qwlciguk, from your reply it seems you have some handson knowledge with the JP1 remotes - I have not yet got started, but am curious.
Note my words - if you have tried to get the IRScope working, and it still does not work, barring support from it's author, I would divert attention elsewhere: so reconsider my suggestion that you don't need to touch the IRScope software at all!
Here is how you can solve these two problems:
1. 5s timeout: The IR scope software wants "something" within 5s of it requesting the IRWidget (IRW), so detect when it sets DTR/RTS as the case maybe, and send it "something". YES, this is a hack, but if you can get the software to compile, this is the best I can think of, besides rewriting the application from scratch.
Using any serial terminal emulator, select this option to put the IRT into IRW mode. Then let IRScope do its thing. Once, that's done, using the same serial terminal emulator, take the IRT out of the IRW mode if you want.
Does this make sense?
If you don't know where to patch the irWidget firmware, let me know and I ill create a new thread for it.[/quote]
I did not know that the existing IRToy software already had built-in support for the widget. I assume that is what you're saying. If so, I was thinking that the easy way to work with that, would be an IRScope "launcher" that opens the comm port, sends the cmd to switch to widget mode and then executes IRScope. When IRScope exits, the launcher gets control back, opens the comm port, sends the cmd to go back into whatever the pwr up default mode for the IRToy is and then exits entirely.
I still don't like the DTR/RTS method, since it relies on behavior of all software that would ever comm with the IRToy, to never raise DTR and RTS together. Seems risky.
As far as modifying the timeout on wating for the first byte, I have found the location in the executable that has the hard-coded 5 second timeout and can patch it to any value up to 32767 ms. I also found the location that controls the maximum capture length, since the current 15 seconds is not sufficient for my purposes. I also noticed that the 5 second timeout on first byte section of code does not handle hardware based widgets correctly. Hardware based widgets start sending as soon as the comm port is opened, while the FW based widgets don't send anything until they see the first IR pulse. I'm not sure if the right thing is to change the design of hardware based widgets or change the IRScope software to special case the timeout. To do that, the software would have to look for a change in the stream of bytes and only consider that IR pulses have been detected when the pulse count changes.
I have asked a colleague who is pretty good at software, to see if he can figure out how to compile a usable version of IRScope.
[quote author="KamalS"][quote author="Qwlciguk"]It would better to simply modify the IRScope software to send a cmd to switch the IRToy from IRToy mode to widget mode. Maybe another mod to switch it back to IRToy mode on exiting IRScope software. The original widget design doesn't pay any attention to data sent by the host computer. So, modifying IRScope to send a cmd would not affect the existing widgets out there at all. The source code for IRScope is open to anyone wishing to modify it. If I remember correctly, it's written in Visual C, but is not compilable with the free Visual Studio version.[/quote]
Note that you don't need to touch the IRScope software at all!
I believe by adding RTS and DTR handling to the irWidget firmware, you can make the IRToy emulate the IRWidget exactly - to the effect that it does not matter to IRScope what the underlying hardware is.
If you don't know where to patch the irWidget firmware, let me know and I ill create a new thread for it.
[quote author="Qwlciguk"]If anyone decides to do this, there are a few requests for modifications to IRScope. The one that I can think of is to change the timeout on detecting IR from the current 5 seconds to something much larger, as some IRScope users complain that they can't get everything together and press the button on the remote within 5 seconds after clicking the capture button in IRScope software. There have been a few other requests related to data formatting/presentation, but I expect that those won't interest much of anybody here.[/quote]
Is there a list of requests for modifications to IRScope somewhere?[/quote]
Emulating the widget is not the issue here. The IRScope software when talking to a widget simply raises DTR and RTS. Nothing sophisticated. There are other modes that are for other implementations, but they're not interesting here. The IRToy with widget FW can safely ignore DTR and RTS and just assume that we want pulse count mode.
The actual issue here, is that we want the widget FW integrated with the standard IRToy FW. To make that work, we wanted to modify the IRScope software to send a cmd to switch the IRToy into widget mode at the start and switch it back to normal IRToy mode after capture is done. I don't think that using DTR/RTS as a way to detect IRScope client is the way to go, since that would get fooled by other non-IRScope client software that may be raising DTR and RTS. All in all, I think a software cmd is the way to go, but the sticking point there, is that I can't seem to compile the IRScope software and have it fully work. It works partially, but the user interface is largely missing.
I don't know of a list of requested IRScope mods anywhere, but as a long time users of IRScope with my own hardware based widget, I have one and others on the JP1 forum have some too. I know exactly where and how to make the mods, but it's all for naught, since it doesn't compile to a usable program for me.
Also, I'm not clear that we've pursued the option of having the IRscope maintainer include the modifications to use the IR Toy yet. A way to tell the IR Toy to go into IRscope mode would have to be presented to him and that doesn't currently exist. How hard would it be to get to that point? Shouldn't we get that covered first?
I have had contact with them several times and it seemed they didn't really want us to infringe on their turf so I kinda left it alone. Because of command conflicts I believe it was not possible to just clone their interface, but it has been a while and I forget.
I do have JTRs irwidget source somewhere, I believe. Will try to dig it out.[/quote]
It's clear that the JP1 folks idea of open source while it may conform to the letter of the law, it certainly can't be said that they cooperate with the spirit of open source. This wouldn't be the first time someone has been asked not to tread on their turf.
[quote author="StephenR0"]I don't see why not. We still don't have source code so we can't enhance the IR Toy firmware appropriately, but apparently the firmware worked. I did start to send JTR a message, but he doesn't have any contact information. In any case, here it is.[/quote]
Thanks very much. If we can't get the source code, I suppose we could re-port the FW from the widget. Hate to have to repeat the work though.
[quote author="StephenR0"]Actually, I have the firmware. I was just wondering why it was withdrawn. Is this use of the IR Toy being discouraged?[/quote]
Can you post the FW somewhere so the rest of us can benefit?
Seeing as how the first post that had the IR Widget mode FW attached, was edited on Dec 22 2012, it is reasonable to conclude that the poster removed the attachement. Why this was done, I can only speculate that he doesn't want to support it. There was at least one person that did program the IRToy with this FW recently (Dec 9), so perhaps he would be willing to re-post the FW?
[quote author="AndThen"]Tryed to quote and it ate my post (I deserved it I knew better..)
IRScope is compiled with VC6, which is not available in an Express version. A web search for "VC6 Migration", might turn up something usefull. It used MFC version 6.0..
*Cool links to all the express versiosn would have been here*[/quote]
Hmmmm....then the current maintainer of IRScope is deliberately misleading folks by stating:
"This is the C++ source code of IRScope.exe version 2.01a. It has been prepared using MS Visual Studio 2008."
[quote author="StephenR0"]Well, let's not exaggerate. 50% more would be $37.50. :-)
I'm interested in the IR Toy option, though. And it would be nice if the IRscope mode were integrated into the firmware somehow.
Also, I'm not clear that we've pursued the option of having the IRscope maintainer include the modifications to use the IR Toy yet. A way to tell the IR Toy to go into IRscope mode would have to be presented to him and that doesn't currently exist. How hard would it be to get to that point? Shouldn't we get that covered first?[/quote]
So from the IR Toy side of the fence, someone just needs to define a short key sequence that tells the IR Toy to switch to IRScope mode. Probably should take it out of IRScope mode when closing the comm port too. Once that is defined, preferably by someone familiar with the IR Toy's FW, then it could be presented to the current maintainer for inclusion in IRScope software, but I expect that someone would have to cough up an IR Toy for him to play with to motivate him to do this. Did I forget to mention that he's in the UK?
[quote author="rct"]Interesting, given that he can't keep his politics out of his business, I'd have no problem letting people know the IRToy 2 is a much more capable device than the IR widget and clearly the better deal.
If I had a license for MS Visual C++, I'd modify IRScope to be IRToy 2 friendly (talk to it using serial data instead of trying to signal with RTS/DTR. I've looked through the code, as I recall adding support for a new device shouldn't be that hard, there are about three or four places where the device types are coded. The most complexity in it is from support for the microcontroller-less widget that shifts in samples at 115K baud and doesn't use the same sample buckets as the widgets with an actual controller.
Note: IRScope can't be compiled with the free MS express compiler as it relies on Microsoft libraries that are only available with the paid version of Visual C++. I think it's Microsoft Foundation Classes.
Note 2: It's been a year or two since I looked at any of this.
Happy New Year all.[/quote]
I took a shot at this and I was able to compile IRScope with the free Express version MS Visual C++ 2008 compiler. It did require installing the DDK (to get MFC) also and futzing with some paths etc. I found the info on how to do that on a website somewhere. I'll look for the link. That said, it was all for naught, as it compiled with some 47 warnings, mostly to do with signed/unsigned conversions etc, but if that's all that was wrong, I'd have been happy. The resulting executable though it ran, much of the user interface was missing. It was able to capture and display waveforms, just none of the menus, save for the help-about, were functional (greyed out) and many other things were also missing.
I did also try compiling with the full-blown "pro" version of the Visual C++ 2008 compiler to no avail. It did the same as the express version + DDK. Lastly, I also tried with the "pro" version of the Visual C++ 2010 compiler and still no go. For all of the blathering they do on the JP1 forum about their software being "open" to anyone to modify, you'd think it was actually possible.
No, not that timeout. The one I'm talking about is the timeout whilst waiting for the first IR bursts. If you start a capture and don't actually shoot any IR within 5 seconds, it cancels the capture and displays an error message. This timeout is hard-coded with no adjustability. The timeout to which you refer, is simply the total duration of recording.
It would better to simply modify the IRScope software to send a cmd to switch the IRToy from IRToy mode to widget mode. Maybe another mod to switch it back to IRToy mode on exiting IRScope software. The original widget design doesn't pay any attention to data sent by the host computer. So, modifying IRScope to send a cmd would not affect the existing widgets out there at all. The source code for IRScope is open to anyone wishing to modify it. If I remember correctly, it's written in Visual C, but is not compilable with the free Visual Studio version.
If anyone decides to do this, there are a few requests for modifications to IRScope. The one that I can think of is to change the timeout on detecting IR from the current 5 seconds to something much larger, as some IRScope users complain that they can't get everything together and press the button on the remote within 5 seconds after clicking the capture button in IRScope software. There have been a few other requests related to data formatting/presentation, but I expect that those won't interest much of anybody here.
OLS works acceptably on 1.8V logic as is. Ideally you should bias the inputs a little bit higher by using a pull-up resistor to 3.3V and an input series resistor. The idea is to make the voltage at the input pin of the IC swing symmetrically about the input threshold, as the 1.8V is at logic high or gnd.
