Jump to content
Flirc Forums
burke

Ability to change speed of Flirc

Recommended Posts

Hi guys :)

 

Yes I know this has been discussed before, yes i know that keyboard repeat rate is controlled by OS but....

 

Currently I am running XBMC on top of Ubuntu minimal, before that it was XBMCbuntu and before that Openelec.

 

What ever I tried it never worked, I would enter needed commands but nothing changed spped of keyboard and flirc was always same.

Back when I was on XBMCbuntu I learned that keyboard repeat rate was "hardwired" inside XBMC - but i did not quite understand what it meant.

 

I always used SSH to log into my XBMC machine and change setting from remote computer and that is way I did not understand what was happening.

 

 

So to "problem".

 

On my MBMC minimal I switch to terminal window and enter:

sudo kbdrrate -r 2 -d 150 

and keyboard in terminal really slows down, but if I switch back to XBMC nothing has append...speed is always the same.

 

My conclusion is that signal is picked up by xbmc before OS can slow it down so it has no effect. :(

 

 

Why I think it would be good?

 

There are a lot of people using Openelec, XBMCbuntu and minimal (not sure how this looks on OSX and WIN OS) 

and lot of people use cheap remotes (like my self) which have no trannsmiter speed contol...

 

My suggestion?

_________________________________________________________________________________________

 

Would it be possible to implement some kind of script/ program  /subroutine  ...something inside flirc programming that would

count number of continuous input signals and then forward every second or third to system?  

 

Sorry for my rubbish English :)  

 

  

  • Like 1

Share this post


Link to post
Share on other sites

This was a well written post, interesting findings.

 

I like the idea too, I think this is one of those things that would befit a lot of people.

Share this post


Link to post
Share on other sites

So Chris! here we meet again :) 

 

Thank you for your support.

 

One thing I forgot to write is that 

xset r rate [delay] [rate] 

 

also does not work.

 

So only alternative option would be to capture input before XBMC captures it  and try to reduce input speed there. 

For this to work one would need to know exact point where XBMC captures input ,

but if it is captured at "beginning"  of system it would be virtually impossible to do anything.

 

I really think this would be a nice feature to have.

Share this post


Link to post
Share on other sites

Even if XBMC captured it as soon as it entered the machine, it could still be done beforehand by the FLIRC, because that's the hardware that decides what exactly gets sent as inputs as keyboard commands.

 

I'm starting to wonder if all of these things that it needs to do will eventually go beyond the physical limitations of the device. Though I remember Jason saying somewhere that he's built a version2.0 of the FLIRC and will be shipping that out instead.  Otherwise all these extra functions will force the software to have to run as a service on the PC instead of within the FLIRC itself, which would open a whole new can of worms as there would need to be a service for Win, Mac, and Linux.    

 

And BTW, your English is far superior to many people that call it their first and only language.  So, props guy!

Share this post


Link to post
Share on other sites

@ Budwyzer,

 

first of all thank you for your kin words.

 

Second, I know  if flirc handles input rate it will be ok, but as you say big question here is how much of signal flooding flic can withstand.

 

We should await "arrival of creator  him self" to here/ see what he thinks of this.

Share this post


Link to post
Share on other sites

Though I remember Jason saying somewhere that he's built a version2.0 of the FLIRC and will be shipping that out instead.

Was it this:

The Powerbase: If there was one element of the FLIRC project you could change, from concept all the way to the final hardware and software, what would it be and why?

 

Jason: I would change the microprocessor. I’m using an 8 bit micro that runs at 12Mhz and it’s biggest limitation (for cost) is that it uses a soft USB stack. Everything is timing critical and because of this, one simple change to the firmware could break USB, and it does. It’s absolutely frustrating, has hindered development, and I hate it.

I would go with a low cost 32 bit ARM cortex M3 next time, and often think about changing, but the ramifications would be absolutely huge. Now, 3 years from when I started, this is actually cost feasible.

Next time, I would also write all the firmware so that it’s architecture agnostic. I would plan ahead, and make sure that I don’t put together a finely tuned piece of firmware for that particular microcontroller. I would in the future structure it in such a way, that should I want to switch to something new, it wouldn’t be an overhaul of code.

(From: http://www.thepowerbase.com/2013/03/taking-control-interview-with-flirc-creator-jason-kotzin/)

Seems like a switch wouldn't be happening anytime soon, if it does change. Only one guy know for sure though...

Share this post


Link to post
Share on other sites

I have a Raspberry Pi and I also mucked around with kbdrate and other settings to no avail. I recently found the interkey-delay setting on the flirc command line and voila! No more rapid button presses. Maybe give it a try...

Share this post


Link to post
Share on other sites

I have a Raspberry Pi and I also mucked around with kbdrate and other settings to no avail. I recently found the interkey-delay setting on the flirc command line and voila! No more rapid button presses. Maybe give it a try...

 

Thank you for your inmput, but I think  that won't help here.

 

We would like flirc to send signal to system in slower rate when you press and hold down one key, not when you are taping it.

 

I will check it out when i get home.

Share this post


Link to post
Share on other sites

Was it this:

(From: http://www.thepowerbase.com/2013/03/taking-control-interview-with-flirc-creator-jason-kotzin/)

Seems like a switch wouldn't be happening anytime soon, if it does change. Only one guy know for sure though...

Yep, it was probably that.  Unfortunately my selective hearing, which I've developed over years of marriage, has also crept into my reading thanks to texting. And so now I also have selective reading, which I can't seem to turn off.    :P

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×