PDA

View Full Version : GlobalCache IR not working - driver problem?



jameswing
March 6th, 2005, 11:04 PM
Does anyone have the GlobalCache device up and working with NetRemote? I have done the following:
1)Set up GlobalCache with a local IP address (192.168.0.70)
2)Configured Netremote IR plugin (instance -3) properties (driver mode = GlobalCache; host = 192.168.0.70; port = 4998; enable repeat = checked; repeat limit = 10)
3)Programmed a button in my CCF to send a learned IR command (0000 0067 0000 000d 0060 0019 0019 0019 0019 0019 0030 0019 0030 0019 0030 0019 0019 0019 0019 0019 0030 0019 0030 0019 0030 0019 0019 0019 0019 03ea )

When I click the button, I can see the activity LED on the GlobalCache eathernet connection flash, indicating activity from the LAN. I see the 'transmitting IR' LED above IR port #1 on the GlobalCache flashes, indicating that it is modulating the IR emitter.

The device does not respond to the IR that is generated by the emitter. I have tried a new blaster (Smarthome #8174) as well as a new emitter (Smarthome #8107S). I have confirmed via a flashing IR receiver that the emitters are in fact, generating SOME IR. I have distances all the way form 0 inches to 6 feet.

I have reconfigured the IR plugin to use NRIR Server and a USB-UIRT on a PC (driver mode = passthrough; host = 192.168.0.100; port = 19001) and tested my button. It works fine using NRIR Server.

I have attempted to view the raw code of what is generated by the GlobalCache device using utilities provided by Jon Rhees, but the IR seems to be rejected as just noise. I have noticed that the duration of the flashing is shorter for the IR generated by the GlobalCache (the IR that doesn't work) and the duration of the flashing is longer for the IR generated by NRIR Server & USB-UIRT combo (the IR that does work). Also, holding down the button makes the code longer when using NRIR Server, but has no effect on the very short burst generated by GlobalCache (changing the repeat limit setting for GlobalCache has no effect)

Am I correct in my belief that I don't have to do anything to the CCF formatted code for it to work with the GlobalCache driver?

I am using Netremote v. 1.0.20.0.

Thanks,

Jim

jameswing
March 6th, 2005, 11:48 PM
More info:
I tried some longer codes from another remote. After many attempts, I was able to get GC to emit enough of a signal so that when holding the blaster against the face of the USB-UIRT about 1 cm to the left of the indicator LED and making several attempts, Jon Rhees' learning utility was able to get enough of a sample so that I could hit 'Accept Burst' and get a code back. Note that the Signal Quality bar was near 100%, but the Learn Progress bar was only about 25% as long as it is when learning directly from the IR remote control. It seems like the duration of the IR signal is just really short when produced by the GC. :(

Here are the CCF formatted codes:

This learned from the remote control first and pasted into CCF:
0000 006b 0000 0032 007e 003f 0010 0010 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 06df

This learned from the very small sample provided by the CG after many attempts:
0000 006A 0000 0032 007E 003F 0010 0011 0010 0011 0010 0031 0010 0011 0010 0031 0010 0011 0010 0011 0010 0011 0010 0030 0010 0031 0010 0011 0010 0011 0010 0011 0010 0031 0010 0031 0010 0011 0010 0011 0010 0011 0010 0011 0010 0010 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0031 0010 0011 0010 0011 0010 0011 0010 0011 0010 0031 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0031 0010 0031 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0FEB

Sanity check - relearned from remote control after above to be sure of the 'sample size' issue. I still get a short enough duration that I have to use the 'Accept Burst' button, but the 'Learn Progress' bar is ~ 4 times as long when the remote control provides the signal as it is when GC provides the signal:
0000 006C 0000 0032 007E 003E 0010 0010 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 06D8


Any ideas?

Thanks,

Jim

jameswing
March 7th, 2005, 04:17 PM
I believe I may be on to the source of the problem...

Reference http://www.giantlaser.com/tonto/?x=doc_ir which explains the various 'parameters' of an IR transmission, including frequency, intro sequence, repeat sequence, type, etc.

It explains:

...But in a nutshell, an IR signal usually has two basic components: 1) an introductory pulse sequence and 2) and a repeat sequence. The intro sequence is sent as soon as the button is pushed. This is followed by the repeat sequence which keeps being repeated as long as the button is pressed. Each sequence is sent at least once. This is useful when understanding the 'type' field.

'Type' is one of 'S', 'F', or 'N'. 'S' is 'Standard' which means the intro and repeat are sent normally. 'F' is 'Repeat Full' which means the intro and repeat will both be repeated. 'N' is 'Repeat None' which means the intro and repeat will only be sent once each. Almost all signals will be of type 'S'.
ie. The standard is to send the 'into sequence' once, then repeat the 'repeat sequence' until the button is released.

I believe the problem is with the "Type". I don't see how the "Type" is stored in CCF formatted codes. It appears that when using NRIR Server, it keeps sending the code until I release the button, or until it has repeated [x] times, whichever is first. But when using GlobalCache, it sends the code exactly once, regardless of how long I hold down the button.

(I have confirmed that GlobalCache receives packets when the button is pressed, and again when the button is released, but the emmission of IR only occurs for a fraction of a second immediately after the button-down event)

It is looking very much like the GlobalCache driver is assuming a 'Type' of 'N' (No repeat) without regard for the setting of 'enable repeat' and 'repeat limit'.

Ed?

Thanks,

Jim

jameswing
March 7th, 2005, 10:24 PM
OK… Theory confirmed.

I took a short code (stop for my Sony Camcorder) and deciphered it. Here is the CCF version:
0000 0067 0000 000D 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD

The 3rd ‘word’ (0000) tells us that there is no non-repeating portion of the code. The 4th ‘word’ (000D) tells us that the repeating portion of the code is 13 pairs long. The 5th – 30th ‘word’ is the repeating portion of the code. Copying the repeating portion of the code, and pasting it 7 more times onto the end; then changing the 4th word to ‘0068’ (thus indicating that the code is (8 x 13 =) 104 pairs long), we get a valid code that represents the original IR signal, repeated 8 times. Here it is:
0000 0067 0000 0068 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD 0060 0019 0018 0019 0018 0019 0018 0019 0030 0019 0030 0019 0018 0019 0018 0019 0030 0019 0030 0019 0030 0019 0018 0018 0018 03FD

Associating this ‘supersized’ code with my button, and executing it via GlobalCache, it operates the device properly.

Changing the ‘repeat limit’ to various numbers between 1 and 1000 in the Netremote IR plugin has no effect on how many times GlobalCache transmits the repeating portion of the IR code. It is ignoring the ‘enable repeat’ setting and assuming it off.

In my testing, I have observed that NRIR Server seems to have a preset minimum number of repeats. When you ‘disable hold-down button repeats’, it still transmits the repeating portion of the code enough times for it to be recognized by the receiver (my SWAG is somewhere between 4 and 10 times). The GlobalCache device appears to be transmitting the code exactly one time (which is not enough for the receiver to be sure of it).

Ben, did you write the GlobalCache driver? Can you check this out? It must have been working properly at one time, but it isn’t now. :cry:

Dave T, Is there a minimum repeat count in NRIR Server?

--Thanks,

Jim

jameswing
March 9th, 2005, 10:32 PM
OK... Two theories confirmed now... I am on a roll. 8)

1) NRIR Server does in fact automatically repeat the repeating portion of the code six (6) times.

2) GlobalCache sends the code exactly one (1) time, regardless of the repeat settings.

I purchased an IR learner from GlobalCache, and the bundled software allows you to adjust the 'End Timeout' -- the minimum length of time that a IR signal must not change state for the learner to assume that it is a 'trailer' - ie. the end of the code.

Check out this Pronto (or CCF) formatted code:
0000 0068 0000 000d 0060 0018 0018 0018 0018 0018 0018 0018 0030 0018 0030 0018 0018 0018 0018 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 0323
Word 2 (hex 0068 = 104) shows that the frequency is (1000000/(104* .241246) =) approximately 40 kHz.
The last word (hex 0323 = 803) shows that the the last 'state' of the modulation lasts for (803/40kHz =) approximately 20 milliseconds.
Summing the periods for all the on/off 'states' (words 5 and up), (hex 623 = 1571 cycles) we find that the entire code lasts for approximately (1571/40kHz=) 40 milliseconds.

I have an IR detector in the area of my testing that flashes when it detects IR modulation. This 'telltale' barely flashes for an instant, if at all, when the GlobalCache sends the above code. But it shines for a good quarter of a second when I send the code via the USB-UIRT or my Sony remote.

When I set the 'End Timeout' to be 20 ms, The above code is what I 'learn' from the 'stop' button on my Sony camcorder remote. (Recall that the 'trailer' on that code is about 20 milliseconds.) When I set the 'End Timeout' higher (35-100 ms), I can see that the Sony remote control repeats the repeating portion of the code 5 times, as this code is 'learned' from it:
0000 0068 0000 0041 0060 0018 0018 0017 0018 0017 0018 0017 0030 0017 0030 0017 0018 0017 0018 0017 0030 0017 0030 0017 0030 0017 0018 0017 0018 03FA 0060 0018 0018 0017 0018 0017 0018 0017 0030 0017 0030 0017 0018 0017 0018 0017 0030 0017 0030 0017 0030 0017 0018 0017 0018 03FA 0060 0018 0018 0017 0018 0017 0018 0017 0030 0017 0030 0017 0018 0017 0018 0017 0030 0017 0030 0017 0030 0017 0018 0017 0018 03FA 0060 0018 0018 0017 0018 0017 0018 0017 0030 0017 0030 0017 0018 0017 0018 0017 0030 0017 0030 0017 0030 0017 0018 0017 0018 03FA 0060 0018 0018 0017 0018 0017 0018 0017 0030 0017 0030 0017 0018 0017 0018 0017 0030 0017 0030 0017 0030 0017 0018 0017 0018 057E
and the USB-UIRT repeats the repeating portion of the code 6 times, as this:
0000 0065 0000 004E 0060 0017 0018 0018 0018 0018 0018 0018 0030 0016 0030 0016 0018 0018 0018 0018 0030 0016 0030 0016 0030 0016 0018 0018 0018 031E 0060 0017 0018 0018 0018 0018 0018 0018 0030 0016 0030 0016 0018 0018 0018 0018 0030 0016 0030 0016 0030 0016 0018 0018 0018 031E 0060 0017 0018 0018 0018 0018 0018 0018 0030 0016 0030 0016 0018 0018 0018 0018 0030 0016 0030 0016 0030 0016 0018 0018 0018 031E 0060 0017 0018 0018 0018 0018 0018 0018 0030 0016 0030 0016 0018 0018 0018 0018 0030 0016 0030 0016 0030 0016 0018 0018 0018 031E 0060 0017 0018 0018 0018 0018 0018 0018 0030 0016 0030 0016 0018 0018 0018 0018 0030 0016 0030 0016 0030 0016 0018 0018 0018 031E 0060 0017 0018 0018 0018 0018 0018 0018 0030 0016 0030 0016 0018 0018 0018 0018 0030 0016 0030 0016 0030 0016 0018 0018 0018 0596

You can see the 20-25 ms pauses every 13th pair, and the giant pause at the end when the transmission stops and the learner times out.

Here is the code learned form the GlobalCache transmission:
0000 0068 0000 000D 0061 0018 0018 0017 0018 0017 0018 0017 0030 0017 0030 0017 0018 0017 0018 0017 0030 0017 0030 0017 0030 0017 0018 0017 0018 057E
(the 4 words describing the code, plus exactly one iteration of the code).

With these oodles of evidence, will Ben or whomever at Promixis is responsible for the GlobalCache driver either:
a) acknowledge this problem and tell us that GlobalCache is being sent a command to repeat the code, but it is not doing so (and thus the problem is with GlobalCache)... or
b) acknowledge this problem and tell us that there is a problem with their driver and they are providing a fix... or
c) acknowledge this problem and tell me to 'pack sand'... or
d) hell, send me the source code and I'll fix it!

I feel like I've been talking to myself for three days. [reading thread...] Oh, I have... :x

Ok. I guess that isn't that long. [...takes chill pill] It just seems long because I am running out of time to return stuff if it isn't going to work. :(

I hope to hear from you guys.

--Jim

ebariaux
March 10th, 2005, 01:42 AM
Just so you're not entirely talking to yourself... here is some of my understanding of all this.

The repeat setting for the GC in NR is for the maximum number of times an IR code will be repeated when you press and hold a key. This is mainly a protection so that if there is ever a communication issue between your PPC and the GC, you don't end up with having the volume up IR code repeated forever.

But it does not mean that the code will be repeated when you just hit a button on your CCF. In this case, the code will be sent exactly one. And if the code in your CCF is, as I understood, 40 ms long, then this is what the GC sends and this is what you're seeing (as I understand).

What I would do, is use the GC IRL with an "end timeout" setting set to longer (e.g. 100ms) and use that code in your CCF. Also, as you're trying to learn the stop key, I don't see a need for a "repeat on hold" there, so the fact that there is a portion of the code that is repeated 5 times by the Sony remote should not matter, everything is part of the "one code" for stop.

Eric

jameswing
March 10th, 2005, 11:04 AM
Thanks Eric,

I was getting kindof lonesome in this thread. :)

Your understanding of the purpose of the repeat setting in the GC driver is the same as mine -- a maximum number of times the code is allowed to repeat, not a minumum... for the reason you stated. The problem is that when I hold the key down, it will not repeat the code at all via GC, no matter what the settings.

I forgot to mention that I had 'disable repeats' set in NRIR Server for this trial and I held the button down, waiting for the code to stop on its own, in order to avoid having the button timing variable creep into it. NRIR's version of sending the code just once is actually to send the repeat-sequence six (6) times. Similarly, the reason I chose the 'stop' key on the Sony remote is that it is a 'non-repeating' key (An example of a repeating key is the fast-forward key, which repeats as long as you hold it down.) The stop key on the Sony remote sends the repeat-sequence five (5) times when you press the key and hold it down indefinitely. (Note it takes less than 1/4 of a second to do this, so holding down the key indefinitely is equivalent to pressing and releasing it as fast as your finger likes to press rubber keys.)

I think the reason Sony transmits five (5) iterations of the repeat-sequence (and NRIR Server + USB-UIRT transmits six (6) iterations) is that they know that there is a lot of noise in the IR spectrum, and once is almost never enough for the receiver to be certain of the code (ie. the receiver needs more than one sample of the code to reject errors, etc). So you have to make a SWAG as to how many is a reasonable number of iterations of the repeat-sequence (with a 'non-repeating' key) to assure reception without overdoing it. Sony uses five (5) for the remote in this discussion, NRIR Server uses six (6). There is no way to store a 'repeat count' in a Pronto/CCF code.

I had attempted exactly what you recommended -- storing a CCF of five (5) repeats as just one code. This does in fact allow GlobalCache to work for non-repeating codes (like stop), but it fails in two other ways: 1) I still cannot send repeating codes (like fast-forward) that need to repeat until I release the button, and 2) When I use NRIR Server + USB-UIRT to send that new code, it sends (5 x 6 =) 30 iterations of the repeat-sequence.

Feel my pain... :cry:

--Jim

jameswing
March 10th, 2005, 11:16 AM
I moved this thread to the Developer / Bugs forum. Please post further replies there.

http://www.promixis.com/phpBB2/viewtopic.php?p=113348

--Jim