UIRT2b / girder generating different codes for IR commands

[levyshay]

Well I use fluorescent lights, And although they cause little interference (Can be noticed by all IR devices, not only UIRT2), I Wouldn't say it's the main problem. (Btw- I also have a red lamp which also has some effect)

Anyway, vbray, Please try to learn girder button from your remote in the "Transmite IR Command" part of the plugin. I think I discovered a bug causing girder get random IR codes. I wouldn't write a conclusion till I test it carefully, But for now I've noticed that learning a key for retrasmision allways gets the same code. You wouldn't be able to trigger girder with it, but it'll help solving your problem.

Shay Levy.

One last thing: If you have an extra IR reciever try replacing...

[jon_rhees]

All,

what you are describing can be one of two things:

1 - you're using a remote which toggles codes. If this is the case, you get two repeated codes for a button -- not random codes.

2. (much more likely) - the supply to the IR detector on your UIRT is noisy. The IR detector is *very* sensitive to high-frequency noise which will cause it to output false signals when all is quiet -- when the detector's automatic gain control (AGC) is settling. There's an easy way to prove if this is happening:
- Create an event and press the 'IR DEBUG' button (below the 'Test' button) and *DO NOT* press any IR buttons. If there is noise, the progress bar will move, indicating you're receiving data, and you'll eventually see a screen full of random hex data. When in this IR debug mode, the UIRT outputs raw pulse data from the IR detector. Now, if you *DO* get noise, you'll commonly find that holding your hand over the IR detector to block all light will calm it down.

The best remedy for this problem is to put in an L-C filter on the 'supply' pin to the IR detector itself.

-Jon

[jon_rhees]

I kind of wish the UIRT designs already had these components incorporated...but oh well.

If you have some old junk PCB's around, perhaps you can find a small ferrite or two. This can act as the 'L' (L stands for inductor). Thru-hole ferrites on PC boards look like black, cylindrical resistors. They are basically a piece of solid wire running through a ferrite cylinder. What you would want to do is put one of these in SERIES with the V+ supply line going to IR detector. Then, you'd want to add a 0.1uF capacitor directly between the + and GND leads of the IR detector. This should help.

I don't know about your specific detector, but many have a shield around them which MUST be grounded for good performance.

Good luck!

-Jon

[vynce]

Have you tried turning the lights off in the room? Some lights (especially fluorescent) can cause interference. Just something else to try...

[windtrader]

I completed my UIRT2 and had the problem with flaky commands. I made the fix Jon recommends and used shielded cables and everything works just fine.

Luc, I think adding the L-R and capacitor to the receiver should be required on all UIRT2.

I am running a AMD A7V, Duron-700MHz, Girder 3.2.4, and John Rhees Girder plug-in V2.0.

I'll be posting my instructional site in a day or so now that everything checks out.

Don

[Luc]

I tried the debug on my system as well and receive nothing, there are fluorecent lights and several monitors and PC's closeby, only after 4 hours there are now a few blocks.
Then went onto another PC and here it receives in a second or so, tried the A and B version with same results. The only major difference is when I use an old TK19: this one receives almost nothing.
Different combinations of filters have been tried with my receiver and it looks like an LC filter gives the best performance.
A resistor and 100n cap also reduce the disturbances very significant but not as good as a ferrite bead.
A single cap direct on the receiver supply pins also improves but the 2 above are far better.
I will do some more testing and will post the results ASAP.

It's obvious that it depends on the PC and the problem can range from none to very significant. I measured the ripple on the supply of the bad PC and it's real hard to see something, it was less than 10mV.

[vbray]

I have communications to the UIRT2 working (thanks, guys :) ) so on to the next problem. I am getting different codes with the same IR command. I have noticed this seems to be a common problem and thought we might consolidate some wisdom on the subject, as I can't find a definitive answer.

Some things I've tried:

1. soldered my receiver directly to the circuit board. ( maybe helped some )
2. tried different remotes and get the same result.
3. moving the uirt further from the pc seems to help in getting the same code more often. how will this help long term since the UIRT is going inside the pc?

I have noticed that :

1. the code displayed in girder will frequently stabilize after the remote button is pressed 10 or more times, then go back to jumping around.
2. the codes displayed very often have the same data in the last 2 or 3 positions.
3. there is usually one code that is displayed more frequently, and is the code mentioned in #1 above.

I found a reference to using the configuration program to set the remote to ignore the first 16 bits, etc, but that program doesn't seem to work with the UIRT2. It seems like a timing or interference problem, but I can't nail it. Anyone got the real answer?

Thanks very much for any suggestions!

[vbray]

I don't have any fluorescent lights in this room. I'll have to try the capture for retrasmit to see what results I get. Is this just a girder 3.2 issue?

I have noticed that some remotes are doing it and some don't. The sony definitely does, and the rca dish remote, but my old magnavox remote captures the same code each time. I'm using a pronto, so all I really need for now is a dependable set of remote codes to teach the pronto / girder. I'm going to try pioneer codes next, they seem to have pretty comprehensive remotes...

Thanks alot for the input!
Vince

[vbray]

If there is noise, the progress bar will move, indicating you're receiving data, and you'll eventually see a screen full of random hex data

You nailed it! That is the problem. It makes alot of sense, because soldering the receiver to the board seemed to help, but not fix completely. This is interesting, too; I had three strands of solid copper cat5 conductor about 4 feet long originally going to the receiver, and the wires were twisted pretty well. The receiver would show activity in the plain girder window, and show remote codes even when no activity was present.

Interestingly I have found that shorter IR codes work very well even under these conditions... makes sense, less chance of fatal interference in a shorter transmission. I have done some experimenting with my pronto and found that the magnavox codes for my old cd player work pretty well. I hate to be stuck with these but it is very cool to see it work after all this effort!

I am, though, clueless as to what values of L and R and how to connect them. Can you suggest something to start trying with? What frequency should I be shooting for and is it a low or a high pass?

Thanks again for the help, this little device is very cool 8)

[vbray]

Yes, I was thinking the same thing about including it... anyway that's easy enough to do. That explains why the detector from radio shack has the tin shield around it. I could fab something like that.

Thanks for pointing me in the right direction, though. The IR debug is very useful for troubleshooting this. I hadn't found that yet.