PDA

View Full Version : NR communicate delay with GlobalCache?



Kaoh
July 25th, 2010, 06:48 AM
I just setup my first device with NR to test and convince the familty that this is the remote way to go.
But I run into a problem using this setup.
I have a windows mobile device and a globalcache WF2IR device. So both are on Wifi.
When I call the guide on my device using NR and use the arrow button to navigate through the guide the response is a bit slow. The device has a IR recieved light and what I see is that when I press the button in NR it takes about 1 sec before the IR recieved light fires. This is to slow when navigating a grid (like the guide) or a menu.
Is there anything I can do to increase the speed? My pronto does this almost instantly.
The next problem that results from this and really makes this useless, is that the globalcache or NR caches the send IR commands so all codes will be send at some point. So pressing 8 times quickly the down button with the intend to go down 3 steps ( that happens when people wonder if the command was send) will still overshoot but it takes 8 seconds, but after the first overshoot people send up commands to compensate so after a while you just have to go and wait till the device had catched up.
As you can imagine this is not going to work.
Can it be a code thing or a communication thing?

Wilhelm
July 25th, 2010, 07:19 AM
Is there anything I can do to increase the speed? My pronto does this almost instantly.
Hi Kaoh,

welcome to the forum. I am using a GC device as well, but the wired GC100-6. I have to say, that NR's support for the GC has always been very poor in performance, but nobody seems to care. You can use a Girder to act as a interface between NR and the GC. This is quicker (go figure) but is has the bad disadvantage that the Girder plug-in does a pretty bad job handshaking with the GC so it happens from time to time that a button gets "stuck" meaning it repeats forever, until you press the next button. If that happens with "volume up", good luck.
Another problem with GC is, that it only supports one open connection. If wifi breaks up even for a moment, NR fails to reconnect. You have to close and restart it. The same happens, if you try to connect to one GC with 2 client devices.

So I myself am using the "native" GC support of NR. Using a PC in between seems to be an idiotic move anyway.

All in all I sadly have to say, you have to live with the slow responses or get another remote solution.
I myself am leaning to the iPhone at the moment, but the solution I try to use now, is also not finished and reliable.

So, Good Luck

Wilhelm

Kaoh
July 25th, 2010, 04:48 PM
I have to say, that NR's support for the GC has always been very poor in performance, but nobody seems to care.

Yeah I just validated by converting the CCF codes I put into NR to the GC commands. Then used the iLearn tool from GC to send the commands and I got a fine result from this test. The device responds really nicely that way. So it definitly is a NR plugin problem.


You can use a Girder to act as a interface between NR and the GC. This is quicker (go figure) but is has the bad disadvantage that the Girder plug-in does a pretty bad job handshaking with the GC so it happens from time to time that a button gets "stuck" meaning it repeats forever, until you press the next button. If that happens with "volume up", good luck.
Is using Girder as quick as it should be? Or just a bit quicker? I cna live with that sollution if it really solves this slow response.
The repeat sounds like that girder is using the repeat mode sending commands with 15 repeats always and normally ending the sequence, this most be solvable. The API docs of GC actually describe this behaviour and document a good way of dealing with it.


Another problem with GC is, that it only supports one open connection. If wifi breaks up even for a moment, NR fails to reconnect. You have to close and restart it. The same happens, if you try to connect to one GC with 2 client devices.

That is not the case for my device, it support up to 4 clients.


So I myself am using the "native" GC support of NR. Using a PC in between seems to be an idiotic move anyway.
I agree, but I really want a working sollution ;)

The alternative is to create a new plugin for netremote. I will look into this in the next week or so. I need to master 3 things at once there, how to convert hex codes to GC commands, how to write a IP stack on a windows mobile device and how to write plugins for netremote. So this may take time ;)

Maybe this plugin can be made open source so that I can just fix the problems with it. That would save me a lot of time.

Kaoh
July 28th, 2010, 03:02 PM
I wrote a little windows app last night with a simple Tcpclient stack that connects to the GC and then lets me fire the commands when I press the button.
Well the GC responded really fast. So it definitly is a plugin problem that clearly has a design flaw.
It probably does the handshake stuff everytime a command is fired (connect, request device info etc) and then after firing the command it waits for a response to validate it was send but waits probably for 0.5 seconds to give the device time to respond.

I can not get the C support to install in my visual studio 2008 (only c# right now) but I will replicate this test using a program for windows mobile to make sure it is not the ip stack on the windows mobile device.

Kaoh
July 28th, 2010, 04:19 PM
I just ported my app to windows mobile app (wow MS thats easy good job on that). And this test app still fires the codes really fast to my GlobalCache, this combination is powerfull, it works faster then my pronto.
So it definatly is a NR plugin issue.
I will see what I can do about getting visual C working so I can take a look at the NR plugin stuff.

tmorten
July 28th, 2010, 07:41 PM
You should try the same test running NetRemote on a PC. I used NetRemote extensively on PC and on Dell Axim x51's (WinMo) and did not experience one second delays with my GC-100's.

For what it's worth, I don't recall there being a handshake per send in the code.

Cheers,
Tim

Kaoh
July 29th, 2010, 12:59 PM
You should try the same test running NetRemote on a PC. I used NetRemote extensively on PC and on Dell Axim x51's (WinMo) and did not experience one second delays with my GC-100's.

For what it's worth, I don't recall there being a handshake per send in the code.

Cheers,
Tim

I can't the PC out of sight of the tv where I test.
But I do not see what it matters, for me it is only important if it works on my PPC. If it works on the PC then it doesnt change a thing.
My own written tests apps have the same fsat response from the Laptop as from the PPC.
And I have only one license, so I am not allowed to install NR on the laptop. And again, I will not use the laptop for zapping.

Kaoh
July 29th, 2010, 01:06 PM
You should try the same test running NetRemote on a PC. I used NetRemote extensively on PC and on Dell Axim x51's (WinMo) and did not experience one second delays with my GC-100's.

For what it's worth, I don't recall there being a handshake per send in the code.

Cheers,
Tim

Oh, and did you use Netremote build in plugin, or the passthrough to girder for the communication with your GC?

tmorten
July 29th, 2010, 01:53 PM
Oh, and did you use Netremote build in plugin, or the passthrough to girder for the communication with your GC?

I've used both with similar results, but I prefer the Girder passthrough because of the disconnect issues that Wilhelm mentioned (which if I recall correctly were the result of a limitation in the GC itself rather than a software issue). By routing all my clients through Girder, no disconnects occur (since all traffic to the GC is coming through one connection).

Best,
Tim

Kaoh
July 29th, 2010, 02:28 PM
I've used both with similar results, but I prefer the Girder passthrough because of the disconnect issues that Wilhelm mentioned (which if I recall correctly were the result of a limitation in the GC itself rather than a software issue). By routing all my clients through Girder, no disconnects occur (since all traffic to the GC is coming through one connection).

Best,
Tim
My GC can support up to 4 clients, so I do not suffer from this problem for now.

Well, to sumarize, I still have still this problem, and I do not own girder. Nor will I buy it.
I need a way to solve this issue, else I purchased a product I can not use.
So please advise what to do, you say the NR does not have this delay, so I am doing something wrong, so how do we get behind this? What do I need to test with NR on my device, how should I work with the plugin instance etc. What logs do you need to find the sollution?

tmorten
July 29th, 2010, 02:33 PM
My GC can support up to 4 clients, so I do not suffer from this problem for now.

Well, to sumarize, I still have still this problem, and I do not own girder. Nor will I buy it.
I need a way to solve this issue, else I purchased a product I can not use.
So please advise what to do, you say the NR does not have this delay, so I am doing something wrong, so how do we get behind this? What do I need to test with NR on my device, how should I work with the plugin instance etc. What logs do you need to find the sollution?

Have you tried testing from the PC version of NetRemote to see if you experience the same symptom? Also, can you verify that the problem still occurs when using only a single client, so that we can rule out the known issue with disconnects? Also, what is the model number of the GlobalCache device that you're using?

Thanks,
Tim

Kaoh
July 30th, 2010, 10:03 AM
I only use one client. I have only one NR license, and no other applications running that connect to the GC.

iTach model:
iTachWF2IR

and I can not test from the PC, as mentioned earlier, since I have only once licens and the designer is on a PC from where I can not visually see any IR device to see the response.

tmorten
July 30th, 2010, 10:57 AM
There is a free 30 day trial of NetRemote here: http://www.promixis.com/download.php?id=1041

I suggest installing that on a laptop or a computer near your GlobalCache device to test with.

The iTach line was introduced after NetRemote 2, so it's possible that the iTach that produces different behavior from the GC-100 series that was the standard for many years, and which I use, but my first suspicion is that it's something related to running NetRemote on your WinMo device, so let's start by trying the PC version of NetRemote to rule that out.

Cheers,
Tim

Kaoh
August 1st, 2010, 04:25 PM
I gave it a try, but somehow the CCF is now corrupt. I can not open it in the designer anymore.
So I have to construct it again and then retest all. Well I have 30 days...

Kaoh
August 1st, 2010, 04:47 PM
Ok, the version of my CCF on the PPC was still working, so I copied it to the laptop.
And I tested, same results. When I press the button the first time the response is rather ok (0.2 sec) but when I press the button almost directly in sequence there is a delay of almost 1 sec before the second command is fired. So moving quickly down the guide is a pain. So there is no diverence in the behaviour on the laptop as with the PPC.
When I do the same with my own test code the commands fire without delay, so it is not the GC device it self nor the path from the laptop or PPC tpo the GC.

Kaoh
August 1st, 2010, 04:50 PM
I also noticed that when I wait myself over 1 second the delay is not there any more. So it looks like that after the first command is send the plugin taks alsmost 0.6-0.8 seconds to complete somehting before it is willing to send the second command. So the device is not ready to send a new command till almost 1 sec after a command.

tmorten
August 1st, 2010, 05:18 PM
Thanks, the detailed description is helpful. I will test this on my end to try to replicate. to make sure I understand:
1. The first press does not exhibit latency
2. Subsequent presses that occur in less than a second from the first press do exhibit latency
3. Subsequent presses that occur more than a second after the first press do not exhibit latency

Have I got it right?

Thanks,
Tim

Kaoh
August 2nd, 2010, 12:47 AM
exactly right

Kaoh
August 10th, 2010, 03:50 PM
Hi, just wandering if there is any progress on my issue here?

tmorten
August 10th, 2010, 04:36 PM
What repeat setting are you using for the plugin instance?

Thanks,
Tim

Kaoh
August 12th, 2010, 12:04 AM
Enable repeat is off,
Repeat: 0

tmorten
August 12th, 2010, 12:05 PM
Does enabling the repeat have any impact on the behavior for you?

Thanks,
Tim

Kaoh
August 16th, 2010, 06:08 PM
No it does not, I set it to enabled with repeat 0.
Exact same behaviour.

Ron
August 18th, 2010, 10:36 AM
Are there any other things trying to access the GC? Maybe some hardware or Girder?

Kaoh
September 10th, 2010, 04:24 AM
Are there any other things trying to access the GC? Maybe some hardware or Girder?

Hi Ron, sorry for may late response.
But no, the GC is brand new and netremote is the only intented client for it. So there is nothing setup that will use it. I do not own girder nor have it installed and I would know of no hardware I own that knows and understands the GC device.