liquid... fantastic comments there, and I don't think cherry could have answered for the both of us better there :)
I like the idea of exec NEXT etc as it would allow a very quick solution, and though I think of it as a hack, if it works.. .who cares!
cherrybomb, I'll post my java code here tommorow (after I do some cleaning) and I'm sure you'll understand it all the same (after all, c# was mostly copied from java :))
inh... keep saving those pennies.. by the time you're done you'll have a working device :)
buying one in a few hours when my patcheck hits the bank so :p
Cool, I look forward to looking at the code. I'll be honest that I wasn't real clear on the table you presented in your post above, but I'm sure the code will make sense. :-)
Originally Posted by sama
I don't know anything about coding, but the table looks to me like each axis outputs it's co-ordinances at a specific spot in the string, & each axis has a value that varies from 0 to 255, so I guess if everything is dead center the string would be either all 127's or all 128's... there is no actual center, as it would be 127.5....
I could be totally wrong though, but that's what it looks like to me:)
I'm really not trying to help, as I know nothing about this, just curious if my understanding is correct?
i wouldn't really look at it as a hack persay, i mean the Exec.exe was created specifically for this purpose by guino. Its super lightweight and fast too, in practice using it equal to actually clicking a button in Road Runner, no lag at all.
Originally Posted by sama
cant wait to see some pics of someone integrating this in there console.
@turbocar & cherrybomb
I guess some more explanation is in order!
Turbo, that was a good and close guess!
I've copied some stuff from the top here to make it easier to see.
      
1 8 0 161 255 251 255
      
2 245 255 0 0 238 255
      
3 2 0 0 0 0 0
The 0'th element is the data descriptor, whcih describes the rest of the data. The data is actually interleaved.
So when the id is 1, the elements are:
1&2 are for pan left/right
3&4 for pan fwd/back
and when the id is 2
1&2 tilt fwd/back
3&4 tilt left/right
5&6 twist left/right
and when the id is 3
the second element is either 1, 2 or 3 to repspecively indicate left button, right button, or both.
Now we can see that each axis is described by two values. The first always gives the value, and the second gives the sign (+/-)
So taking an example from the table:
this means the value for the axis is extracted from element 1 (0-255).
pan left/right axis
value from 1
right: 2 = 0
left : 2 = 255
if going right, then element 2, which is the sign would be 0, and if going left, element 2 would be 255.
Finally, if the sign is 0, the the value would increase from 0-255. If the sign is 255, then the value would decrease from 255-0.
And now for the problem I've found :(. I've noticed that pushing beyond 255, actually starts the value again! It gets to 255, then starts at 0 again (the other way if the sign value is 255). It's like it has two lungs!
And the peculiar thing is, there are 7 bytes that come back, and the bytes do not change at all to indicate that the axis is on it's "second lung". I'm going to look deeper, and see perhaps if I'm missing anything, which I hope is the case. Otherwise, the only other thing I can think of is to keep track of climbs and falls (per axis) and to detect "second lungs" based on climbs and falls. This will be difficult since if you let go of the knob, it will return to 0 in a flash and probably bounce a bit too. It's a dirty solution basically and I can't imagine this is how they've done it.
I think I'll take this chance to finally learn C#. I'll get Visual Studio installed on here ASAP
Ah, I didn't know that Exec was specific to RR. That sounds like a really good solution and would make things a lot easier to code. I guess Exec is a small bit of code that fires off a COM message and terminates.
ok, that was a false alarm. After looking again, it seems that the "sign" value not only switches between 0 and 255, but it also goes to 254 and to 1 (to indicate second lung).
This means that the actual range of the device is more than +/- 255. I expected to see it go to The max I've seen it get to on the "second lung" (that term is just too catchy to stop using!) is 190. So that's a total range of +/- 445.
At the moment, I've got code that checks for 255/254/0/1 etc, and act accordingly. However this is not the way to do it. It seems that this is not an 8 bit number after all, but actually a 10-bit, which is odd!
Using some bitwise operations, I think a much more elegant solution can be obtained. I'm having to go back to my elementary s/w engineering notes (5 years old, but still have them :))
Since we have 2 x 8 bit numbers, I'm thinking somethign along these lines:
The value for each axis in each direction ranges from:
and the "sign"/second lung figure is one of these four:
if we take just the last two bits from the sign:
and append that to the first 8 bits, to get a 10 bit number, then we look at the values, this would make things a much much more efficient, perofrmance and code wise. To test the theory, here are some values to see how it would work:
using 00000111 for the value (7), then we should be able to get the following figures.
0000000111 = 7
0100000111 = 263
1000000111 = -7 (if the first bit is read as a sign)
1100000111 = -263 (if the first bit is read as a sign)
and at this stage, we can check the MSB (most significant bit, far left) and that tells us the sign, then we shift everything to the left, and we'll have a value which we can multiply by -1 based on the MSB.
ok, I was on my lunch break and it just hit me! It's a lot easier than I thought...
the number coming back is not an 8 bit, nor is it a 10 bit. It's 16bit! and we don't need to do anything to it. just need to read it as a 16 bit short integer!
assume the sign byte is 254 and the value byte is 0. We know that 254 means the second-lung and negative. So this should be -255
now we create a short (initialised to 0)
0000 0000 0000 0000
assign the first number (the one that is 0, 1, 254 or 255 - 254 is used as an example):
0000 0000 1111 1110
shift it by 8 bits to the left
1111 1110 0000 0000
do a bitwise xorOR (EDIT:xor would be totally wrong!) with the value (assume 1)
Bob's your uncle! :)
1111 1110 0000 0000
1111 1110 0000 0001 = -255 (assuming singed short)
I think your a rocket scientist:D
I wish I could help here... when you mentioned the second lung, the first thought I had was limiting the travel..... I mean we have way more resolution than we need already, so that might have been a possibility I thought... now I guess that's not an issue though...
hehe, I love decoding what someone else has done stuff. I once decoded the Lego Mindstorms brick, but I was paid to do that one :D
Would have been a good idea about limiting the travel, though when you see the device you'll think twice about that! It's one of those "sealed shut and I don't think i have the balls to dismantle it'cos it'll break" devices :) I mean seriously, it looks like you have to crack something to find out how it opens up. And it's just too damn nice and compact and sleek to scratch etc.