Somewhere there just has to be a software engineer who is sitting around, sluggin' rats in the gutter, saying to himself "If only I had an interesting project to work on". Well, Bunky, here's your chance.
https://www.hifi-remote.com/forums/dload ... le_id=3336
Tommy
Looking for a Volunteer Software Designer
Moderator: Moderators
-
Tommy Tyler
- Expert
- Posts: 411
- Joined: Sun Sep 21, 2003 11:48 am
- Location: Denver mountains
I read your .doc file and still can't quite figure out what you're asking for, especially in comparison to CaptureIr.
Do I understand correctly? You are talking about hardware more complex than the CaptureIr hardware, so that the hardware does the demodulation with the advantage that you are immune to most of the Windows latency problems, and the disadvantage that you don't know the frequency.
I know I'm way behind my promises on improving CaptureIr software. In its present form it is barely usable by those who aren't IR experts, and its performance is seriously worse on single CPU systems than on dual CPU systems.
But if you find extra software help, I think CaptureIr is the better starting point.
If you want CaptureIr software connected to alternate hardware, that also shouldn't be too hard. DecodeIr works almost as well with unknown frequency as it works with known frequency. CaptureIr has its frequency detection and processing software overly tangled with the rest of its low level processing so it isn't trivial to make it optional, but even without a choice of optional hardware, making most of the frequency handling optional in CaptureIr is the most important next enhancement. Windows latency problems mess up the frequency detect far more than other aspects of CaptureIr and it would usually give better results on single CPU systems if most of the frequency processing were turned off.
The connection of CaptureIr to DecodeIr makes the output significantly easier to use. I haven't worked with your previous hardware/software design in so long I've forgotten all the issues (I still have it sitting around somewhere), but I recall that I couldn't see any easy way to get more convenient output from it.
Do I understand correctly? You are talking about hardware more complex than the CaptureIr hardware, so that the hardware does the demodulation with the advantage that you are immune to most of the Windows latency problems, and the disadvantage that you don't know the frequency.
I know I'm way behind my promises on improving CaptureIr software. In its present form it is barely usable by those who aren't IR experts, and its performance is seriously worse on single CPU systems than on dual CPU systems.
But if you find extra software help, I think CaptureIr is the better starting point.
If you want CaptureIr software connected to alternate hardware, that also shouldn't be too hard. DecodeIr works almost as well with unknown frequency as it works with known frequency. CaptureIr has its frequency detection and processing software overly tangled with the rest of its low level processing so it isn't trivial to make it optional, but even without a choice of optional hardware, making most of the frequency handling optional in CaptureIr is the most important next enhancement. Windows latency problems mess up the frequency detect far more than other aspects of CaptureIr and it would usually give better results on single CPU systems if most of the frequency processing were turned off.
The connection of CaptureIr to DecodeIr makes the output significantly easier to use. I haven't worked with your previous hardware/software design in so long I've forgotten all the issues (I still have it sitting around somewhere), but I recall that I couldn't see any easy way to get more convenient output from it.