-
Posts
1,003 -
Joined
-
Last visited
-
Days Won
74
Posts posted by yawor
-
-
You can record Eject button with
flirc_util record_api 184 102
But you won't be able to add modifier keys to it because this is not a key from HID Keyboard usage table (only keys from that table support modifier keys). Because of that this key will act ONLY as an Eject for your DVD drive.
I think that Mac keyboard's controller (inside the keyboard) doesn't send an Eject code when you press option+command+eject, but it sends something else. Maybe it's just a standard Sleep code. Try recording a Sleep button using that command
flirc_util record_api 50 102
-
Which keys are available is dependent on the control schema you choose in the TV for that input.
-
Eject HID code is not from a standard keyboard HID table, but from a Consumer table.
Which Flirc do you have?
-
Do you have access to another PC? It would be good info if you could test it on another PC before exchanging it. Maybe you could ask one of your friends if you can test the device on their computers.
-
I've compared both configurations and there doesn't seem to be anything wrong with them. The IR hashes in both are different. I couldn't find even one that would overlap between devices. I wonder if this may be something with the remote itself? I don't know Harmony and its features/capabilities. Is it possible that the remote is sending commands for both devices? Please re-check your activities' settings.
-
Please save configuration from both Flirc units and attach them here as attachments. Name them accordingly.
-
@lumpynose why do you want to transfer (doesn't matter over which protocol) config file for Flirc to Raspberry (or any other computer for that matter)? The configuration is saved on the Flirc unit itself. If someone is not tech savvy and has never used linux/unix shell then there's really no better way of programming Flirc than do this on a PC using GUI and then just plug the unit to the target system. No need to transfer anything anywhere.
Also every media center OS for RPi requires a little different approach as the base OS is different and can have different file system structure. And RPi is not the only board out there so there would need to be an instructions for different combinations of the boards and OSes. I think it's a good idea, but requires a lot of work. Also there's really need for making a proper manual.
-
OK, thanks. It's a remote for Philips DVD player models DVP3962 DVP3980 DVP3982. I've programmed my universal remote for one of those players.
Protocol being used is RC6, so I was right about that. The carrier frequency is standard for RC6 (36 kHz) so it in range for Flirc.
RC6 is similar to RC5, so it has a toggle bit which is alternating between key presses. But the bit encoding is reversed compared to RC5.
I've tested with old Flirc (fw 3.8.0) and the behaviour is exactly like described by @Segfault. I've been able to record all 4 directional keys (with some errors that the key is already recorded) but after that some keys are alternating between different recorded functions. For example, in my case, pressing left dir key on remote once executes cursor left, but another press on left dir key executes cursor right.
On new Flirc (fw 4.0.0.10 and 4.0.0.15) the keys are properly recognised. There were no issues at all with recording all 4 direction keys (each key recorded twice because of toggle bit in RC6). Normal operation was ok: I've been able to properly navigate in the foreground app using direction keys. No issues like with v1, that the key is recognised as something else.
Jason, if you have a Harmony, you should be able to add one of the DVD models I've mentioned at the beginning.
-
@Foxxi this is a really good question. I've gone through this thread once again and one person posted that v1 worked properly while v2 didn't. That would certainly be an interesting comparison.
-
Can you check the product number on the remote? It should probably be somewhere under the battery cover.
-
I don't use one by myself as I'm using Flirc with Raspberry Pi 3 and OSMC.
Try the sleep/wake key on Media keys controller.
-
Philips uses RC5 and RC6 protocols (which were created by Philips in the first place). It should use 36 kHz carrier frequency, so at least that should not be a problem for Flirc.
-
I would not bother with upgrading to Pro (unless you have other reasons than this issue). I would be very surprised if that worked.
-
If you don't have a Samsung TV then you can try 2051 in TV mode. On that code both v1 and v2 work really well. It uses NECx2 protocol which works really well with Flirc.
I don't know how well do you know your remote, but if you don't want to use TV device slot on your remote for Flirc, then you can switch any other device slot to a TV mode (this means you can use codes for TVs on that slot). To do that you can use 9xx codes: http://www.hifi-remote.com/wiki/index.php?title=992
Just replace SETUP button with Magic button, and when there's an info to tap a specific device button then select the slot using Device button and confirm with Magic.
For example, if you want to use a TV code on DVD slot, then use following sequence:
- Hold Magic for few seconds, until one of the device slots blink 2 times and stay lit.
- Enter 992 (the led should blink 2 times after entering last digit).
- Using device button, select TV slot and press Magic.
- Using device button, select DVD slot and press Magic (the led should blink 2 times after that operation).
After that you can select DVD slot, hold down the Magic button then when in programming mode, enter 2051. If you want to reset DVD slot to a DVD codes repeat the same sequence but in step 3 also select DVD slot (so 2 times the same slot).
This works the same way on my OFA Smart Control.
Also on v2, when you record a button, please hold it a little longer. Flirc v2 analyses the delay between signal repeats and saves that value along the button and key info.
- 1
-
It's an issue with the keyboard layout you use on Windows. It seems that you use your local keyboard layout on Windows, but at the same time you use an US QWERTY (or compatible) layout on LE8.
The issue comes from the fact, that Flirc GUI knows only one kb layout: US QWERTY. Because of that there's a problem if you use a layout which is incompatible with it (e.g. you need to press a different key or combination to get the same symbol as on US QWERTY). Flirc hardware only knows standard HID codes which are always the same depending on the physical position of the key on the keyboard (this doesn't depend on the layout). When you press a key on the keyboard, the operating system receives the HID code and maps it to a key code (the code that is assigned to a specific symbol or function) depending on the selected keyboard layout in the system itself.
To solve your issue, you need to do two things:
- Set the kb layout to be the same on both systems. You would probably still want to use your local layout (as you probably also have a hardware keyboard with that layout printed on the keys) which you use on Windows. Then you should also use the same layout on LE8. I can't tell you how to change it because I don't use LE8.
- You need to change the way you record your keys. Look at your hardware keyboard you have connected to your PC. Find how to get the minus sign on it (which key or key combination you need to press to print "-"). Then open Flirc GUI, go to Controllers -> Full Keyboad, but instead of pressing a button in the GUI which has a minus symbol on it, press the same key or key combination you use on your hardware keyboard by the keys' position on it. So if on your hardware keyboard the minus sign is right next to the right shift, then in the GUI, to record the minus sign, you need to also press a key right next to the right shift (in GUI its "/" and "?" key). You need to do the same for other symbols that are not achieved in the same way as on the US QWERTY keyboard. There should be no problem with symbols which are the same as on the US QWERTY.
There's a plan to add support for different keyboard layouts to the GUI, but that unfortunately requires a full rewrite of the app and probably won't happen that fast.
If you have more questions related to this problem don't hesitate to ask. I'll try to help you the best I can.
-
Yawor,
Thank you for the information, and taking the time to look up the schematics of the case I mentioned, and actually looking into what I am trying to accomplish. I do have a few clarifications/questions. As I said in my original post, I am relatively new to some of this stuff, so I don't mean to sound like I am questioning your knowledge, but rather trying to gain more perspective from it.
No problem :). We all learn something all the time and I'm certainly not a person who knows everything.
I suppose "Boot" is a loaded and incorrect word in this sense, I should have said "wake" or "bring out of hibernation" or something to that effect. Also, you said there isn't a power button, but there is a place to put a reset switch (it's labeled as RUN on the board). My though is (and my thoughts very well may be wrong) If I could get the RUN pins to connect, this would cause the PI to reset, and reload the operating system, essentially "booting" the pi, but as stated before, "boot" is not really the correct term.
Yes, you probably should be able to use output from Flirc SE (the one which is normally connected to motherboard's power switch pins) to the reset and it should work just like you expect. But remember that closing or suspending the OS on RPi doesn't really do anything besides closing the OS :). The CPU and other peripherals are still drawing power. But as you later mention, saving power is not your main concern, so this may be an OK solution for you,
The adapter cables that I added to the media pi case accomplishes the part where you said "The hardware should have its own power supply port (which should be used to power whole set instead of RPi's Micro USB one)". Just past the power switch, there is a micro usb cable that plugs into the pi. Well instead of plugging directly into the pi, I plugged it into a micro usb y cable that has a male plug on the other side going to the Pi, and the 3rd side is a USB port (so power is coming from a source outside of the pi) so I have the flirc powered, independently of the raspberry pi, as well as connected to a usb port on the pi. Would this not be enough to get the Flirc to be able to reset the pi? (I'm assuming not, from your post, but curious as to what is lacking or needed to make this work theoretically)
Thank you for linking some of the power management boards.
That's not exactly what I've meant. The Y cable just splits the power. What I've meant and what the boards I've linked to do, is a circuit which is able to control power delivery to the Pi. These boards communicate with Pi over GPIO. It's something like this: when power button on the board is pressed, one of the GPIO pins changes state, which is detected by a script or software running in the OS, which in turn executes system halt. Just before system closes some other GPIO pin changes state by software, which is in turn detected by the power management board. This is a signal that system is about to finish shutdown and power can be cut in a moment. Of course every board can use their own technique for this, it's just a simplified description of how this works. The power is delivered to RPi through some kind of relay (mechanic or solid state).
My reasoning for wanting to do this is not energy/money based, but rather making a set top box that could be powered on, much like a cable box, DVD player, cable box etc.. Also, it's set up to dual boot between Kodi, and RetroPie, and would need to be restarted/power cycled in some form or fashion to switch over to the other OS.
Wouldn't the reboot function in Kodi be enough? I don't know RetroPie, so I don't know what power options are available in it, but it also probably have a reboot option. This should reboot the hardware so it starts right from the bootloader.
Of course having a hardware reset option just in case isn't that bad at all. Even if you won't use it as a "wake" function. But it can be nice option if OS freezes and the only other way to bring it back to live is to pull the power plug.
-
Hi,
First of all, Raspberry Pi (any version that is available up to this date) does not have any power management by itself at all. So as long as you have power connected directly to the RPi it will draw it no matter if the OS is running or not. There's also no power button support on the board, so it's not directly compatible with Flirc SE - as RPi doesn't support power states you can't control them with Flirc SE.
To actually use Flirc SE with RPi you'd need additional hardware. The hardware should have its own power supply port (which should be used to power whole set instead of RPi's Micro USB one) and probably should also connect to RPi's GPIO pins. It would also probably need additional software running on the Pi which would communicate with extra hardware over GPIO (for example to notify it that the OS has been properly closed and the power can be cut). The hardware should support power button by itself.
I've read the manual for MEDIAPI+ and the board inside of it doesn't support any of the requirements I've described. It looks like it connects the external power supply port directly to RPi, with just a simple hardware power switch in between. This is not enough for properly interfacing RPi with Flirc SE (actually it doesn't add anything helpful in this topic).
There are some extension boards which add power management functionality to RPi. Some examples:
- https://lowpowerlab.com/guide/atxraspi/
- https://hackaday.io/project/1967-atx-pi
- https://www.pi-supply.com/product/pi-supply-raspberry-pi-power-switch/
I don't know if these boards can be adapted to properly work with Flirc SE though. I don't have any of them as there's really no need to do that. My RPi 3 is always on behind my TV. I've been doing some calculations on the power consumption and cost when RPi 3 is running constantly and it was only a few dollars per year (I don't remember exactly how much, the calculation is somewhere on the forum). Of course the cost is also dependent on the cost of electricity in your area (mine is around $0.13 per kWh).
-
@Kevin Cowans as we are only 1 hour apart timezone wise, in case you have some problems running ubuntu let me know using private message here on the forum. I'll try to help you then.
As for using keyboard over BT, you'll unfortunately find that you can only use it when the OS is fully booted. You also need to pair the keyboard in the OS. So for booting Linux from USB you need to use Unifying (or some other keyboard).
-
This is getting weirder :(. I've upgraded to 4.0.15 and checked on both my computers and it still works properly.
Jason has asked this before, but can you test on the same hardware but with a different system? Maybe one of the live usb distros so you don't need to modify your hard drive. I don't know if the sleep will work with live usb though (it should).
How long do you have your Win10? Maybe there's some driver conflict caused by something you've installed before. Windows USB drivers can get messy sometimes and potentially non-related things start to misbehave. It's a last resort, but I wonder if system reinstallation (or factory reset in Win10) would help in this situation.
-
Can you do a test? Clear both old and new Flirc and then record one button on old one and the same on new one. Then save both configs and attach them here. Also clear new Flirc again and load config from old one and then also save it and attach as a third file.
As for the flirc_util error, do you have Flirc GUI opened? It should be closed before accessing Flirc with flirc_util.
-
I see nothing like than neither on my Win7 PC nor my Linux laptop.
-
Yes, of course. It still uses HID standard. I have Option software installed for extra features of MX Master mouse.
You can install standalone Unifying software (without SetPoint or Option) to be able to manage your receiver:
-
You can do that using command line flirc_util command by executing:
flirt_util keys
-
I think it will be :). I've found out what is the issue and already reported it to Jason.
Anyway, I think it's best to record everything from the start anyway. New Flirc has a new feature: it not only stores the IR signal hash and keyboard key code for each record, but also analyses signal and stores the amount of time between signal repeats making the key hold detection to be more robust (that's why there's no longer inter-key delay needed for 2nd gen). Because old Flirc doesn't have that information in its config, when you import it to new Flirc a default value is used. The default may work but it's not guaranteed. After the import is fixed you should do some tests and check if key repeat is working properly for you.
Problems getting it to work properly - Best device to program One For All remote with?
in How To
Posted
@Andaho I'm always recommending a Samsung TV remote :). This can also be any other device which uses either NECx1 or NECx2 protocols. They are simple (both have the same structure, NECx2 differs in that it also have a subdevice id in addition to only device id in NECx1 - so more possible, non-conflicting codes). In comparison to NEC1 and NEC2 (without "x") they also use full frame repeat (when you hold the remote button down, it sends the same signal over and over again) where NEC (without "x") protocols use only a special repeat short signal.
Do you use RemoteMaster software with your remote? I think your remote doesn't have the serial port exposed and needs to be opened to access the port. But this gives a lot of possibilities. You can edit almost anything in your remote, even create your own device profiles, where you can select everything from the protocol to a code each of the buttons sends out. I don't know if there's an extender for your remote (a piece of additional software you can install in it to give it additional capabilities like long press etc).