It has been discussed before in http://www.meedio.com/forum/viewtopic.p ... highlight= and http://www.meedio.com/forum/viewtopic.p ... 117#134117, and been established that it takes about 400 ms for the USB-UIRT to transmit a code.
For volume control, it is far too long. It takes too many seconds to change the volume to a desired level.
Is it a plugin issue, or a unit issue? In other words, can *you* fix it, or should I contact Jon from USB-UIRT to try and fix it?
Thanks,
Yoram
USB-UIRT transmit time
Yoram,
I'm really not sure what the problem is, so I'm not really in a position to fix it. I'd suggest contacting Jon and seeing what he says about it. It would be interesting to see if the same timing is experienced with other software too.
I'm sure the length of the Pronto code will also have an effect on the time it takes to send it.
I'm really not sure what the problem is, so I'm not really in a position to fix it. I'd suggest contacting Jon and seeing what he says about it. It would be interesting to see if the same timing is experienced with other software too.
I'm sure the length of the Pronto code will also have an effect on the time it takes to send it.
Scott
-
yaccri
- HouseBot Special Member
- Posts: 304
- Joined: Wed May 07, 2003 2:19 pm
- Location: Tel-Aviv, Israel
- Contact:
This is how my receiver works, and I guess that most if not all other similar devices work:
When holding down the remote's VOL button, the receiver's display shows that the first change takes about 1/2 a second, and after that it accelerates (or at least changes very fast). For example if the receiver's volume is -50Db, it takes about 1/2 a second to get to -50.5DB, and another 1/2 a second to get to -60.0 Db.
Jon from USB-UIRT compared this behavior to the 'repeat' PC keyboard behavior.
So the core of the problem is that the first transmission takes a LOT longer than the repeated transmitions.
I also did this test: I created a VB script that repeatedly transmits the VOL IR code 20 times. It took about 9 seconds. Then, I changed the 'repeat' of the USB-UIRT from 1 to 20 and tested it. This test took less than 3 seconds. Also, whereas running the script caused the USB-UIRT led to blink, in the 'repeat' test the led was 'on' for the transmission time.
So Scott, this might be challenging (or maybe even impossible) to optimize. The ideal behavior would be to simulate the the remote's behavior. That is, when pressing a button, the USB-UIRT will transmit the code. If after _ ms the button is still pressed, it will repeat transmitting, and stop transmitting when the button is released.
I suppose that new button functionality is needed to perform this. Maybe a task button that will run a task when a button is pressed, and stop it when the button is released. Also, since there was a big difference between the two tests above, it may be worth to try to accelerate the continuous transmissions.
I'm surprised that this issue got little attention in the forum. Every HB user who tried to control volume should have encouner this issue.
Scott, do you have another brilliant solution?
Thanks,
Yoram
When holding down the remote's VOL button, the receiver's display shows that the first change takes about 1/2 a second, and after that it accelerates (or at least changes very fast). For example if the receiver's volume is -50Db, it takes about 1/2 a second to get to -50.5DB, and another 1/2 a second to get to -60.0 Db.
Jon from USB-UIRT compared this behavior to the 'repeat' PC keyboard behavior.
So the core of the problem is that the first transmission takes a LOT longer than the repeated transmitions.
I also did this test: I created a VB script that repeatedly transmits the VOL IR code 20 times. It took about 9 seconds. Then, I changed the 'repeat' of the USB-UIRT from 1 to 20 and tested it. This test took less than 3 seconds. Also, whereas running the script caused the USB-UIRT led to blink, in the 'repeat' test the led was 'on' for the transmission time.
So Scott, this might be challenging (or maybe even impossible) to optimize. The ideal behavior would be to simulate the the remote's behavior. That is, when pressing a button, the USB-UIRT will transmit the code. If after _ ms the button is still pressed, it will repeat transmitting, and stop transmitting when the button is released.
I suppose that new button functionality is needed to perform this. Maybe a task button that will run a task when a button is pressed, and stop it when the button is released. Also, since there was a big difference between the two tests above, it may be worth to try to accelerate the continuous transmissions.
I'm surprised that this issue got little attention in the forum. Every HB user who tried to control volume should have encouner this issue.
Scott, do you have another brilliant solution?
Thanks,
Yoram
Yoram,
Some IR codes (for things like volume) actually contain two different codes. One is sent on the first press, the other is sent when you hold the button down. You can read more about this on page two of this most excellent article.
The USB UIRT API call that actually sends the IR code allows me to specify the 'repeat count'. I assume that the call will first send the standard IR burst and then if the code has a "repeat" burst, it will send that for the remaining count. From hearing the results of your VB experiment, it sounds like that is just what is happening.
The problem isn't so much that a Theme button in HouseBot can't send a stream of commands as it is the Hardware Interface is really unable to send a sustained burst of unknown length. For example, when the API is called to send the IR code it must contain the number of repeats to also send. The number of repeats really isn't known at that time, as it depends on how long the user would hold the button down (in the future).
The only way I can imagine that this could work would be if the API also provided a 'stop/cancel' send API. Then I could call the send API with a large number of repeats specified. Then send the 'stop' API when the user released the button. However, even if the API did support this, the IR sending model of HouseBot doesn't.
Some IR codes (for things like volume) actually contain two different codes. One is sent on the first press, the other is sent when you hold the button down. You can read more about this on page two of this most excellent article.
The USB UIRT API call that actually sends the IR code allows me to specify the 'repeat count'. I assume that the call will first send the standard IR burst and then if the code has a "repeat" burst, it will send that for the remaining count. From hearing the results of your VB experiment, it sounds like that is just what is happening.
The problem isn't so much that a Theme button in HouseBot can't send a stream of commands as it is the Hardware Interface is really unable to send a sustained burst of unknown length. For example, when the API is called to send the IR code it must contain the number of repeats to also send. The number of repeats really isn't known at that time, as it depends on how long the user would hold the button down (in the future).
The only way I can imagine that this could work would be if the API also provided a 'stop/cancel' send API. Then I could call the send API with a large number of repeats specified. Then send the 'stop' API when the user released the button. However, even if the API did support this, the IR sending model of HouseBot doesn't.
Scott
-
yaccri
- HouseBot Special Member
- Posts: 304
- Joined: Wed May 07, 2003 2:19 pm
- Location: Tel-Aviv, Israel
- Contact:
Scott,
The article you mentioned is great! Thanks.
Thank you for the detailed response. I didn't realize it is so complicated!
Since I had put all my IR controlled devices in the living rooms' closet, this issue became more significant.
I'll give another try with Jon, presenting your ideas.
Thanks,
Yoram
The article you mentioned is great! Thanks.
Thank you for the detailed response. I didn't realize it is so complicated!
Since I had put all my IR controlled devices in the living rooms' closet, this issue became more significant.
I'll give another try with Jon, presenting your ideas.
Thanks,
Yoram
-
yaccri
- HouseBot Special Member
- Posts: 304
- Joined: Wed May 07, 2003 2:19 pm
- Location: Tel-Aviv, Israel
- Contact:
Scott,
Jon's reply to the subject is:
Would you consider supporting that function?
I'll be happy to test it.
Thanks,
Yoram
Jon's reply to the subject is:
The API actually does support this. If a repeatCount of 32767 is passed into the TransmitIR() function, the IR code will be continuously transmitted until another TransmitIR() call is made with a 0 for the repeatCount. This is known as ‘streaming support’ in the USB-UIRT.
-Jon
Would you consider supporting that function?
I'll be happy to test it.
Thanks,
Yoram
Ahhh. I was kinda wondering if something like that would work.
The trick for implementing this would be to figure out a way to do it generically. Since the IR codes are being sent from HouseBot, it can't really do UIRT specific calls. Therefore it would possibly involve an architectural change to the way IR codes are managed in the server (I haven't really given this any thought, so I'm not really sure what the solutions could be). If I find a spare moment (not many these days), I'll give it some more thought.
I think it's a good idea, and it certainly would benefit all users.
At this point, you will need to submit a feature request to Meedio for any new development ideas. I'm really out of the loop for any new development now.
The trick for implementing this would be to figure out a way to do it generically. Since the IR codes are being sent from HouseBot, it can't really do UIRT specific calls. Therefore it would possibly involve an architectural change to the way IR codes are managed in the server (I haven't really given this any thought, so I'm not really sure what the solutions could be). If I find a spare moment (not many these days), I'll give it some more thought.
I think it's a good idea, and it certainly would benefit all users.
At this point, you will need to submit a feature request to Meedio for any new development ideas. I'm really out of the loop for any new development now.
Scott