PDA

View Full Version : Problems with UIRT2



levyshay
October 13th, 2002, 12:55 PM
Hi Jon,Luc and everyone...

I've replaced my IR detector with a shielded one which I took from an old creative infra cdrom. The detector had 47uf capacitor in parralel so I connected it also. Now my UIRT doesn't output any garbage at all.

My configuration:
UIRT2 (Kit A) from Luc, girder 3.24, 10Mhz PIC clock, programed with v1.7
PC: PIII-800. Also my kit is well built, And generaly I get it to work very well, ...

I took some time and do some testing, and I encountered the flollowing problems:

1. I use an original pin to pin serial cable, when connected a program that access the UIRT (Girder,Test App,Terminal) will crash/hang after recieving 20-50 codes from a remote. Adding in series with that cable a small adapter which connects only TxD, RxD and GND (both pin 5 and shield GND) solves this problem. So I guess the problem come from RTS/CTS/DTR, but I couldn't find which.

2. I use the UIRT to recieve a button from a remote (Volume Up/Down) and send it to my AVR. Generaly it works fine. Sometime the pic gets into a loop an starts trasmitting garbage for 5-10 seconds, during this time it's not accessible to the PC. Disconnecting the UIRT from RS232 doesn't stop it while it is in this loop, so I think the problem is inside the PIC software.

3. I have 2 remtoes which when using normal IR decoder (Like igor's one) produce diffrent codes, under UIR mode this remote produce exactly the same codes. I've tested them with the test app in all modes, on RAW/STRACTURED mode you can see that the codes they send are not the same, only the last bytes are the same (which I think describe the key on the remote which can be the same) but the first bytes (which I think are the remote ID) are not the same. UIR mode will produce the same code for those remotes.

4. Using a remote that trasmits it's code once, and then a diffrent code for repeat will produce only one event, as the key was pressed just once, and not helded. On remotes that send the same key it works fine.
I would like to ask if a small routine can be implemented into the pic which will solve this.
I wrote such routine for a dos driver I wrote long ago, what should be done is:
After decoding a code from a remote you start a timer (something around 200ms), if during that time something is sensed from IR decoder the same code allready decoded should be sent to the PC, so the pc see's the same button repeats. When the timer ends the next thing come from IR decoder will be considered as a new key. This is based on the fact that normal people can't press two different keys within 200ms time.
Alternatly a much simpler but less clear solution would be to trasmite the second code from IR decoder to the PC, So in this case the job of detecting a repeated code would relay on the plugin.
I've tryied configuring a serial plugin for girder which will recieve codes as stractured (Not UIR as normal) and this way I got one code for the 1st press, and a diffrent code indicates repeating.

5. If I leave the pic in RAW/STRACTURED mode and start girder it will not put the UIRT back to UIR mode. Entering learn mode (for trasmiting) in the plugin would put it back to UIR mode. So I think the plugin is missing an init that would put it in UIR mode at start (maybe it is done via RTS line, but mine is not connected to the pic..., so it should be done via a command also, atleast when fast UIR init is not checked)

Well this message becomes too long ... so thanks for reading.

Shay Levy.

levyshay
October 13th, 2002, 12:55 PM
Hi, Thanks for your attention Luc.

I've tried programing my UIRT2 with Danijel Pticar's software version 1.22. which gave interesting results:

Problems 1,2,3 where solved:
1. Girder didn't stuck at all. I had to switch back to girder 3.1 as I didn't find plugin for DP's software for girder 3.2, While I was in girder 3.1 I programed UIRT back with Jon's software version 1.7 and girder started hanging/crashing again (Girder 3.1 is mostly hangs, while girder 3.2 crashes)
2. Never accured.
3. The 2 remotes produced diffrent codes in UIR mode (Quiet simillar, but still with 2-3 bytes diffrent), as they should.
4. This is the same with this version.
5. Not tested, plugin releated.

I've also tried programing the PIC with 4Mhz version of Jon's firmware (Also replacing the crystal to 4Mhz) All problems accured on 4Mhz version execpt problem 2 which I think came out just once after heavy testing, and I'm not sure if it did accured or it was something else.

BTW: I noticed that the crystal makes no problems if it's not removed and since I programed diffrent versions every 10 minutes and didn't want to ruin the PCB I didn't remove it. Also a quick way of enabling disabling PROGRAM mode is to put a jumper header on the Shunt1 pins, for normal mode a jumper cap is placed, for programing mode I took a 9V battery and made a small cable from it using a 2 pin connector from an old pc case which can connect directly on the 2 pins of the removed jumper.

Regards,
Shay Levy.

levyshay
October 13th, 2002, 12:55 PM
Another test I did:
I took two remotes which produce same codes with UIRT2 & Jon's firmware (v 1.7, 10Mhz)
These remotes produced different codes with DP's firmware.
I opened one of the remotes and changed the address of the remote by changing one bit, the change was noticed with DP's firmware, but not with Jon's firmware. I had to change 4 bits of the remote address till the change was noticed on Jon's firmware. So I guess something in the UIR mode calculation drop some bits.

Shay Levy.

levyshay
October 13th, 2002, 12:55 PM
Solution for problem 1. (Cabling)

After long hours of testing why when all RS232 pins are connected communication programs hang/crash I solved the problem. (at least for me)
I insisted that the problem is within the PIC firmware as this problem occurred to me only with Jon's firmware and not with others, after spending some few hours on this issue debugging the function that sends data to PC and even writing new one of my own I got to the conclusion that it might not be software problem, but hardware one (what else left?...)
The problem didn't occur on other firmware they use the port at 9600bps most of the time and switch to higher baudrates only for recording/transmitting (short times)
So I took a cable with only RxD TxD and GND connected and started connecting pins to see where the problem come from. the problematic pin was CTS (Pin 8), When this pin is not connected no problem, but without this pin you can't program the PIC, so a solution was to put a 10K resistor (I used it since it's the first one I founded in a pile of resistors, I don't know if a better value should be chosen) between CTS line from PC to UIRT2. After trying to program the PIC few times, and checking that no problem with communication software's, I've done a little cut on the PCB and soldered the 10K resistor there.
I hope this will solve similar cabling issues other having.

Regards,
Shay Levy.

Luc
October 13th, 2002, 12:55 PM
Shay,

this is indeed a very detailed problem report.
I can't similate some of these on my P2 system and did not yet have the time to try the others. I will try everyting on the P2 and lucky me: I just have a P4-1600 waiting to be delivered thus I will try it on this one also and hopefully will be able to reproduce and solve some of them.

Luc.