yawor

@jason I would gladly help myself as I'm a programmer (I had experience in programming atmega micro-controllers) but for me it only happened once. What about my suggestion to add ability to send debug messages in firmware using interface which is used by GUI/CLI to program and configure Flirc? I space is constraint then I think you could make a special debug build with less space for key mappings. I think that if some people experience this bug they will be willing to save their current config and use this debug build for a few days with less keys available. It would require GUI to have ability to receive debug messages and save them and people using the debug build would have to keep GUI open to keep logging running.

It looks like you can actually force IRDA port in E90 (and in some other Nokia Symbian phones) to work as an IR beamer. You need to install some software to do this, like for example Psiloc IR Remote. But don't expect to have good range using that.

Hi, I've been doing some hacking with Flirc and EventGhost to get the best possible setup. I wanted all the keys to be intercepted by EventGhost so I could do some more advanced control schemes. My problem was that I don't like mapping remote keys to some arbitrary shortcuts. The problem here is that in Windows I cannot stop key presses just from a specific keyboard (Flirc in this case) so I loose those shortcuts if I use them in Flirc and EG. Now here comes a little trick. Media buttons are not treated as Keyboard events (they are not intercepted by HID keyboard filter driver) but are available to Generic HID plugin in EventGhost. Why is that? Because media keys are not from default keyboard HID usage table but from the "consumer" one. Media keys in EventGhost's Generic HID are received as decimal value of HID code for those buttons. Unfortunatelly Flirc GUI (and CLI too) doesn't have much media keys available to be used. Fortunatelly saved config file has very simple structure :). I've assigned every button on remote to Play button for a reference and then replaced play button code to ranges that are not officially used in Consumer HID Table, from 0x04 to 0x1F, then from 0x23 to 0x2F - this was enough for my remote but there are other unused ranges. Those can be found here http://www.freebsddiary.org/APC/usb_hid_usages.php, table 12 - Consumer. After loading the config back into Flirc I'm getting correct HID codes in EventGhost when I'm pressing buttons. Here are my two suggestions: 1. I don't know if this can be somehow done in the firmware, but when I hold the button pressed on the remote I'm getting a stream of button press events in HID instead of just one (this also happens for not modified config with standard media buttons). When I release the button then HID gets release event correctly. For now I've modified Generic HID plugin to remember last event and not issue it again if enduring events are enabled (required for long press detection and action repeat configuration). Maybe I'm wrong (I don't know HID specifics) but I think Flirc should only send one key press event (on press and hold) and then one release event. If not then forget this suggestion. 2. It would be nice to be able to set arbitrary codes from Consumer table (possibly using hex notation or detected by 0x before the code) using at least the CLI. Maybe new command in CLI like record_hid or something. I know that Flirc can only store 2 bytes per key (modifier + HID code for keyboard table and HID code + 0x66 as a marker for consumer table) so we cannot access codes above 0xFF but I think this is enough for most cases. This would be great feature for advanced users.

Some remotes don't send the same code when button is long pressed. It is possible that your remote sends one code at the beginning and after it detects a long press it changes code to another. Some remotes even send multiple codes in cycle on long press. You can try recording the same button one more time but hold the button on remote before starting recording. You will get either a success (then the code is different) or "button already recorded" (then there is some other problem).

@ptr727 your light dimmer must be using high frequency PWM. It looks like it uses a clock frequency which is close to standard IR carrier frequency (about 38kHz). Also the light itself radiates IR light in addition to visible one. This creates a situation in which IR receiver in Flirc "thinks" it is getting a signal from real remote. As Flirc needs to have wider carrier frequency range sensing ability to support more types of remotes it is also more sensitive to such cases. IR receivers in TV or other equipment is tuned to specific carrier frequency of the maker's remote and can be immune to the flicker of dimmed lights. ---edit--- The standard real time clock uses quartz clocked at 32.768 kHz frequency which is not bang on IR carrier frequency but it is near. Those clocks are very popular to be used as PWM clock source so I would not be suprised if yours is using it too.

I have that too. It seems that every key that has a modifier is skipped when viewing in CLI. It should be rather easy to fix/add that to the tool by dev.

Isn't there no one in home besides you who uses another remote for example for TV?

Try with another remote. Just use one for TV for example but point it in a way that only Flirc gets signal and not TV.

Have you tried it with different remote? There are many RC schemes out there and Flirc doesn't work well with some of them. For example remote can send different signals on every second key press (MCE remotes do this) or even use more exotic scheme. Have you tried the same config and remote on different computer or operating system?

I've had a similar issue but it happened only once. I don't know what caused it. It was after upgrade to 2.6. I've formatted my Flirc and started new configuration with new remote (One For All URC 6440 set to Samsung TV). I've been learning new buttons and testing them right away in XBMC (learning done in Flirc GUI, not XBMC plugin). It started repeating my key presses multiple times with fast interval. It was not about 20 repeats like in OP case but maybe 3 or 4 additional presses of the key I've pressed and it stopped only after I've unplugged and plugged back the stick. My settings: - Sleep detection on (but no button was assigned to WAKE yet) - Noise canceler off - Build-in profiles off - Interval set to 3 As I've mentioned this only happened once so far and after that I've formatted Flirc many times and I've learnt remote keys multiple times until I've got it right for my setup and it didn't happened anymore. When I was playing with Flirc it sometimes got signals from another remote that my wife used in another room for TV. Maybe it got multiple signals at once during learning or something and it caused some problems? But then after replugging it everything was OK and every button I've already configured worked as it should. Maybe it would be good to have some debug build of the firmware and debug mode in flirc gui/cli that would receive extra messages what is happening over its "programming" interface (the one that gui/cli uses to configure flirc) and be able to save it to file. ---edit--- BTW Flirc is plugged directly into USB port in my monitor's USB HUB. It sticks out on one of the sides of the monitor so it's not hidden behind anything and it can easily receive signals from room where the PC stands and also a living room where the TV is. The HUB itself seems to be active and powered from monitor's power suply.

@pope5: you can find a lot of RC codes here: http://www.remotecentral.com/cgi-bin/files/rcfiles.cgi?area=prontong&db=discrete Those are in Pronto code so either your software need to support them or you need to convert them yourself into format recognized by it.

Hi, I really like the idea of Flirc. Up until now I've been using a remote made by a polish company ELMAK which is dedicated to use with PC. It comes with USB receiver which operation is very similar to Flirc because it also works like HID keyboard. Unfortunatelly it is preprogrammed to emit specific keycodes for every key on the remote (as it works only with this remote). It is possible to remap keycodes, but only when a dedicated software is running (only windows is supported). Now I'm seriously considering getting rid of it and buying Flirc :) as it gives much more freedom. Now some features that would be nice to have (but even without them it is still great device): 1. ELMAK's USB receiver emulates both HID keyboard and mouse. If Flirc doesn't have this functionality yet it would be awesome to have this in the future. I know that this would require to change USB code to register two devices istead of one and this isn't probably easy thing to do. After that one could just record remote key to move mouse in each direction (8 directions would be great for remotes that can do left/right/up/down and diagonals). This would also require to set specific mouse speed and accelleration over time (the longer key is pressed the faster mouse is moving). 2. Ability to create and switch profiles (or presets). A profile could contain recorded keys. Some keys could be assigned to switch profiles. An example involving above idea (HID mouse) would be to have direction keys mapped to up/down/left/right keyboard keys in one profile and to mouse in another. An extension to profiles would be to define globals keys. If global key is recorded it would be used if current profile doesn't also have the same key assigned. It would save space if some keys are shared between profiles. A second extension to this idea would be to provide ability to change profiles from the OS (some kind of API). 3. I don't know how Flirc stores each recorded key right now, but maybe this could be useful. It would require a change to both firmware and configuration software. Add ability to record and name all the keys on the remote and then just assign keys by name (name would be only a helpful label, key assignment would actually be by internal key id). 4. Not everything can be done by the device itself. I know that primary objective is to have easly configurable and usable remote control receiver but I know that there will be a lot of more advanced users out there that would like to do more. The idea is to either provide an additional software for advanced functions like key combos or key sequences, or add ability to map remote key is such way so it could be intercepted by such a software. As I don't see a need for another automation tool (there is a lot of them right now) the latter idea is probably better. It could be implemented as second (third if counting with HID mouse), HID device which neither keyboard nor mouse (generic HID device). Such a device can emit arbitrary codes which are not recognized by OS as keypresses or mouse moves. Such events can be intercepted by third party software (like EventGhost) and then trigger some advanced actions. So, to implement 1 and 4 Flirc should be recognized by system as 3 devices (which probably shouldn't be a problem - there are a lot of devices which register more than one device in system like mentioned ELMAK receiver or Logitech Unifying which also registers mouse and keyboard and some other devices as well) and each recored key would have one of the 3 modes (keyboard, mouse or generic for advanced users). I hope that I presented my ideas clearly. Whether I buy Flirc or not doesn't depend on these features but still would be awesome to have at least some of them. I hope that you ship to Poland :).