| View previous topic :: View next topic |
| Author |
Message |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
 Posted: Fri May 07, 2010 12:43 pm Post subject: |
 |
|
It's probably not worth bothering him with this, if he's in poor health, especially as we don't have anyone who needs an upgrade for it. I was just thinking of trying a standard leadout time (of let's say, 50k) for all the buttons to see if it would work. Maybe the device itself doesn't really care what the leadout time it. I would also have asked to see sample of the same button learned several different times, to see if the leadout is consistent for each of the learns.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
 |
rct
Joined: 03 May 2010
Posts: 10
|
| Posted: Sun May 09, 2010 12:22 pm Post subject: IR widget, count vs. time mode. |
|
|
| mathdon wrote: | | rct wrote: | | Is IRscope 2.x ok to use input where the carrier has already been removed from an IR decoder or does it need to see the carrier? |
In "IR Widget Count" mode, the one normally used with the Widget, the hardware needs to see the carrier. I understand that "IR Widget Time" mode is for use with demodulated signals, ie when the carrier has been removed by the hardware, but I have no means of testing this.
|
First, out of curiosity, which version of the IR widget do you have? Does it only have an IR Detector and not both a detector and a demodulator?
The serial IR widget and the comprehensive USB (both PIC based) on Kevin Timmerman's IR widget page have both IR detectors and IR demodulators. (The simple USB and the 74HC microcontroller-less circuit) only have IR detectors.)
It looks like from a very brief scan of the ir widget pic assembler that the pic based IR widgets will send timings if RTS was high when the capture was started. I don't know PIC assembler so I'm guessing quite a bit from Kevin's comments. The source I'm looking at is from http://www.compendiumarcana.com/irwidget/irwidget20080827.zip.
From looking at the IR Scope 2.00 source code, what I understand so far as the primary difference between the hardware selection is the order in which it is bring RTS high (vs. DTR) in order to tell the hardware to capture counts vs. timings. (widget.cpp: openport). Other than the RTS/DTR ordering, I don't see any differences for the handling of the IR Widget vs. the MiniPOV3 that has been loaded with the IR widget emulation code.
IRScopeDlg.cpp determines whether to process pulse data or time data based upon the hardware type. Also the hardware type is used to check the number of bytes received to determine the success of the capture.
The hardware type numbers are hardcoded (ie magic) numbers, so m_hardware < 3 is a pulse counting device They match the order of the drop down box:
Count Devices
0: IR Widget (Pulse)
1: MiniPOV3 (Pulse)
2: Discrete (74hc circuit I think) pulse.
Timing Devices:
3: IR Widget
4: MiniPOV3
Would you ever consider hosting the IRscope code on a public source code repository like sourceforge, google code, github?
Thanks,
--Rob |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sun May 09, 2010 4:11 pm Post subject: |
|
|
| rct wrote: | | First, out of curiosity, which version of the IR widget do you have? |
The one sold by Tommy Tyler.
| Quote: | | From looking at the IR Scope 2.00 source code |
This suggests that you have the source code from its publicly available posting on this website.
| Quote: | | Would you ever consider hosting the IRscope code on a public source code repository like sourceforge, google code, github? |
See the previous sentence: it is publicly available, that is how you have it. What more do you want?
_____________
Graham |
|
| Back to top |
|
|
rct
Joined: 03 May 2010
Posts: 10
|
| Posted: Sun May 09, 2010 4:30 pm Post subject: |
|
|
| mathdon wrote: | | rct wrote: | | Would you ever consider hosting the IRscope code on a public source code repository like sourceforge, google code, github? |
See the previous sentence: it is publicly available, that is how you have it. What more do you want?
|
I'm using the IRscope 2.01 Beta 3 binaries that you posted. I have the IRScope 2.00 source code that you posted. I didn't find the 2.01 beta sources. I probably should have specifically mentioned a source code management system. I'd like to be able to access the latest sources, see what's changed between releases.
I'm considering trying to add support to IRscope for reading timings from the USB IR toy device. Since you are maintaining IRScope 2.x, I'd like to be able to send you patches against the latest source, that would hopefully be easy for you to integrate if you accepted them.
The code hosting systems like google code, sourceforge etc, provide other features such as bug/enhancement tracking, wiki's for documentation, etc. Obviously not critical, but nice to have.
Thanks,
--Rob |
|
| Back to top |
|
|
Kevin Timmerman
Expert
Joined: 09 Jan 2007
Posts: 142
Location: West Michigan
|
| Posted: Sun May 09, 2010 5:04 pm Post subject: |
|
|
| rct wrote: | I'm considering trying to add support to IRscope for reading timings from the USB IR toy device. Since you are maintaining IRScope 2.x, I'd like to be able to send you patches against the latest source, that would hopefully be easy for you to integrate if you accepted them.
|
Don't do that. An IR demod module is not suitable for analysis of IR transmissions. The timing is inaccurate and inconsistant, and the carrier frequency unknown. The IR widget allows use of a demod module so that it could be used for remote control. The ability to display the signal from a demod module (time mode) in IR Scope was added to show how BAD these modules are for IR analysis. Early versions of IR Scope didn't support time mode at all. |
|
| Back to top |
|
|
Kevin Timmerman
Expert
Joined: 09 Jan 2007
Posts: 142
Location: West Michigan
|
| Posted: Sun May 09, 2010 5:08 pm Post subject: Re: Automated analysis of IR protocols |
|
|
Yes, I am oPossum in the adafruit forums. |
|
| Back to top |
|
|
rct
Joined: 03 May 2010
Posts: 10
|
| Posted: Sun May 09, 2010 5:25 pm Post subject: Re: Automated analysis of IR protocols |
|
|
| Kevin Timmerman wrote: |
Yes, I am oPossum in the adafruit forums. |
Ah!!, Thanks, I thought you were two separate people until earlier today I went to download & read the MiniPOV3 decode firmware and noticed the URL was http://www.compendiumarcana.com/irwidget/minipov3/povcap.zip
Ok, several things make more sense now.
Thanks for all your contributions and making so much of your stuff open. I've been learning a lot from reading your circuits & code. The 74HC circuit is really interesting. I've been meaning to breadboard that as soon as I get the parts.
--Rob |
|
| Back to top |
|
|
rct
Joined: 03 May 2010
Posts: 10
|
| Posted: Sun May 09, 2010 5:53 pm Post subject: |
|
|
| Kevin Timmerman wrote: | | rct wrote: | | I'm considering trying to add support to IRscope for reading timings from the USB IR toy device. |
Don't do that. An IR demod module is not suitable for analysis of IR transmissions. The timing is inaccurate and inconsistant, and the carrier frequency unknown. The IR widget allows use of a demod module so that it could be used for remote control. The ability to display the signal from a demod module (time mode) in IR Scope was added to show how BAD these modules are for IR analysis. Early versions of IR Scope didn't support time mode at all. |
Ok, I'll certainly respect your wishes. The devices I have all have IR demodulators in them. I've started experimenting with just an IR LED on Friday after reading your ir widget page in more detail. Right now I just have it hooked up to my oscilloscope in photovoltaic mode. I'll probably build something soon for capturing IR pulses. I don't have a PIC programmer (yet). I have a couple of arduinos laying around.
So I guess I should be asking a different question. There seems to be lots of information and tools here in the JP1 community. I'm interested in automation with computers & microcontrollers (what I believe you are terming remote control). The community around each device seems to develop it's own tools. IR Scope, decode IR, etc. seemed like a good starting point for a fairly general utility.
I'd like to have some (hopefully general) tools for viewing & trying to recognize IR waveforms, even if they come from IR demodulators like the one used in the USB IR Toy.
(I understand IR demodulators are bad and that the fall times can be high, like 100 us and inconsistent.)
Thanks for any insights (and of course your past contributions)
--Rob |
|
| Back to top |
|
|
Kevin Timmerman
Expert
Joined: 09 Jan 2007
Posts: 142
Location: West Michigan
|
| Posted: Sun May 09, 2010 6:18 pm Post subject: |
|
|
| rct wrote: | | I'm interested in automation with computers & microcontrollers (what I believe you are terming remote control). |
Girder (Windows) and LIRC (Linux) are the popular programs for doing that. |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon May 10, 2010 3:11 am Post subject: |
|
|
| rct wrote: | | I'm using the IRscope 2.01 Beta 3 binaries that you posted. I have the IRScope 2.00 source code that you posted. I didn't find the 2.01 beta sources. I probably should have specifically mentioned a source code management system. I'd like to be able to access the latest sources, see what's changed between releases. |
I don't normally post the source code of Beta versions as by their nature they are in a state of continuous development, but I will do so in this case if you are interested - though in view of Kevin's comments, I think you may no longer be so.
| rct wrote: | | Would you ever consider hosting the IRscope code on a public source code repository like sourceforge, google code, github? |
I have never used a code hosting system and have no wish to move any of the software I am maintaining to one. However, I don't wish to stand in the way of progress and I see that the RDF maintenance is currently being moved to SourceForge. So if anyone wishes to take over maintenance from me and migrate the programs to SourceForge when the current betas have moved to release, I am happy for them to do so.
_______________
Graham |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Tue Oct 25, 2011 1:44 pm Post subject: |
|
|
Graham,
I liked your stuff so much that I wanted to call it from my own (Java-) programs. So there was the option of either writing a jni-interface (like DecodeIR has) or translating it all to Java.I took the latter approach. The result is available here. (Just the Analyze-function at this time).
In case someone is interested: This is now I use it, in IrMaster and in IrpMaster.
Again, thanx for a great project, and for GPL-ing it!  |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Tue Oct 25, 2011 2:20 pm Post subject: |
|
|
Thanks, Barf. I'm pretty well a convert to Java now. From my experience of it with RM/RMIR, it seems to be what C++ ought to have been. I've been thinking of translating ExchangeIR.dll to Java myself, so that I could incorporate at least the Pronto conversion into RMIR. It's great that you have translated part of it already.
_________________
Graham |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Thu Aug 23, 2012 2:26 pm Post subject: |
|
|
I have translated some more parts of Graham's ExchangeIR to Java, and checked in to SVN (https://controlremote.svn.sourceforge.net/svnroot/controlremote/trunk/exchangeir/src/com/hifiremote/exchangeir/).
* FindRepeat (Graham's name), corresponds to the class RepeatFinder,
* UeiLearnded, reading and writing.
* Some cleanup
* Does not require IrpMaster anymore.
* Misc improvements
Everything documented with Javadoc.
There are still some parts not translated: I have no plan to do this either. This is because of the non-implemented parts are fairly trivial stuff, that is IMHO better handled otherwise, e.g. with IrpMaster (as API-library). |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
