Jump to content
Flirc Forums

Bluetooth capability to be added at v3?


Hotwire

Recommended Posts

I'm sure BT connectivity has been requested before, but I have to request if it'll be added for v3.

 

I think BT is inevitable for remote control. My cable provider even started recently rolling out BT support for new STBs, and those are the types of companies that are usually the slowest to break molds. 

Link to comment
Share on other sites

Wouldn't it be simpler to just use USB BT adapter (or built-in one in case there is one)? You've presented a single example (PS4) where the protocol description is actually available. Adding whole BT stack to Flirc just for PS4 is not very good idea in my opinion. Do you have more examples of BT remote interoperability between different producers?

As an example, I have an LG magic remote for my TV. It uses BT. I've been trying hard to pair it with my PC without any success. I assume it's exactly the same situation with other producers.

Link to comment
Share on other sites

List of BT devices supported by Harmony: https://support.myharmony.com/en-us/how-to-pair-over-bluetooth-usb-receiver-or-wi-fi

You wouldn't add BT to Flirc for PS4, but to control Flirc with a BT remote. The benefits are:

  • Removing line of sight issues in regards to device placement, and a far greater signal range.
  • Reduction in relay devices to bridge devices that are in different rooms. Currently you'd have to purchase either a Logitech Harmony Companion (which uses a hub as RF>IR relay), or/and those IR pyramid devices which do IR>RF>IR. This is much less efficient, as well as being a disaster if you'd want to control multiple devices in different rooms from a single room (you'd have to buy a whole bunch of relay equipment to bridge each room). BT would remove the necessity for relay devices, as range is greater, allowing for direct communication.
  • BT support would allow many more users to install the Flirc Streacom Edition in non-Streacom enclosures. The FLIRC-SE is a much cleaner solution than the Flirc dongle, because it is an internal device. It's also the only solution that allows users to remotely boot from S5 power state. If users want to install a FLIRC-SE now, they'd have to mod their case (drill a hole in it to receive IR) if it is not a Streacom. BT would avoid having to do enclosure modifications.
  • And lastly is reduction of input lag. Takes this with a grain of salt, it might be my imagination, but last time I tested it felt like commanding with my Harmony via BT to my PS4 was faster, than it was with my Harmony via IR to my STB. It felt like there was less overall input lag between Harmony and PS4 via BT. But I'll leave this one in the middle before I've tested some more.
Link to comment
Share on other sites

Yes, I know what advantages it would bring. It's not my decision to make of course, but to be honest, I don't see that ever happening.

  • First of all, Logitech probably has agreements with all manufacturers which they support with their BT remote control. That gives them an access to protocol specifications. I don't say it's impossible, but certainly hard for a small company like Flirc to get such an agreement from big TV appliance producers.
  • Every manufacturer uses rather their own control protocol. Flirc would need a separate support (in the firmware) for each manufacturer's BT remote control. This is NOT standardised in any way.
  • This applies at least to Samsung and LG (I don't know about others): BT TV remotes still require an IR to turn the TV on first as they don't support turning on over BT. This means that the remote won't send a BT command for power button.

I hope I'm in the wrong here though as that would certainly be a nice feature. But I won't hold my breadth.

  • Like 1
Link to comment
Share on other sites

Imagine if, back in the day when IR got traction, all the different manufacturers implemented it, used their own codes, and refused to share them. And if there was no way to easily intercept and decipher said codes. 

That's more or less what you have with BT today. BT also has limitations and as for how "fast" it is that is entirely up to how well it is implemented. Logitech worked directly with Sony on their PS4 implementation, for example. 

Doing the same thing for example with a HTPC is an entirely different problem. 

If anything, I see wifi remote control becoming more common. The Shield and a few other devices already offer it (the Harmony can control the Shield over Wifi today) and virtually every device including TVs today have wifi, whereas BT isn't as common.

The FLIRC is an excellent supplement to devices like these. For example, having full keyboard shortcuts mapped to IR makes the Shield far more functional with apps like Kodi that support keyboard shortcuts. 

  • Like 1
Link to comment
Share on other sites

Imagine if, back in the day when IR got traction, all the different manufacturers implemented it, used their own codes, and refused to share them. And if there was no way to easily intercept and decipher said codes. 

That's more or less what you have with BT today. BT also has limitations and as for how "fast" it is that is entirely up to how well it is implemented. Logitech worked directly with Sony on their PS4 implementation, for example. 

Doing the same thing for example with a HTPC is an entirely different problem. 

If anything, I see wifi remote control becoming more common. The Shield and a few other devices already offer it (the Harmony can control the Shield over Wifi today) and virtually every device including TVs today have wifi, whereas BT isn't as common.

The FLIRC is an excellent supplement to devices like these. For example, having full keyboard shortcuts mapped to IR makes the Shield far more functional with apps like Kodi that support keyboard shortcuts. 

The thing about RC over WiFi, is that latency is quite high. Also not having physical buttons for RC is not really desirable imo.

Link to comment
Share on other sites

@ixian I don't think this is a matter of manufacturers sharing IR protocols. It's a matter of transfer medium and how easy/hard it is to analyse the signals. To analyse even some new IR protocol you should be able to do that using equipment that costs less than $20-$30. There's really not much variance between different protocols: they can vary in carrier frequency, timings between bursts and lengths of the bursts themselves. The only issue may be in decoding how to interpret these bursts as ones and zeros. Medium (as in IR light) is relatively easy to work with. Also it's usually a one way communication so you don't need to track it in both ways. Actually you really don't need to even decode the original command and use different techniques to just create your own information from detected timings. Flirc works like that. Most of the generic IR receivers (non-MCE) that can capture almost any remote work like that. Unfortunately there are some protocols which send the same command code with varying signals (so each button press sends a signal that is somehow different from the previous). RC-5 is such protocol for example. It changes a single bit between presses. That's why you need to record each key twice in Flirc if you use RC-5 protocol (like MCE).

BT is at a totally different level. You have bi-directional communication. BT remotes usually are first paired to the target device (so the remote knows BT address of controlled device and the device knows the BT address of the remote). Pairing can be a standard one (like in case of PS4) or proprietary (like in case of LG Magic Remote). After that you need to know how a device is controlled. This can be done with different BT profiles (serial profile, HID profile, Bluetooth Low Energy, etc) where each profile has totally different setup and way of working with. Hardware which allows to capture and analyse BT traffic is horrendously expensive. Medium (as in RF @ 2.4 GHz) is not easy to work with because there are other protocols also working in that band (mostly Wi-Fi).

@Hotwire I still think that the best approach with BT would be to use BT adapter. But it requires some work to be done. First of all you need to find out what's the control scheme of specific BT remote and if it's possible to pair it with generic BT adapter. Then some software would be required to translate BT commands into commands usable on the target device. There's also a chance that the remote uses HID profile and at least some keys can work without additional software (like direction keys).

  • Like 1
Link to comment
Share on other sites

The thing about RC over WiFi, is that latency is quite high. Also not having physical buttons for RC is not really desirable imo.

That may be anecdotal for you but is not an inherent flaw. I use WiFi integration with a hub and one of my Shields and have no issues with latency whatsoever. A lot of factors can cause latency issues.

@ixian I don't think this is a matter of manufacturers sharing IR protocols. It's a matter of transfer medium and how easy/hard it is to analyse the signals. To analyse even some new IR protocol you should be able to do that using equipment that costs less than $20-$30. There's really not much variance between different protocols: they can vary in carrier frequency, timings between bursts and lengths of the bursts themselves. The only issue may be in decoding how to interpret these bursts as ones and zeros. Medium (as in IR light) is relatively easy to work with. Also it's usually a one way communication so you don't need to track it in both ways. Actually you really don't need to even decode the original command and use different techniques to just create your own information from detected timings. Flirc works like that. Most of the generic IR receivers (non-MCE) that can capture almost any remote work like that. Unfortunately there are some protocols which send the same command code with varying signals (so each button press sends a signal that is somehow different from the previous). RC-5 is such protocol for example. It changes a single bit between presses. That's why you need to record each key twice in Flirc if you use RC-5 protocol (like MCE).

You might have misunderstood me; I was just using IR as an example "what if". To your point though, yes, decoding IR signals is easy and straightforward, BT is another matter entirely and understanding the inner workings of remote control there is hard. 

  • Like 1
Link to comment
Share on other sites

That may be anecdotal for you but is not an inherent flaw. I use WiFi integration with a hub and one of my Shields and have no issues with latency whatsoever. A lot of factors can cause latency issues.

Not anecdotal. Controlling an IR device via my Harmony Hub (phone-WiFi->hub->receiver) has got more noticeable input lag than using the physical remote of the Harmony set (remote->hub->receiver). But it entirely depends on how you use it. The increase in input lag is far less noticeable if you don't need to spam commands. For me it is too slow. It might be less slow when taking the hub out of the equation (phone->WiFi->receiver), but it'll never be as responsive as remote->receiver. Even it would in be as fast, a virtual remote is still a massive pain the rear. 

Link to comment
Share on other sites

Even it would in be as fast, a virtual remote is still a massive pain the rear. 

Nothing can beat a remote with physical buttons :). Especially one with good key layout which makes it easy to control your equipment without looking at the controller.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...