RC5 PC remote control through USB ??
Thu Dec 20 2007, 08:10 pm
weeeeeww... That last post made it a lot clearer thx..
another thing, this is UART transmission right ? (between 8051 and VB)
if so, how many bits are we transmitting, 8 or 9 ?
as a last question for today , '#30H' is 30 in Hex right? u didnt use the standard RC5 commands ..
another thing, this is UART transmission right ? (between 8051 and VB)
if so, how many bits are we transmitting, 8 or 9 ?
as a last question for today , '#30H' is 30 in Hex right? u didnt use the standard RC5 commands ..
Thu Dec 20 2007, 11:53 pm
yes transmission is between VB and 8051 and its only 8 bit
30H is 0x30 or 30 hex. i read the standard commands but i send back the normal digits.. coz its easy to debug using a simple hyper terminal
30H is 0x30 or 30 hex. i read the standard commands but i send back the normal digits.. coz its easy to debug using a simple hyper terminal
Sun Dec 23 2007, 08:28 pm
whenever you change the mode from WMP to Mouse or Mouse to WMP control, mode bit is changed and VB software is informed about the changed mode.
I dont quite get that, you mean one of the 8 bits sent, informs the vb abt the mode status? Or is it just that the vb starts off with a certain mode initially, and toggles it everytime the user presses 0 ? ( cause that's how i understood it )
Another thing i do not understand in the code, in the mouse routine...
mskip2: cjne a,#03H,mskip3 acall chk_valid jb VALID,ok2 ret ok2: mov a,#33H acall tx ret
What does the chk_valid do? and why it is only for a few commands of the mouse routine ?
mskip6: cjne a,#26H,mskip7 mov a,#37H acall tx ret
also in the mouse routine, why are you expecting a 26hex , since it's the 7 button?:-/
Mon Dec 24 2007, 01:08 am
whenever you change the mode from WMP to Mouse or Mouse to WMP control, mode bit is changed and VB software is informed about the changed mode.
I dont quite get that, you mean one of the 8 bits sent, informs the vb abt the mode status? Or is it just that the vb starts off with a certain mode initially, and toggles it everytime the user presses 0 ? ( cause that's how i understood it )Milz
Yest it starts with mouse mode initially.. and toggles it after pressing power key. when power key is pressed controller send 0 and then software replies back with mode.. if software send 'm' that means its in mouse mode.. so mode bit is toggled and controller switches to keyboard mode.
Another thing i do not understand in the code, in the mouse routine...
mskip2: cjne a,#03H,mskip3 acall chk_valid jb VALID,ok2 ret ok2: mov a,#33H acall tx ret
What does the chk_valid do? and why it is only for a few commands of the mouse routine ?Milz
As i already said.. for navigation keys like Up, Down, Left, Right Toggle bit is not checked.. but for others like left click and right click toggle key is checked. So for only few commands this routine is used.
mskip6: cjne a,#26H,mskip7 mov a,#37H acall tx ret
also in the mouse routine, why are you expecting a 26hex , since it's the 7 button?Milz
well.. this is a different story you will see an extra piece of code added for 26H and 38H the reason was.. i was not having volume+/- keys on my test remote.. as it was a custom made... so i used those keys for same operation of Vol+/- you can remove that code if you want.. it was only for my convenience did not bother to remove it.. coz it wont harm anyone
Milz like this.
Mon Dec 24 2007, 07:51 am
Ajay rocks ! hehe
ok might sound stupid, but i had no idea vb sends back to the controller .. ! :-|
from the few things i understood from the 8051 code, i didnt see any rx routine!
.. or i didnt get you ... that's an option too
Yest it starts with mouse mode initially.. and toggles it after pressing power key. when power key is pressed controller send 0 and then software replies back with mode.. if software send 'm' that means its in mouse mode.. so mode bit is toggled and controller switches to keyboard mode.
ok might sound stupid, but i had no idea vb sends back to the controller .. ! :-|
from the few things i understood from the 8051 code, i didnt see any rx routine!
.. or i didnt get you ... that's an option too
Mon Dec 24 2007, 11:24 am
check in the Timer1_timer sub
after checking the Mode variable.. i send 'x' or 'm'. this is how it work..
Case &H30 If Mode Then MSComm1.Output = Chr(Asc("m")) Mode = False StatusLog.SelText = vbCrLf & "0 Received, Mouse Mode" Else MSComm1.Output = Chr(Asc("x")) Mode = True StatusLog.SelText = vbCrLf & "0 Received, Keyboard Mode" End If
after checking the Mode variable.. i send 'x' or 'm'. this is how it work..
Tue Dec 25 2007, 11:44 pm
keyboard: ;Routine for Keyboard operation mov a,TEMP cjne a,CMD,k_valid1 ret
As soon as you enter keyboard mode, you're checking if the command is the same as the previous command and if they are you're disregarding the command ... Ok but what if the user presses two 'Next' button twice in a row, but with an acceptable delay between the two .. will the program disregard the 2nd click ?
Wed Dec 26 2007, 12:48 am
it will accept.. i know your confusion.. because even i was confused when i coded it.. and believe me it works.. maybe the data reception is way too fast..
also sometimes.. you get error in sending commands.. reason for error is.. after reception of first bit.. we give delay with a wild guess that next bit might come at this place.. even a small mistake will make big difference.. even if no data is coming.. sometimes a flicker in ambient light cause circuit to get activate. Try it in sun you will get to know.. it just one example of error... there are many other possibilities like the way you handle the remote.. direction and angle.. etc... I tested the whole thing with almost all possibilities.. well you will understand when you use it... or make it from scratch
also sometimes.. you get error in sending commands.. reason for error is.. after reception of first bit.. we give delay with a wild guess that next bit might come at this place.. even a small mistake will make big difference.. even if no data is coming.. sometimes a flicker in ambient light cause circuit to get activate. Try it in sun you will get to know.. it just one example of error... there are many other possibilities like the way you handle the remote.. direction and angle.. etc... I tested the whole thing with almost all possibilities.. well you will understand when you use it... or make it from scratch
Thu Jan 03 2008, 03:10 am
Hello again Ajay! happy new year to every1..
Ok so im finally trying out my pic , and while trying as a first step to simply test the decoding part, where the pic should output the command bits on Port D through LEDS .. It did Not work.. But what really is blowing my mind, is that it works perfectly well when i tried the code on Proteus !
So im just wondering , what could be the problem , if it works on Proteus, but not on hardware?
P.S: When i click on my remote, it simply gives me random bits everytime... nothing close to the command i clicked on, even if i click the same button twice! :mad
Ok so im finally trying out my pic , and while trying as a first step to simply test the decoding part, where the pic should output the command bits on Port D through LEDS .. It did Not work.. But what really is blowing my mind, is that it works perfectly well when i tried the code on Proteus !
So im just wondering , what could be the problem , if it works on Proteus, but not on hardware?
P.S: When i click on my remote, it simply gives me random bits everytime... nothing close to the command i clicked on, even if i click the same button twice! :mad
Thu Jan 03 2008, 03:25 am
PROTEUS?? how did u simulate there???
and.. there is surely delay problem.. the timings are not correct..
even thought the theoretical values say about the timings..
but.. in reality.. there is sometimes a lot of difference.. try to decrease the delay.. slowly.. till you get right bits.. only way to get it working is testing on hardware..
it took me 7 days for perfect decoding..
also.. once you finish with your code.. i will add ur PIC code in my library will be useful.. so test test test..
and.. there is surely delay problem.. the timings are not correct..
even thought the theoretical values say about the timings..
but.. in reality.. there is sometimes a lot of difference.. try to decrease the delay.. slowly.. till you get right bits.. only way to get it working is testing on hardware..
it took me 7 days for perfect decoding..
also.. once you finish with your code.. i will add ur PIC code in my library will be useful.. so test test test..
Powered by e107 Forum System