Silitek SM-1000 remote control

[Ron]

Are you using the X10 driver?

-Ron

[Ron]

I'm sorry i was mixed up, I have updated the silitek plugin and it should now work again.

Please download it from the download section of the Girder page.

-Ron

[Ron]

I've sent Erik an email with your
question.

Ron

[dannej]

Hi,

I've been trying to setup Girder to work with my Netshooter remote control (Silitek SM-1000) for a while now, but it doesn't seem to work. The remote works fine with the original software, and also the utility Remote Selector. In the latter program, I've been using com port number 2. When just selecting com2 in the Silitek plugin and trying it out, it tells me that it "Cannot read 1st char" (I've tried com2 too). So, I tried skipping the "init check" which makes it initialize perfectly. The led on the receiver even blinks when I press a button. However, Girder doesn't seem to receive any IR code(s). I've also tried changing com port speed, flow control and options in the Silitek plugin. The strange thing is, a couple of months ago I got it to react on button presses, but since the signal seemed to change for every press (on the same button), I gave up. I decided to give it a shot again though, since it seems to be the program that could suit my needs.
All help is appreciated.

- Daniel.


[Edited by dannej on 02-04-2001 at 11:53 AM GMT]

[dannej]

The X10 driver/plugin for Girder or the remote itself, such as Windows drivers?
None. Haven't installed any drivers for the remote at all in Windows, and the only hardware plugin I'm using for Girder is the Silitek one.

- Daniel

[dannej]

Thanks for your help Ron, it got Girder "noticing" the remote control presses. However, my previous problem is still present. It seems that the code the remote sends to Girder changes for every press. It looks as if there are two codes for every button, and Girder seems to pick a random one. I just tried the "1" button, and the code it chooses first is "FEDE72", and then "C1FE72". Watching the line where the code is displayed I also see that when pressing and holding the "1" button, lots of different codes are shown, with an interval of a couple of MS's. Do all remotes behave this way? I've tried setting anti-repeat and also a couple of different options in the Silitek plugin. There are 3 options in the plugin, BTW, that seem to be related, and that's the "Message for key up", "Message for key down" and "Message for key still pressed". How do I find these numbers? (Default is 0)

Thanks once again for all your help.
- Daniel

[Erik]

Hi everybody !

I am sorry to reply only now.
I also have problems with my silitek plugin : as a matter of fact, I built this plugin under Win NT 4, and I compiled it on this platform. I used this plugin on this platform without any bug, it was working properly. But when I tried to use it on Windows 98, it did not work. My problem is that I can't compile my plugin on Windows 98 and debug it. I don't know why it does not work, I checked and checked again and I did not find any error. I will try to find Visual C++ in order to install it at home on Windows 98 and debug my plugin but if someone had Visual C++ on a Windows 98 platform, he could try to debug it and help me :-). Thanx a lot for your help,

Regards

Erik Damiano

[Henrik]

Hi!!

I´m just curious how it´s going with the Silitek driver??

// Henrik, Sweden

[nhuillard]

I'm experiencing the exact same problem with the Silitek driver ("cant read 1st char" when initializing, and different code on each button press). I'm using W98SR2.
I have also tested PC Remote Control, which have (the main app AND the test app) the same problem using the Silitek remote : button presses don't seem to be constant.
Steven Blackburn has documented the béhaviour of the remote control : http://www.ecs.soton.ac.uk/~sgb97r/remote/index.html and http://www.ecs.soton.ac.uk/~sgb97r/remote/silitek.html
He noticed many little thing (parity is important, etc).
Another question : does the Silitek plug-in produces clean mouse movements with the Silitek I-point on the remote ? SB have the clue for using it, if it's not present in the plug-in.

NH

[Ionsurge]

I was initially having trouble with the remote returning different codes after button presses. I'm using windows XP so my solution may or may not help, plus this is only my second day using the program.
Using the com port settings from this address:
http://www.ecs.soton.ac.uk/~sgb97r/remote/silitek.html
I manually configured the comport on my computer. Go into hardware manager, and click on the properties for your comport and select the settings tab. I could initially set everything as per the website, except for the speed, as the closest choices were 9600 and 2400. However I disabled the FIFO Buffers completely in the advanced properties dialog, and went back to the settings window and was able to set the baud rate to 1200.
As a note, I was able to select 1200 in the silitek plugin, but I think the problem was that my comport could not adjust to this speed, until I fixed it as above. Especially since above is all I changed to get it working.
My plugin settings are speed:1200, bit #:8, stop bit 1, dtr, fast silitek init, skip silitek init check, Strip Zeros from Stilitek String
Hope this helps,

[Homer]

Thanks for the info on how to initially setup the Silitek RC.

But I am having trouble with my Silitek Remote Controll joystick.

I get the same Event String for every movement. (i.e. up/down, left/right)
I am trying to controll mouse movement with the small joystick on the remote but this error is preventing any such thing.

All the other buttons work fine.

I have Win XP with Girder 3.2

Can anybody help?

[Tesargo]

Homer:

I am using Win XP and all bottons on the remote SM-1000 works fine for me also.

I can use the joystick device and I get unique codes even from the joystick device.

The tricky part is to get the codes for the larger movements of the joystick. To enter these you have to edit the XML settings file by hand. (This is not true, I am not as newbee now as when I wrote this message.)

The thing that doesn't work fine with the joystick is that it is sending the code words with a shorter delay than the buttons. This makes the joystick to bahave slowly when releasing the joystick.

Anyway, I sent a message about this to Erik Damiano.

//Anders

[Tesargo]

To post more information concerning the Silitek SM-1000.

The plugin I used before (the Silitek plug-in from Erik Damiano) queued up the messages from the joystick device. The result of this was that the mouse pointer kept moving eventough the joystick had been released.

Anyway, I have tested a better solution, the "Generic serial support"- plug-in. It took a while before I configured it correctly.

Here is the configuration that works perfect:
Generic serial support - plugin
Parity: None
Word size: 8 bytes
Stop bits: 1
Handshaking: DTR/RTS power
Baud rate: 1200

Message definitions - Receive settings
Character events: Enabled
Fixed length: 3 characters
Enable receive timeout 200 ms
Translate bin -> hex: checked
Message buffer size: 30
Suppress error messages: checked

To get the joystick device to control the mouse pointer I have written a LUA script using the WinLUAEx- plugin.

This way of controlling the mouse pointer works, but when Girder is in the background the events are not evaluated fast enough for a smooth operation. I don't know how to make this faster, but it works well when the Girder window is the forgroundwindow. Why is that? An other priority setting in Windows has no effect.

//Anders

[Mark F]

Where do you have the LUA script defined? In the serial plugin as a receive event script or as a command in the Girder tree?

[Tesargo]

The script is in a command in the Girder tree.

* Would it be faster if I put the script in yor "Generic serial support"-plugin instead?
* How do I get the IR-string within the Receive-event script in the plugin?
* Can a script in the Serial plugin call functions in the WinLUAEx-plugin?

Thanks
/Anders

[Mark F]

The answers are:

Yes, a character event handler in the plugin would be faster than a command in the tree due to (potentially) fewer thread switches.

The SerialValue variable contains the "IR-string" when the LUA event handler code gets control. Everywhere in your command script where you have been using pld1 (the IR-string), use SerialValue instead.

Yes, an event handler script can use any LUA function, including the ones in WinLUAEx or any other plugin. For example, the X10 MouseRemote sample (included in the serial plugin distribution) uses the MOUSE_* calls to move the mouse pointer and click the mouse buttons along with TriggerEvent to generate unique events for the other buttons.

[Tesargo]

Mark...
I got my script working, I just substituted the IR-string varible.

Well, the mouse pointer doesn't move smoothly anyway.
When I use the script as a command in the Girder tree it goes smooth when the Girder window is the forground window, but slow if it's in the background.

When I have the script as a receieve plugin script the mose pointer moves like the background Girder command solution, but no matter if the Girder window is in forground or not.

To me it seems like some thread has too low priority and that thread seems to be the one that processes the mouse movements. I think this is the case due to the fact that the the speed of the mose is not changed, only the time between each co-ordinate change. When it goes non-smooth, it jumps with fewer and greater distances. It is like each jump is composed of several smaller jumps that are added to each other to be performed in one larger co-ordinate jump.

* Is there a way to change the priority of a plugin?
I think the WinLUAEx should have higher priority.

/Anders

[Mark F]

Sorry that didn't work. Could you place the LUA script into a .zip file and attach it here? I would like to try it on my system at home tonight.

What other stuff is Girder doing while this is running? Do you have an LCD attached? Is it constantly updating? Are you running a media player? Are you intercepting messages from that?

[Tesargo]

The girder or the computer does nothing else simultaneously.

It is possible to control the mouse like it is, but I have seen that it can be controlled smooth when the Girder window is in foreground.

Do you have a SM-1000 remote control?

/Anders

[Mark F]

No, I don't have one of these. I will force one of my PCs to send data to the other in the correct format and see what happens. :)

[Mark F]

I am still at work so I haven't tried this on my test PC yet; but, have you tried to determine the right movement amount using an algorithm instead of those massive if/elseif/else constructs? Maybe something like this:


local header = strsub(SerialValue, 1, 2)

-- is this joystick stuff
if ((header == "7C") or (header == "FE")) then

-- get x and y movement as strings
local joyX = strsub(SerialValue, 3, 4)
local joyY = strsub(SerialValue, 5, 6)

-- if this is a non-0 movement
if ((joyX ~= "80") or (joyY ~= "80")) then

-- convert new relative movement from a hex string to a number and mask off the MSBs
joyX = band(tonumber(joyX, 16), 63)
joyY = band(tonumber(joyY, 16), 63)

-- convert from unsigned to signed as needed
if (joyX > 31) then joyX = joyX - 64 end
if (joyY > 31) then joyY = joyY - 64 end

-- move mouse
MOUSE_Relative(0, joyX*1.2, joyY*1.2, 0)

end
end


I don't know if this would be better or worse. :(

This is just an alternative approach. ;)

[Tesargo]

Well, it is not my script that slows down the performance.

I have run tests with a "MOUSE_Relative" statement only without any conditional statments at all, but that also gives very slow mouse pointer position changes.

Actually the best thing, without any if-statments, would be if the hex codes could be translated into decimal. Those values would be possible to immediately use in the "MOUSE_Relative" call.

I am using Girder 3.3.1.
Do you think any later version would have improved performance?

My computer is not slow, it is an AMD Athlon 2100+.

I suppose you have written that very general serial plugin. It is great and what it seems to me is that there is no bottleneck in it. I have seen smooth operation but only when the Girder window have been the foreground one.

Please tell me what happens if you have cared to run your tests between your computers.

/Anders

[Mark F]

You have done excellent testing to localize the problem. Thank you!

I'll let you know what I find.

[Mark F]

I just finished setting this up and running it. It must not be real world enough because I didn't see jumpy behavior with Girder minimized to the tray and the Logger plugin hidden. :(

After testing this way, I got out my old pointing device (RemotePoint Plus: 6 buttons and a hat) and played with that for a while. The hat uses the same MOUSE_Relative() function inside a serial event handler. This ran smoothly until I used it to start Internet Explorer 6. The mouse movement was jerky until Internet Explorer 6 was up and running and then became smooth again.

My PC runs at 633MHz using Windows '98 and Girder 3.3.5.

It may be Windows itself; but, something is stealing cycles from Girder on your machine. :evil:

[Tesargo]

Thank you for your work done.

Well, perhaps it might be my older version of Girder and/or that I'm using Win XP.
I'll first try to kill off unnessecary processes and then I'll try it on a Win 98 machine, and newer Girder, and finally I'll re-install my XP when I feel that I have time.

Thank you once more.

/Anders