jason
-
Posts
3,733 -
Joined
-
Last visited
-
Days Won
229
Posts posted by jason
-
-
Thanks Jason,
I tried upping the interkey delay to 7 (it was on 6 originally), but couldn't detect any change (I still get stuck keys). Just in case the original 6 was too high, I also tried setting it to 2, but that didn't have a noticeable effect either.
What would happen if it were to send multiple NULLs after each key, as a workaround? Or at least to check whether that's the problem. Is that plausible? Is there anything else I can do to try and prove whether that's the problem or not?
Sorry, I dropped the ball, wondering how things were going? You still seeing this issue?
-
Thanks Chris, yes, please keep me posted. I've actually been looking at this quite a bit to see what the cause is.
-
Your device certainly has many records, however, it shouldn't be full. It's about half way. I can presume it's a software bug, but I'll try to confirm.
Which remote are you using?
-
thanks so much for your really detailed posts. I'll get to these.
One note, with the sensitivity, you have to plug-unplug your flirc. I should have a print out but I didn't really make that official yet as I will be fine tuning this and adding support via the gui.
Thanks again.
-
@Jason
For my own information, isn't the flirc effectively an USB keyboard to the computer? Unless it's sending a keystroke other than what was intended or sending repeatedly, I'm having a hard time figuring how it causes the issue.
Is there some other functionality that I'm unaware of? I test my setups using a text editor. I'm assuming flirc has no app/state information and therefore does not provide different inputs based on the active app (again just an USB keyboard that is programmed to accept IR inputs and provide USB keyboard outputs to the computer). Am I missing something? I ask because I'm still new to flirc and that's the mental model I use in troubleshooting.
It's actually pretty complicated. I appear to the host as a USB keyboard, but my firmware and how I send keys to the computer is entirely up to me. But that's not the problem, the problem is the remote control. When you press a button on your remote, your remote blinks an LED sending a 'packet' across your room. Each packet is sent around 100ms apart from the next, but that 100ms really depends on your remote. Some are 100ms, the harmony is configurable to seconds.
So here is the problem. When you press the button on the remote, the remote sends packets (plural) to flirc. When you hold your button down on your remote, your remote sends 'packets' to flirc. There is absolutely no difference from flirc's point of view. I have to determine if you've just pressed the button on your remote, or if you are holding it down. If you press the button rapidly, you may just end up looking like you are pressing the button down to me. And the worst part is, each remote control is different. So I have to come up with a generic way that will work with everything.
So that's the problem, I'm not sure if that's what you asked, but I'm referring to this as 'sticky' buttons. I'll narrow this down and come up with a really smart way of making this rock solid.
The issue with the new firmware is that I made a mistake somewhere in the USB protocol and windows does not see my 'terminate' character, which is interpreted as the user has stopped pressing the key all together. I'm going to narrow this down really soon.
-
Try experimenting with that delay, between 100ms - 200ms.
Yes, 200ms will limit you to about 5 button presses a second, and if you click faster than every 200ms, the second press would be ignored. Every remote works differently, and I had to make an assumption that no person would really press a button faster than 6 times a second. ~166ms. I believe I gave it wiggle room and stuck it around 140 ms.
Try playing with it, I'm sure you will find a happy spot. Let me know.
-
Yes, there should be a configuration in your harmony software to change a delay for successive button presses. I actually haven't found this myself (nor have I really looked), but others on the forum have mentioned this. Maybe someone will chime in, or if you do find it, could you post back a screenshot or where it is? I'm sure this would help a lot of people.
Just increase that delay to 200ms.
Thanks for the good feedback, and let me know.
-
Pretty curios to know what the original default remote protocol was. I want to perfect this guy, and it's been quite the challenge to make it work across all the flavors of remotes....but I'm going to fucking do it.
:)
-
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.
-
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?
-
follow up.
yes, I found that if I do the routine of programming each MCE button twice then I get good results. As I mentioned above it's not so fun but maybe i am lazier than most!
one issue I can think of is that with this routine some applications will not respond correctly to fast-forward commands. I recall that sometimes one press is 1X forward speed, 2 presses is 2X forward, etc. I didn't test it but I guess the end user (application) will not be able to respond correctly.
btw, you can see in another thread that I am using a keypress application in Windows provided by user NJKA to do the testing.
Thanks for the followup, I'm going to get this resolved in a firmware update.
-
duk
Attached....Hopefully :)... need to always use the Add to Post?.
The 153 firmware version was the fw_wake.bin. I saw that before the official firmware page.
Now switched to the official version from here http://blog.flirc.tv/?page_id=46.
However I've noticed that the Version 1 firmware also has the record wake command, yet on the page at http://blog.flirc.tv/?page_id=46. you say this is not availible until Firmware 1.1!
What is the current status of the sleep issue?
My computer will wake from sleep fine using any key via a standard keyboard when entering an S3 sleep state.
But I need to use the "special" record wake command with flirc.
If I use the following from the commandline
powercfg -devicequery wake_from_s3_supported
The list does not show either the flirc device or an additional HID Keyboard device (only the HID Keyboard device for the normal keyboard.
Another observation is that the Keyboard device for the Flirc has no Power Management tab in Device Settings.
So it would look like, currently the Flirc is not registering it self to be an S3 wake supported device. Is this correct?
Cheers
Neal
@ 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.
-
Just realized I was not complete or detailed enough in my earlier post - sorry!
I also have a Tek 2235 Analog scope and a DSO Nano and a bare IR Receiver Diode. These parts are what I used to measure the modulation frequency. The DSO Nano waveforms can be captured and analyzed on the PC and I think the Nano just barely does have enough bandwidth to pick up the modulation.
I get your point about the jitter and if I get some time I will re-measure the modulation frequency on my two 'Windows' remotes which are actually HP and Rosewill brand. My home theater components are Panasonic and Sony so it seems I will have good luck if I use some other remote controls.
I think the biggest thing I was reacting to is that the front page of FLIRC makes it very clear in capital letters that ANY remote will work though this is not totally accurate. Leaving out all remotes designed for Windows MCE seems like a big hole.
I had initially planned to do my remote integration with Arduino and the Ken Shirriff library but the deeper I get I see I don't have enough time for this. I am sticking with Flirc for now and will either use a Sony universal remote or pick up a Harmony remote since it seems those are highly endorsed by the community.
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.
-
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
-
@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.
-
I'm really touched. Thank you so much. If you do get anything, please let me know, I'll match the donation.
-
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
-
Love the setup
-
On me list. = )
-
I actually don't own any USB 3.0 hardware yet. But I will definitely have to test this out. Thanks for the post.
-
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
-
Really sorry this is happening, please keep me posted and I'll await the log.
-
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.
-
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.
PC randomly waking up when flirc plugged in.
in Firmware Bugs
Posted
This is actually all really good feedback. It will be a matter of hooking up my debugger and trying to figure out why a key is sent when an unknown signal is detected.
The hard part....time... = (