Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by jason

  1. Nope, they don't have to be programmable. Any other remote should work fine. You can even cycle through DVD/AUX/TV to get different remotes as those are most likely set as different devices. I'm not quite sure yet. If you give another remote a shot, that might narrow it down. If you run through the GUI minimalist view two times, do you get, "button already exists" error? Or can you record the same button a couple times. The "GO" button needs to disappear on the other windows, it only works on the minimalist window. I will update that in the next release.
  2. Not really sure what could be going on. Do you have any other remote you could try? Let's see if it's a problem with Flirc, or an issue with remote/compatibility. Perhaps the batteries in the remote are on their way out?
  3. Thanks for the followup, I'm going to get this resolved in a firmware update.
  4. duk @ Neal Does the special wake command from flirc work? I haven't gotten much feedback regarding that release. Yes, the commandline will still show the wake command, and you will be able to successfully record to that command, however the firmware wont officially support this in v1.0. Here are my plans: I'm overwhelmed working out logistics right now. Programming, assembly, packaging take up most of my time and I'm working a lot right now to make this less intrusive to my day so I can continue with development on the GUI and firmware. The repeat firmware will be deployed soon. Once that is done, I will work on the 1.0 release of the GUI, then this will have my full attention as it's one of the last remaining puzzle pieces. Of course stay tuned to the blog or twitter feed where I will be announcing all these releases as well as any new beta firmware images to try. Thanks Neal.
  5. Thanks so much for the reply. Yes, I agree with you, and I'll make this a priority. I started doing some homework, I'm going to try and get to the bottom of this over the next few weeks. I didn't quite follow if it was broken for you entirely, or if you just needed to do as the thread suggested and record multiple times. I don't use a traditional way of 'clocking in ir'. Without going into detail too much detail, it wont be as easy as adjusting for the last extra bit, but will require a good amount of work in my firmware. Thanks again.
  6. Hi Neal - I didn't see the config file attached. You can also email that to me. Is this the firmware version that came on your flirc? Thanks, Jason
  7. @mjkuwp94 As mentioned by everyone, your concerns are extremely valid. I'm using if not the same, but an extremely similar IR receiver you mentioned on sparkfun. You actually won't be able to tell the modulation frequency with that specific part. The output of this part is a noise free, demodulated signal from the received IR signal. If you point your remote at this part, and shoot, you will be able to receive the output on your scope because 56kHz is still within the wide frequency band of the on part filter. However, when passing through the AGC, it could have unpredicted results on the output which will show up as jitter, or worse. You can try this experiment by looking at the output and comparing your scope shot next to the IR receiver, and again when emitting a signal from the other side of the room, where the frequency effects would be more exaggerated. My algorithm will be fine tuned in the future for this, and eliminate the need for double recording (is that your primary concern?). But overall, I have to play a lot of tricks in order for this RC6 protocol to work which is outside the specified 38kHz center frequency of my receiver. All this being said, there are some RC6 protocols which are 38kHz, in which the only problem would be the double presses issue, in which you would need to record your button twice. If this truly what you are seeing, how is the performance of your flirc when you have done so? I've often found RC6, regardless, doesn't seem as solid. Thanks so much mjkuwp94.
  8. I'm really touched. Thank you so much. If you do get anything, please let me know, I'll match the donation.
  9. What an amazing story and it humbles me to hear your gratitude. I'm so grateful the product has solved your problem, and it's personal stories like this that make all the hard work worth it. Thank you so much for sharing, and please don't hesitate to post, email, or shout out should you have any questions or feedback. Happy Holidays and a healthy new year to you. Very Sincerely, Jason
  10. I actually don't own any USB 3.0 hardware yet. But I will definitely have to test this out. Thanks for the post.
  11. I'm not sure you could. You can get a harmony remote and program the specific buttons on the remote just for flirc, while volume up/down could control your receiver. That's what I do, I was never fond of changing devices on the remote if I had to do this often. The cheapest harmony is about 20 bucks, but you get what you pay for: http://www.amazon.com/Logitech-Harmony-300i-Remote-Control/dp/B003IZFCFW/ref=sr_1_1?ie=UTF8&qid=1323539773&sr=8-1
  12. Really sorry this is happening, please keep me posted and I'll await the log.
  13. I'm not entirely convinced it's flirc, but let's try to get to the bottom of it. Do you have any logs you can check? Does XBMC have a log in windows you could look at immediately after a reboot from a crash? How about installing a different version of XBMC? Let me know.
  14. You can try a piece of electrical tape, although I'm not sure that would work as the sensor on the inside is a wide angle. Interesting problem, maybe there could be something in flirc which would say, 'if this button is received, ignore all signals until it is received again'. Would be tricky and I'd have to leave it as a super advanced option as I could see a lot of trouble coming from this.
  15. Yes, I agree, sounds like two different problems. Certainly create a different thread for that one, but gfxmonk is most likely right, this is probably noise due to ambient light. @gfxmonk, there isn't really a log because flirc uses the generic HID driver that comes with the OS. How USB keyboards work is this. When you press a key, the keyboard sends the key, followed by a null. The null says, "I'm not pressing the key anymore". Otherwise, the host thinks you are holding it down. One thing that could be happening is the null is sent too quickly to the host, and the host misses this. But this really shouldn't be the case since I wait for the host to be ready. One thing we can try is the interkey_delay. Changing this value will actually also adversely change the delay this termination signal gets sent to the computer. You can change this with the command line: flirc interkey_delay 0-7 Try increasing this. Doing flirc interkey_delay by itself shows the current value set. Let me know. -- Jason
  16. This definitely sounds like an OS problem, and the first of I've heard of something like this. Interkey delay is for something a bit different. I'm sure linux has a GUI for configuring the keyboard. Maybe there is something in there. When the key get's stuck, could you switch to a terminal and do a: dmesg | tail perhaps that would show us something. Thanks gfxmonk
  17. Pseudo is exactly right. I did experiment with black plastic, which is transparent for the infrared spectrum. I was extremely disappointed in the quality. It's a plastic that looks extremely cheap and I was not happy with the effect on the sensitivity. Maybe one day I will look at this again.
  18. Let me look into why that's not showing up. Thanks!
  19. We could change the sensitivity dynamically, are you familiar with the command line? This hasn't made it's way into the GUI yet.
  • Create New...