New version using linuxWiimoteLib

[Pere Negre]

Ok. Finally it was not as difficult as I have feared.

Check the new code in github. Needs a little tweaking, but at least we got rid of cwiid.

-- 
Pere

[al...@paranoici.org]

At line 193 in linuxWiimoteLib.py, the string "Nintendo RVL-CNT-01-TR"
might be accepted also:


def device_discovered(self,address, device_class, name):
if name == "Nintendo RVL-CNT-01": self.found = address

might be replaced in some similar to

def device_discovered(self,address, device_class, name):
if name.startswith("Nintendo RVL-CNT-01"): self.found =
address

I have not a new wiimote but seems that it use the same protocol of the
old one


If you can patch the code and make a deb (I can also do it myself) I
could
share it with the italian mailing list "wii libera la lavagna" and make
a cooperative
testing identifying the wiimote working and not working models.


Pietro Pilolli

[al...@paranoici.org]

You can see the bug about the not working wiimotes in cwiid
at https://github.com/abstrakraft/cwiid/issues/17

Anyway I'm happy that python-whiteboard has been disacoupled by cwiid!

If anyone is interested to fix the new wiimote issues see the before
proposed patch and check the wiimote reverse engineering info on:
http://wiibrew.org/wiki/Wiimote#0x20:_Status

Pietro Pilolli

[Pere Negre]

At line 193 in linuxWiimoteLib.py, the string "Nintendo RVL-CNT-01-TR" might be accepted also:


        def device_discovered(self,address, device_class, name):
                if name == "Nintendo RVL-CNT-01": self.found = address

might be replaced in some similar to

        def device_discovered(self,address, device_class, name):
                if name.startswith("Nintendo RVL-CNT-01"): self.found = address

I have not a new wiimote but seems that it use the same protocol of the old one


If you can patch the code and make a deb (I can also do it myself) I could
share it with the italian mailing list "wii libera la lavagna" and make a cooperative
testing identifying the wiimote working and not working models.

Ok. I've fixed the line you pointed.

But bear in mind that if you read the code carefully, you will realise that that line does not get executed ever!

That's because the device discover phase happens in wiimote.py (line 84). So, when the real Wiimote object gets constructed, the hw address is already known.

Anyway, it needs more testing.

I can build the new .deb. You think it's stable enough? In my computer it works fine!

--
Pere

[al...@paranoici.org]

Hy,
I have read more about the new wiimote Nintendo RVL-CNT-01-TR
and I want share with you my info


See http://wiibrew.org/wiki/Wiimote

First of all seems that you can connect these model only with the sync
button
"The newer Wiimote RVL-CNT-01-TR shuts down immediately upon receiving
any HID output report if it has been turned on using the 1 + 2 method,
although it works using the sync button. It is possible that
authentication is now mandatory for the 1 + 2 temporary sync"

and the you can read

"The original Wiimotes (RVL-CNT-01) allowed sending commands using SET
REPORT (0x52) over the control pipe, instead of using the data pipe;
however, this form does not work on the newer RVL-CNT-01-TR, and as such
is not recommended."

I have seen that wiimoteLib.py send command with the 0x52 over the
control pipe.
Then I have tested with my old wiimote if I am able to use the data
pipe as suggested.
In this way the code might be compliant with the old and new wiimote
models.
I think to have reached my goal changing in file linuxWiimoteLib.py
(See the attached file) all the occurrences of 0x52 in 0xa2 and using
for I/O the data socket.
Then all the messages are read and send to the data pipe.

I want comment some lines of code line 134

old code:
# The data pipe 0x13 in hex 19 in dec
self.isocket.connect((self.bd_addr,19))
# The control pipe 0x11 in hex in dec
self.osocket.connect((self.bd_addr,17))

new code
# The data pipe 0x13 in hex 19 in dec
self.datasocket.connect((self.bd_addr,19))

All the messages read and written from/by sockets now use this one
socket.

and a first example at line 270 old code:

# Send a control SET REPORT (0x52) over the control pipe
self._send_data((0x52,0x11,self.setter.SetLEDs(self.WiimoteState.LEDState)))

and the new one:

# Send over the data pipe; All the output reports are prepended with
0xa2
self._send_data((0xa2,0x11,self.setter.SetLEDs(self.WiimoteState.LEDState)))

With this changes all seems work fine.

I would have feedback and testing on this issue.

Pietro Pilolli

[Pere Negre]

Works with my device too. Committing to github...

--
Pere

[al...@paranoici.org]

Hy, I have done an other little patch in order to:
- switch off all the led a part of the first one
- ramble the device

This things are done after the connection as the old code
before the linuxWiimoteLib

At line 96 in wiimote.py

def bind(self, addr):
try:
self.addr = str(addr)
self.wii = wiLib.Wiimote()
self.wii.Connect(self.addr)
self.wii.SetRumble(True)
qt.QThread.msleep(200)
self.wii.SetRumble(True)
self.wii.SetLEDs(True, False, False, False)
self.wii.activate_IR()

self.wii.setIRCallBack(self.create_wiimote_callback())
self.error = False
return

Anyway I attach the modified file

Pietro Pilolli

On 07.09.2012 17:47, Pere Negre wrote:
> Works with my device too. Committing to github...
>

> On Fri, Sep 7, 2012 at 5:20 PM, <al...@paranoici.org [2]> wrote:
>
>> Hy,
>> I have read more about the new wiimote Nintendo RVL-CNT-01-TR
>> and I want share with you my info
>>

>> See http://wiibrew.org/wiki/Wiimote [1]

[al...@paranoici.org]

Setting for sensitivity has beeen dropped and not replaced:
https://github.com/pnegre/python-whiteboard/commit/0435ec34cc5a83c79302b521b42cb28c69f4687f

I think that we might reimplement it, because it is an important
because put a lower sensitivity
can help when the sunlight disturb the wiimote whiteboard.
Could be a good choice set the wiimote cmos sensivity instead of
reimplement the old one highpass
filter.

See the "Sensitivity Settings" paragraph in
http://wiibrew.org/wiki/Wiimote

A you can see has five level that has been used usually, level 5 is the
more sensible.
Exists two extra level that are not used with the wii that put an extra
sensivity:
- Suggested by Marcan
- Suggested by inio (max sensitivity) This is now the default sensivity
level in python-whiteboard

Pietro Pilolli

[Pere Negre]

Ok. Committed.

--
Pere

[Pere Negre]

I'm looking at it. We can define a new method called "setIRSensitivity" in linuxWiimoteLib.Wiimote

I'm trying to understand how it works. You can see in activate_IR (lines 312-330) how it sets the maximum sensitivity.

The part I really can't figure out is lines 326-328. The "default" sensitivity.

--
Pere

[Pere Negre]

I've defined a new function in linuxWiimoteLib to set IR sensitivity. Take a look: https://github.com/pnegre/python-whiteboard/blob/master/stuff/linuxWiimoteLib.py (line 323).

For now, it's only called when the IR camera is initialized.

--
Pere

[Pere Negre]

Following the specifications in wiibrew, I modified the function. What do you think? It's correct now?

--
Pere

[al...@paranoici.org]

The code seems ok.
Have you done some test to see that the sensibity has changed and how?
The only one my doubt is that the Block 1 described in Sensitivity
Settings
at http://wiibrew.org/wiki/Wiimote is long 9 bytes and we set only two
byte
and it says block 1 is 0x41, and second byte of block 2 is 0x00.

Fos Level 1 we have:

02 00 00 71 01 00 64 00 fe fd 05 Wii level 1

self._write_to_mem(0x04b00008,0xfe)
time.sleep(0.1)
self._write_to_mem(0x04b0001a,0xfd05)

If I understand well I expect

self._write_to_mem(0x041,0x0200007101006400fe)
time.sleep(0.1)
self._write_to_mem(0x00,0xfd05)

But can be that I am misunderstanding. A real test could prove the
sensivity
codes.

If it is right the python-whiteboard approach might be correct yout
code also but
in any case I'm not able to much the theory exposed in doc and the
implementation

Pietro Pilolli

On 08.09.2012 12:04, Pere Negre wrote:
> I've defined a new function in linuxWiimoteLib to set IR sensitivity.
> Take a
>
> look: https://github.com/pnegre/python-whiteboard/blob/master/stuff/linuxWiimoteLib.py

> [4] (line 323).

>
> For now, it's only called when the IR camera is initialized.
>
> On Sat, Sep 8, 2012 at 11:31 AM, Pere Negre <pere....@gmail.com

> [5]>
> wrote:

>
>> On Sat, Sep 8, 2012 at 11:00 AM, <al...@paranoici.org [3]> wrote:
>>
>>> Setting for sensitivity has beeen dropped and not replaced:
>>>
>>
>
> https://github.com/pnegre/python-whiteboard/commit/0435ec34cc5a83c79302b521b42cb28c69f4687f

>>> [1]

>>>
>>> I think that we might reimplement it, because it is an important
>>> because put a lower sensitivity
>>> can help when the sunlight disturb the wiimote whiteboard.
>>> Could be a good choice set the wiimote cmos sensivity instead of
>>> reimplement the old one highpass
>>> filter.
>>>
>>> See the "Sensitivity Settings" paragraph in

>>> http://wiibrew.org/wiki/Wiimote [2]

[Pere Negre]

Check the new code.

It's already implemented and working in my machine.

To take effect, when the sensitivity slider is moved, you have to deactivate and activate again the wiimote (it's not necessary to disconnect, only to deactivate).

Maybe an "apply" button in configuration settings would be the right thing...

Test it, please.

--
Pere

[al...@paranoici.org]

> The code seems ok.
> Have you done some test to see that the sensibity has changed and
> how?
> The only one my doubt is that the Block 1 described in Sensitivity
> Settings
> at http://wiibrew.org/wiki/Wiimote is long 9 bytes and we set only
> two byte
> and it says block 1 is 0x41, and second byte of block 2 is 0x00.
>
> Fos Level 1 we have:
>
> 02 00 00 71 01 00 64 00 fe fd 05 Wii level 1
>
> self._write_to_mem(0x04b00008,0xfe)
> time.sleep(0.1)
> self._write_to_mem(0x04b0001a,0xfd05)
>
> If I understand well I expect
>
> self._write_to_mem(0x041,0x0200007101006400fe)
> time.sleep(0.1)
> self._write_to_mem(0x00,0xfd05)
>
> But can be that I am misunderstanding. A real test could prove the
> sensivity
> codes.
>

I have test you code and it seems strange first of all the code disable
the IR
and it seems a strange behaviour and then I have doubt about registry


In my opinion this code put to level one

self._write_to_mem(0x041,0x0200007101006400fe)
time.sleep(0.1)
self._write_to_mem(0x00,0xfd05)

and this one to max sensivity
self._write_to_mem(0x041,0x000000000000900041)
time.sleep(0.1)
self._write_to_mem(0x00,0x4000)

Take in mind that your code for e.g. level 1

self._write_to_mem(0x04b00000,0x0200)
time.sleep(0.1)
self._write_to_mem(0x04b00002,0x0071)
time.sleep(0.1)
self._write_to_mem(0x04b00004,0x0100)
time.sleep(0.1)
self._write_to_mem(0x04b00006,0x6400)
time.sleep(0.1)
self._write_to_mem(0x04b00008,0xfe)
time.sleep(0.1)
self._write_to_mem(0x04b0001a,0xfd05)

might be the same that
self._write_to_mem(0x04b00000,0x0200007101006400fe)
time.sleep(0.1)
self._write_to_mem(0x04b0001a,0xfd05)

I'm trying to test the code in wmgui. With this interface you can
enable IR and send rough
command in registry. You can open wmgui then Settings/IR data and then
View/Memory read and write and then write register (the codes must be
given without 0x, it is hex as default)

Now I am testing the string inside it, I hope to see differences in the
blob size or have a greater distance with
the right maxivity level settings. Please try yourself to make this
type of testing.
I think that it is more scientific that test the running whiteboard, a
lot of changes could give false impressions.

Pietro Pilolli

[al...@paranoici.org]

I have not read well the specificationa

Write Sensitivity Block 1 to registers at 0xb00000
Write Sensitivity Block 2 to registers at 0xb0001a

then level 1 could be:
self._write_to_mem(0x0b00000,0x0200007101006400fe)
time.sleep(0.1)
self._write_to_mem(0xb0001a,0xfd05)

but the phrase could get you the reason.
I expect that after the init you can change the sensivity without reset
the device

Pietro Pilolli

[al...@paranoici.org]

Your code might work also in short version


self._write_to_mem(0x04b00000,0x0200007101006400fe)
time.sleep(0.1)
self._write_to_mem(0xb04001a,0xfd05)

I have an other doubt.

See the points:

1)Enable IR Camera (Send 0x04 to Output Report 0x13)
2)Enable IR Camera 2 (Send 0x04 to Output Report 0x1a)

we have implement these with
self._send_data([0xa2]+i2bs(0x120033)) #mode IR
self._send_data([0xa2]+i2bs(0x1304))#enable transmission
self._send_data([0xa2]+i2bs(0x1a04))#enable transmission

How you can see seems that the document is not updated and that all
the direct writing on registries can be translated in command to be
sended
in the data pipe.

My question is how we can send a data command to change the sensitivity
on the fly
in similar way to.

self._send_data([0xa2]+i2bs(0x120033)) #mode IR
self._send_data([0xa2]+i2bs(0x1304))#enable transmission
self._send_data([0xa2]+i2bs(0x1a04))#enable transmission

See that we are send to write registry on data socket instead of
control socket.
I remember that PSM 0x11 is for the control pipe and is for PSM 0x13
for the data pipe.

Pietro Pilolli

[Pere Negre]

On Sat, Sep 8, 2012 at 2:12 PM, <al...@paranoici.org> wrote:

Your code might work also in short version


                 self._write_to_mem(0x04b00000,0x0200007101006400fe)
                 time.sleep(0.1)
                 self._write_to_mem(0xb04001a,0xfd05)

Ok. Code updated. 

 

I have an other doubt.

See the points:

1)Enable IR Camera (Send 0x04 to Output Report 0x13)
2)Enable IR Camera 2 (Send 0x04 to Output Report 0x1a)

we have implement these with
                self._send_data([0xa2]+i2bs(0x120033)) #mode IR
                self._send_data([0xa2]+i2bs(0x1304))#enable transmission
                self._send_data([0xa2]+i2bs(0x1a04))#enable transmission

How you can see seems that the document is not updated and that all
the direct writing on registries can be translated in command to be sended
in the data pipe.

My question is how we can send a data command to change the sensitivity on the fly
in similar way to.

                self._send_data([0xa2]+i2bs(0x120033)) #mode IR
                self._send_data([0xa2]+i2bs(0x1304))#enable transmission
                self._send_data([0xa2]+i2bs(0x1a04))#enable transmission

See that we are send to write registry on data socket instead of control socket.
I remember that PSM 0x11 is for the control pipe and is for PSM 0x13 for the data pipe.

Pietro Pilolli

I'm looking into it. 

--
Pere

[al...@paranoici.org]

On 08.09.2012 15:49, Pere Negre wrote:

> On Sat, Sep 8, 2012 at 2:12 PM, <al...@paranoici.org [1]> wrote:
>
>> Your code might work also in short version
>>
>>                
>>  self._write_to_mem(0x04b00000,0x0200007101006400fe)
>>                  time.sleep(0.1)
>>                  self._write_to_mem(0xb04001a,0xfd05)
>
> Ok. Code updated. 
>
>  
>
>> I have an other doubt.
>>
>> See the points:
>>
>> 1)Enable IR Camera (Send 0x04 to Output Report 0x13)
>> 2)Enable IR Camera 2 (Send 0x04 to Output Report 0x1a)
>>
>> we have implement these with
>>                 self._send_data([0xa2]+i2bs(0x120033))
>> #mode IR
>>                 self._send_data([0xa2]+i2bs(0x1304))#enable
>> transmission
>>                 self._send_data([0xa2]+i2bs(0x1a04))#enable
>> transmission
>>
>> How you can see seems that the document is not updated and that all
>> the direct writing on registries can be translated in command to be
>> sended
>> in the data pipe.
>>

The doubt was a my delirium write_to_mem append to begin [0xa2,0x16]
and calculates correctly the size. Then seems that the code is 100%
correct
using the data pipe.

The only little suggestion that I have is externalize the 0xa2; in this
way if
we want change in the old 0x52 we can change or select the right vae
easly.

[al...@paranoici.org]

On 08.09.2012 18:05, al...@paranoici.org wrote:
> On 08.09.2012 15:49, Pere Negre wrote:
>> On Sat, Sep 8, 2012 at 2:12 PM, <al...@paranoici.org [1]> wrote:
>>
>>> Your code might work also in short version
>>>
>>>                
>>>  self._write_to_mem(0x04b00000,0x0200007101006400fe)
>>>                  time.sleep(0.1)
>>>                  self._write_to_mem(0xb04001a,0xfd05)
>>
>> Ok. Code updated. 
>>

Is possible the code in order to activate the infared automatically
after that the sensivity
has beeen changed?

Pietro Pilolli

[Pere Negre]

I'm making some tests calling self.wii.wii.setIRSensitivity(val) directly in sliderIRMoved (in configuration.py).

But it freezes the cursor sometime... It needs more experimentation.

--
Pere

[Pere Negre]

I've uploaded the new version (seems stable right now). It will be easier to test for most users.

https://github.com/pnegre/python-whiteboard/downloads

--
Pere

[al...@paranoici.org]

I have a partial test of new python-whiteboard with
a new generation wiimote plus
(a my penfriend has tested only the connection, the ramble and the
battery status monitor,
calibration and all the features will be test the next days)

In order to fix it; I have added these lines at line 116

self.controlsocket =
bluetooth.BluetoothSocket(bluetooth.L2CAP)
self.controlsocket.connect((self.bd_addr,17))

before of

self.datasocket =
bluetooth.BluetoothSocket(bluetooth.L2CAP)
self.datasocket.connect((self.bd_addr,19))

If I open directly the datasocket on 19 the wiimote refuse the connect

Anyway the controlsocket receive some info about the wiimote status but
I think that
there are not important.

At
http://wiibrew.org/wiki/Wiimote
you can read
"the control pipe is essentially unused"

But I don't know if it is true could be the case to try to make a read
on the pipe and see
wich kind of report it sends (if it exists)

Anyway please add the two lines of code that I have sent,
without these lines the wiimote plus is not able to connect!

Pietro Pilolli

[Pere Negre]

Ok. Code added to the repository. Thanks.

--
Pere

[al...@paranoici.org]

I member of wii libera la lavagna mailing list has test with
me the program with wiimote plus ant it's work.

An other guy report that when the calibration window appears,
it see the calibration point but when it switch-on the pen
the circle are not filled with the red color.
Anyway he is able to complete the calibration successfull.

Have you got some idea about this strange misbehaviour?
It seems that the calibration window is not updated or that
the circle red drawing has done out of screen

Sorry for the imprecise bug report but it is a translation from italian
and I have not furthermore info because I am not able to reproduce his
bug.

May be caused by the setVisible in calibration.py

Pietro Pilolli

[Pere Negre]

An other guy report that when the calibration window appears,
it see the calibration point but when it switch-on the pen
the circle are not filled with the red color.
Anyway he is able to complete the calibration successfull.

Have you got some idea about this strange misbehaviour?
It seems that the calibration window is not updated or that
the circle red drawing has done out of screen

Ummm... What linux distribution is he/she using? what desktop environment (kde, gnome, enlightment...)

In the past, I observed some strange behaviour with the compiz effects enabled on GNOME boxes. Can he/she provide more information?

--
Pere

[al...@paranoici.org]

Sorry I have not specified that the guy that is not able to see the red
circle
filled uses a wiimote plus.

Is it possible that the new device is faster than the old one and that
the old code
has modded inside to draw the calibration point with red incrementally
after a timeslice (t) and it exit after
fixed number of detected dots (dotnumeber).
If are collected dotnumber in a timeslice minor then t than we could
have the suspected bug.

I think that the calibration window might have all the logic based on
detected light dots.
Encreasing the detected dots the calibration point will be filled with
red.

Pietro Pilolli

[al...@paranoici.org]

Sincerly he uses wiildOs that it is the distro that I'am using also.
It is the distro made my self and it uses lxde + openboex + xcompgr
and on this environment I have never seen this problem and
also other teacher have not never get this type of problem.

I retell you, could be that it is some hard coded assumption about the
device fastness,
sensitivity or something like this?

Pietro Pilolli

[Pere Negre]

Sincerly he uses wiildOs that it is the distro that I'am using also.
It is the distro made my self and it uses lxde + openboex +  xcompgr
and on this environment I have never seen this problem and
also other teacher have not never get this type of problem.

I retell you, could be that it is some hard coded assumption about the device fastness,
sensitivity or something like this?

Yeah, maybe. If the wiimote plus is throwing data at a faster rate than the wiimote, it can overflow the number of hardcoded "cycles". See lines 52-68 in calibration.py

That part of the code is a bit ugly and it needs some cleanup. I'll look into it. Maybe I can fix it.

It's strange that that problem happened only to him.

--
Pere

[Pere Negre]

Ok. Try this patch. I've limited the refresh rate of the pointer in calibration screen.

--
Pere

[al...@paranoici.org]

I'm quite sure that the problem is at line 65 infact if I decrease this
number I have the same
behavior that has described my collegue with wiimote plus.

Now the real point is; Is it right base the calibration on a maximum
point? Could be.
Could be better say that if the user click in a stricted arount for 4
seconds the calibrartion point is valid?
Could be better also (in this way we have the assurance that a user
could finish the calibration in few seconds)

An other question for curiosity? Do you really use the various
coordinates of each calibration point in order to fix some rumors
or you make a sort of coordinate average that it is the more roundable
point?

Anyway I think that the hand and the pen has some noise and then could
be that the smoothing could be sufficient and the calibration
could be more or less precise without have a so worst result

Pietro Pilolli

[Pere Negre]

See the patch that I sent you a moment ago. It limits the rate of the updates in the wiimote callback function. That should fix the problem.

Now the real point is; Is it right base the calibration on a maximum point? Could be.
Could be better say that if the user click in a stricted arount for 4 seconds the calibrartion point is valid?
Could be better also (in this way we have the assurance that a user could finish the calibration in few seconds)

Yes. I think you're right. It needs some fixing and cleanup. See if the fix works and I'll see if I have time this week I'll work on this. 

An other question for curiosity? Do you really use the various coordinates of each calibration point in order to fix some rumors
or you make a sort of coordinate average that it is the more roundable point?

No, it does not calculate a average coordinate (for now). It simply uses the last value in the buffer.

--
Pere